/method/mcp-receipt-pack

External SRS Receipt Verification

This page explains how an external, vendor-neutral SRS receipt pack is verified from explicit files: the input bytes, a deterministic adapter, a valid fixture, an invalid drift fixture, the byte-for-byte expected validator outputs, the canonical SRS envelope schema, and a pack-local check. The worked example is the vendor-neutral MCP audit-trail receipt pack. Verification proves SRS envelope form and input-byte integrity only. It does not prove that any recorded event is true, it does not admit a record, it does not certify compliance, and it asserts no live integration.

The worked example

The example is the first vendor-neutral, receipt-bearing conformance pack in garp-receipt-conformance, merged as PR #7 (commit 3e2fe99) under packs/mcp-audit-trail/v0.1/. It takes one explicit, public-safe MCP (Model Context Protocol) custody-gateway audit-trail input file and builds one ARCS SRS envelope receipt from it. The audit trail is digest-only: generic tool names such as fs.read and kv.get appear with sha256 argument and result digests, never raw payloads — and there is no AWS, OpenAI, Microsoft, or Bedrock identifier anywhere. The fixtures are synthetic and authored in that repository. GARPedia explains the verification shape; it does not admit these fixtures into the public commons and does not treat them as admitted state.

What verification checks

Verification checks structural and cryptographic integrity only. Structural: the receipt is a well-formed ARCS SRS envelope under the canonical schema, with all GARP body content under extensions.garp.body. Cryptographic: the receipt binds the exact input bytes — the sha256 recorded in extensions.garp.body.artifact_hashes equals the sha256 of the input file — and the receipt regenerates byte-identically from that input.

What verification does not do

Verification does not prove truth. It does not assert that any recorded audit event is true, that any tool call was authorized, or that any custody claim is correct. It does not admit a record, it does not certify compliance, and it asserts no live integration: the check is pack-local and offline, with no network, no live credentials, and no scanner. The receipt attests envelope form and input-byte integrity; nothing more.

The four explicit verification inputs

Verification is computed from four explicit inputs — files and a schema, never live state.

input bytes: The explicit public-safe input file input/mcp_audit_trail.input.json. The adapter reads one file and writes one file; there is no other source of state.
expected receipt bytes: The valid fixture fixtures/valid/mcp_audit_trail.envelope.json — the receipt the deterministic adapter must reproduce byte-for-byte from the input bytes.
canonical SRS envelope schema: The schema already vendored and reconciled in the repo at schemas/srs-envelope/v0.1.0/, pinned by digest e866eabf…d6b61. The pack validates against it; it does not re-vendor or edit it.
validator output: The byte-for-byte expected text under expected/valid/ and expected/invalid/, compared against the canonical validator's actual output.

What the pack-local check proves

The pack ships its own conformance check, check.sh, run from the repository root. It uses the Python 3 standard library and stock POSIX tooling only — no network, no live credentials, no scanner. In order, it proves:

Explicit-file input, deterministic adapter. The adapter tools/build_receipt.py reads the one input file and regenerates the receipt byte-identically — no wall clock, no randomness — and the result is diffed against the valid fixture.
Cryptographic binding. The sha256 recorded in extensions.garp.body.artifact_hashes is compared against the sha256 of the input bytes; they must be equal.
Valid fixture validates. The canonical validator exits 0 on the valid receipt and its output matches expected/valid/ byte-for-byte.
Invalid drift fixture is rejected. The same canonical validator exits 1 on the drift fixture and its output matches expected/invalid/ byte-for-byte.

A green check means the receipt is a well-formed SRS envelope that binds its input bytes and that the forbidden drift is structurally refused. It does not mean the audit events are true, authorized, or admitted.

Valid fixture vs invalid drift fixture

The pack pairs one valid fixture with one invalid drift fixture so the check proves both acceptance and refusal against the same canonical validator.

valid

The valid receipt demonstrates the correct shape: any decision/verdict semantics are carried as a reference, extensions.garp.body.decision_ref, with no verdict anywhere. The expected output reads Valid SRS envelope 0.1.0.

invalid drift

The drift fixture hoists the gateway decision onto the envelope as a top-level status verdict. The canonical validator rejects it with TOP_LEVEL_BODY_VERDICT, proving the drift away from decision_ref is structurally refused.

Envelope invariants (Option A)

The receipt holds the same envelope invariants the canonical validator enforces. There is no top-level receipt_class. receipt_type remains the family axis in the closed enum; this pack uses provenance. boundary_type remains the top-level routing axis, and garp-receipt-conformance PR #8 (commit 72e3a18) settled its posture as an open string: this pack uses audit_trail_boundary as a pack-local descriptive value under that open-string boundary_type — not a newly-minted canonical boundary_type. GARP body content lives under extensions.garp.body, named by body_kind (here mcp_audit_trail). This preserves Option A: decision/verdict semantics are a reference under decision_ref, never a body-level or top-level verdict, status, disposition, decision, or governance_state.

Vendor packs instantiate this neutral shape

This neutral pack (garp-receipt-conformance PR #7) proves the shape, and the first vendor-specific pack now instantiates it. garp-receipt-conformance PR #9 (commit bf5ca67) added packs/bedrock-openai-audit/v0.1/, a Bedrock/OpenAI explicit-file pack: it reuses the same canonical schema, the same envelope invariants, and the same decision_ref discipline, differing only in its explicit, vendor-shaped input. Like the neutral pack, its verification is structural and cryptographic only — it does not verify Bedrock or OpenAI model output. Future AWS and Microsoft AGT packs should clone this PR #9 pattern: reuse the proven shape, never invent a new receipt shape, and never weaken any invariant.

Durable non-claims

Verification is structural and cryptographic only.
Verification does not prove truth.
A receipt attests envelope form and input-byte integrity only.
Verification does not admit a record.
Verification does not certify compliance.
Verification asserts no live integration.
A passing check does not authorize any tool call.
A passing check does not assert any custody claim is correct.
The example fixtures are synthetic, not admitted public commons.
The canonical schema is referenced, not re-vendored or edited.
audit_trail_boundary is a pack-local descriptive value under an open-string boundary_type, not a canonical boundary_type.
Decision semantics are a decision_ref, never a top-level verdict.
Vendor packs reuse the neutral shape; they do not invent new receipt shapes.
The Bedrock/OpenAI vendor pack does not verify Bedrock or OpenAI model output.

Related method pages

/method/mcp-record-custody-gateway — the custody-inspection sibling at the same MCP boundary that likewise separates posture from admission.
/method/context-io-governor — the disposition surface that also reports exposure without minting a canonical receipt.
/examples/srs-receipt — the SRS receipt walkthrough that shows one envelope and its conformance posture three ways.
/method/reverse-wiki-function-inventory — the inventory where public method surfaces are kept legible.