The verification.* Constraint Family: Pre-Action Fail-Closed Gates for AI Agent Decisions

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Scope

In scope:¶

• Gate semantics for pre-action verification of factual claims.¶
• Receipt envelope format and required claims.¶
• Calibration anchor requirements and discipline.¶
• Multi-axis freshness model.¶
• Verification protocol for relying parties.¶

Out of scope:¶

• Signing key management policy (defers to JWKS standards).¶
• Specific verifier implementations or model architectures.¶
• Claim-extraction techniques (how a claim is identified from agent input/output).¶
• Adversarial-probe methodology specifics.¶

3.1. The Four States and the Capture Relationship

A verifier reports exactly one of four states for an admitted observation:¶

• verified --- the claim was checked against evidence and the evidence supports it.¶
• contradicted --- the claim was checked against evidence and the evidence is inconsistent with it.¶
• indeterminate --- the claim was checked and the check did not resolve to either of the above. See below for the reason codes that distinguish why.¶
• not_evaluated --- no check was performed.¶

These four supersede draft-krausz-verification-state-01's supported / refuted / unverifiable / unknown domain one-for-one in that order; see Section 10 for what this renaming does and does not settle about the downstream recommendation and gate mapping.¶

Capture relationship. A state is not a free-standing value. A receipt MUST capture a state together with (a) the subject it describes (Section 3.2) and (b) a reason code, when this section requires one for that state. A bare state carried without an identified subject is not evaluable under this vocabulary and MUST be treated by a relying party as if the state were absent. The evidence_set block of Section 5.3, where present, is the record of what was captured; the state is the record of what capturing it established.¶

Instrument failure. A verifier reporting any of the four states MUST distinguish reaching that state through evaluation from failing to evaluate because the verifier's own instrument failed. An implementation that could not complete its check --- a timeout, a crashed dependency, a malformed internal input --- MUST NOT report indeterminate or any other state as though it were a substantive finding. It MUST report the state the observation would otherwise carry (typically not_evaluated, or indeterminate where a partial check ran before failing) together with the reason code instrument_failure. instrument_failure is available under all four states for exactly this purpose: it marks the state as unreliable on account of the verifier's own tooling, not as a genuine result about the subject.¶

Reason codes under indeterminate. Two further reason codes distinguish why a check that ran did not resolve:¶

• divergence --- the check ran and found a divergence between sources or signals that the verifier cannot attribute to either side.¶
• absence --- the check ran and produced no signal at all. This name is retained from prior working-group usage rather than renamed, because the absence of a signal is a distinct and previously-established meaning that a synonym would obscure.¶

A verifier MUST choose divergence or absence for every indeterminate report that is not an instrument failure; the two are not interchangeable, and collapsing them discards exactly the distinction this section exists to preserve.¶

3.2. The Subject Clause

The subject of a state carrying an open attribution question between the artifact being evaluated and the evaluator that produced the state is a property of the observation, not of the code, verifier, or vantage point that produced it. A verifier reporting such a state MUST name what it observed, because the same signal observed from a different vantage is a different fact.¶

This clause generalizes a narrower formulation originally scoped to not_evaluated alone. A roll-up in which canonicalization disagreement and a forged signature both terminate in the same reported outcome shows that the same attribution question arises wherever a state's cause could be either the artifact or the evaluator, not only where no evaluation was performed. The clause therefore applies to indeterminate and contradicted reports carrying an unresolved artifact-vs-evaluator question exactly as it applies to not_evaluated.¶

3.3. Admissibility as a Gate, Not a State

Admissibility is a gate applied to an observation before evaluation: does this observation count at all. It is evaluated prior to, and independently of, the four states in Section 3.1, and it is not a fifth state alongside them.¶

An observation excluded at the admissibility gate (for example, one excluded on reconnaissance or scope grounds) never reaches state assignment and MUST NOT be reported using any of the four states. Admissibility and state occupy different axes: an admitted observation is then, and only then, evaluated to one of verified, contradicted, indeterminate, or not_evaluated.¶

4.1. Sibling-not-Member Relationship to environment.*

Both families produce a binary fail-closed gate primitive. They differ in predicate shape (boolean vs probabilistic) and threshold provenance (fixed vs calibration-anchored). This difference is sufficient to warrant a sibling family rather than a member entry under environment.*: probabilistic predicates require calibration discipline that boolean predicates do not, and the version-binding mechanism described in Section 5 is specific to mappings between probabilistic primitives and binary outputs.¶

Read sibling-to-sibling: environment.* attests a deterministic read of the world (state matches or does not, with a fixed-semantic threshold), while verification.* attests an irreducibly probabilistic statement about a proposition (calibration-anchored confidence over a claim, with a mapping-versioned threshold). Both produce the same binary gate output; they differ in what kind of fact the threshold is being applied to. This split is structural: the receipt envelope, JCS canonicalization, signed-primitives discipline, and offline-verifiable-against-published-JWKS verification model are identical across the two families. See [ENV-STATE] for the world-state-read sibling.¶

4.2. Composition Rules

Conjunction: Multiple verification.* constraints in a single mandate combine with AND (orthogonal+conjunctive). All constraints MUST resolve to act for the action to proceed.¶

Ordering with environment.*: environment.* constraints MUST short-circuit before verification.* constraints per [ENV-STATE] Section 5.5. Environment evaluation is typically cheaper (no oracle roundtrip) and a failed environment constraint moots the verification. See also Section 11 for the non-interference security property this ordering provides.¶

5.1. JWS Envelope

Verification receipts MUST be issued as JSON Web Signatures (JWS) [RFC7515]. Both compact serialization and JSON serialization (flattened form) are conforming. The v0.3 reference fixture pair uses JWS JSON (flattened) serialization because it preserves the protected/unprotected/signature object structure the verification protocol walks (Section 5.4); compact serialization remains valid for profiles that prefer it. A relying party MUST accept both serializations.¶

• alg: A conforming implementation MUST accept both EdDSA (Ed25519, [RFC8037]) and ES256 ([RFC7518]). The v0.3 reference fixture pair signs with EdDSA; ES256 remains valid for profiles that prefer it. Other algorithms are optional and SHOULD follow the IANA JOSE Algorithms registry.¶
• kid: MUST resolve to a key in the issuer's published JWKS [RFC7517] at /.well-known/jwks.json unless an alternate JWKS location is published in the issuer's metadata.¶
• typ: verification-receipt+jws.¶

5.2. Payload Claims --- Canonical, Derived, Mapping-Bound

The payload signs three structurally distinct field groups plus their bindings.¶

Canonical input (signed primitives):¶

• v_verdict (string, REQUIRED) --- One of verified, contradicted, indeterminate, not_evaluated, per Section 3. This revision changes the field's domain from draft-krausz-verification-state-01's supported/refuted/unverifiable/unknown values to this four-value vocabulary, one-for-one in that order; the claim name v_verdict itself is unchanged and continues to be emitted by existing issuers. A rename of the claim to v_state, to align the wire name with this vocabulary's own terminology, is deferred to a future revision pending an assessment of the migration cost across existing draft-krausz-verification-state-01 implementers; see Section 10.¶
• v_reason_code (string, REQUIRED when Section 3 requires one for the reported v_verdict, OPTIONAL otherwise) --- One of instrument_failure (available under any state), or, when v_verdict is indeterminate and the reason is not instrument_failure, exactly one of divergence or absence.¶
• v_subject (string, REQUIRED when v_verdict carries an open attribution question per Section 3.2, OPTIONAL otherwise) --- Names the specific observation the state describes, so that the same signal reported from a different vantage is identifiable as a different fact.¶
• v_confidence (number, REQUIRED) --- Float in [0, 1].¶
• v_adversarial_result (string, REQUIRED) --- One of resilient, vulnerable, not_checked.¶

Canonical derived (signed):¶

• v_recommendation (string, REQUIRED) --- One of confident_supported, un_probed_not_cleared, vulnerable_supported, weak_supported, refuted, unverifiable, error. Derived deterministically from the canonical input under the named mapping.¶

Derived output (signed):¶

• v_gate (string, REQUIRED) --- One of act, halt. Derived from v_recommendation under the named mapping.¶

Binding (signed):¶

• v_gate_mapping (string, REQUIRED) --- Stable identifier of the published mapping document used at issuance (e.g., v0.3.0-2026-05-30). The mapping document is immutable after publication; future revisions ship as new identifiers.¶
• v_gate_mapping_hash (string, REQUIRED) --- SHA-256 hex digest of the canonical serialization of the mapping document identified by v_gate_mapping. MUST be present in every receipt. Receipts MUST bind to a content-addressed mapping; the absence of v_gate_mapping_hash is a malformed-receipt condition and MUST result in gate decision halt.¶
• v_claim (object, REQUIRED) --- Binds the verified claim to the receipt. See Section 5.5.¶

Provenance (signed, not gating):¶

• v_method (string, OPTIONAL) --- Self-describing verifier pipeline identifier.¶
• v_calibration (object, OPTIONAL) --- Calibration anchor metadata. See Section 8.¶
• v_sources_used (array of strings, DEPRECATED) --- Source labels actually consulted in this evaluation. Deprecated by this revision in favor of evidence_set.sources (Section 5.3), which names sources with content-addressing rather than free-text labels. An issuer MAY still emit this member for backward compatibility; a relying party MUST NOT treat its absence as a defect, and MUST NOT treat its presence as evidence pinning.¶
• v_evidence (string, DEPRECATED) --- URI pointer to evidence corpus, if persisted. Deprecated by this revision in favor of evidence_set (Section 5.3), which pins content rather than pointing at a live location. An issuer MAY still emit this member for backward compatibility; a relying party MUST NOT treat its absence as a defect.¶
• evidence_set (object, OPTIONAL) --- Content-addressed record of the sources considered during verification. See Section 5.3 for its full structure.¶

Standard JWT claims [RFC7519]:¶

• iss (REQUIRED), sub (RECOMMENDED), iat (REQUIRED), exp (REQUIRED), nbf (OPTIONAL).¶

5.3. Evidence Pinning

A verification.* receipt pins the rule applied (via v_gate_mapping_hash) but, absent this section, carries sources as bare URIs. Recomputing a state therefore requires re-retrieving them, which is neither deterministic (the same URI returns different bytes over time) nor durable (a retrieval provider can retire). A receipt without evidence pinning is a pointer to evidence, not a record of it. This section closes that gap by letting a receipt carry a content-addressed evidence_set. Throughout, the evidence block states what was judged; it never states what the judgment was --- v_verdict and its reason code are untouched by anything in this section.¶

leaf = SHA-256( "ao-evidence-leaf-v2" || 0x00
                || url || 0x00
                || snippet_sha256 || 0x00
                || content_kind || 0x00
                || retrieved_at )

node = SHA-256( "ao-evidence-node-v1" || 0x00
                || left || 0x00
                || right )

5.4. Verification Protocol

A relying party verifying a receipt MUST execute the following sequence and treat any failure as a malformed receipt with gate decision halt:¶

1. Verify JWS signature against issuer's published JWKS
   (RFC 7515).
2. Resolve v_gate_mapping -> fetch the named immutable
   mapping document. MUST verify the SHA-256 digest of the
   fetched document matches v_gate_mapping_hash (hex-encoded).
   Digest mismatch -> malformed; gate decision = halt. This
   binding is mandatory; receipts without v_gate_mapping_hash
   are malformed.
3. Recompute candidate_recommendation from
   (v_verdict, v_confidence, v_adversarial_result)
   using the mapping's rules and the threshold recovered from
   the mapping document. v_verdict's domain depends on which
   revision issued the receipt -- this revision's four-value
   vocabulary, or draft-krausz-verification-state-01's
   supported/refuted/unverifiable/unknown domain for receipts
   issued before this revision -- as identified by the named
   mapping document.
4. Confirm candidate_recommendation == v_recommendation.
5. Compute candidate_gate = mapping(v_recommendation).
6. Confirm candidate_gate == v_gate.
7. If the receipt carries an evidence_set, resolve it per
   Section 5.4.1's evidence-set step below. This step resolves
   to "resolved" or "unknown" and never itself halts except
   on the malformed conditions Section 5.4.1 lists.
8. Verify exp/nbf against current time, subject to clock
   tolerance.
9. If all checks pass -> receipt is valid AND internally
   consistent under the named mapping. Any mismatch ->
   malformed; gate decision = halt.

The relying party never trusts the issuer's runtime to have applied the mapping correctly. The signature binds inputs, outputs, and mapping identifier together; the verifier recomputes locally.¶

5.5. Claim Binding

The verified claim MUST be bound to the receipt via v_claim:¶

"v_claim": {
  "text": "string (OPTIONAL when caller marks input
           as PII-sensitive)",
  "hash": "hex-encoded SHA-256 of canonicalized claim
           text (REQUIRED when text is omitted)"
}

Hash-only mode permits PII-sensitive verification while preserving the receipt's auditability --- the verifier can confirm a future caller's claim hash matches the issued receipt's bound hash without exposing the claim text.¶

5.6. Receipt Envelope Example

The following is a non-normative example of a receipt envelope payload illustrating the mandatory v_gate_mapping_hash binding alongside v_gate_mapping:¶

{
  "iss": "https://verifier.example.com",
  "sub": "claim:sha256:a3f1...",
  "iat": 1748649600,
  "exp": 1748736000,
  "v_verdict": "verified",
  "v_confidence": 0.91,
  "v_adversarial_result": "resilient",
  "v_recommendation": "confident_supported",
  "v_gate": "act",
  "v_gate_mapping": "v0.3.0-2026-05-30",
  "v_gate_mapping_hash": "sha256:1ad513cd0cfcc1...",
  "v_claim": {
    "hash": "a3f1c2d4e5b6789012345678abcdef01..."
  },
  "evidence_set": {
    "evidence_set_version": "ao-evidence-set-v1",
    "retrieved_at": "2026-09-01T12:00:00.000Z",
    "source_count": 2,
    "pinned_count": 2,
    "fully_pinned": true,
    "evidence_root": "c9f2...",
    "sources": [
      {
        "url": "https://example.com/report-a",
        "snippet_sha256": "6f2c...",
        "retrieved_at": "2026-09-01T12:00:00.000Z",
        "pinned": true,
        "content_kind": "snippet"
      },
      {
        "url": "https://example.com/report-b",
        "snippet_sha256": "a114...",
        "retrieved_at": "2026-09-01T12:00:01.000Z",
        "pinned": true,
        "content_kind": "snippet"
      }
    ]
  }
}

The v_gate_mapping_hash field carries the hex-encoded SHA-256 digest of the canonical serialization of the mapping document identified by v_gate_mapping. This field MUST be present in all conforming receipts; its absence is a malformed-receipt condition. The evidence_set member is illustrative and OPTIONAL; the digest values shown are truncated placeholders, not computed values, and MUST NOT be used as test vectors.¶

5.7. Version-Binding Rationale

Gate-derivation rules will evolve. A receipt issued under mapping v0.3.0-... MUST remain verifiable as correct-under-v0.3.0 after a newer mapping ships. The mapping identifier in v_gate_mapping is the binding that makes this true: a verifier fetches the same mapping document the issuer used at issuance, regardless of newer revisions. Receipts never silently re-verify to a different gate.¶

Mapping document publishers MUST treat published mappings as immutable. New rules ship under new mapping identifiers. Errata (typographical corrections only) MAY be appended to a published mapping document's metadata, but the normative rule tables MUST NOT change after first publication.¶

6.1. Decision Table

The reference mapping v0.3.0-2026-05-30 defines the following decision table, restated against this revision's four-state vocabulary. Future mappings MAY tighten or extend this table; the structural shape (binary act/halt output derived from canonical recommendation) MUST be preserved. The recommendation and gate vocabulary (confident_supported, un_probed_not_cleared, and so on) is unchanged from draft-krausz-verification-state-01 in this revision; see Section 10.¶

Independent of the mapping table above: this revision requires that an issuer reporting v_reason_code: instrument_failure MUST derive v_recommendation: error and MUST derive v_gate: halt, regardless of which of the four states instrument_failure is attached to. This rule cannot be part of mapping v0.3.0-2026-05-30 itself --- that mapping predates the reason-code vocabulary and, per Section 5.7, published mappings are immutable and MUST NOT be amended to add it. Applying this rule in practice therefore requires a future mapping revision that encodes reason-code-aware derivation explicitly; this is the gap Open Issue 4 (Section 10) names.¶

This table maps the four states onto the same recommendation/gate structure draft-krausz-verification-state-01 defined for its four raw-verdict values, one-for-one in declaration order (verified from supported, contradicted from refuted, indeterminate from unverifiable, not_evaluated from unknown). It does not yet give the recommendation layer its own reason-code-aware treatment; that is deferred, and named explicitly in Section 10 rather than silently assumed.¶

6.2. Threshold Rules

The confidence threshold used to derive v_recommendation is specified in the named mapping document, not in the individual receipt. Receipts reference the mapping by v_gate_mapping identifier, and the threshold is recovered from that mapping. This ensures that the threshold is auditable, versioned, and consistent across all receipts issued under the same mapping: two receipts under the same mapping ID MUST gate against the same threshold; threshold changes require a new mapping version with a new ID.¶

For a strict fail-closed gate, un-probed adversarial state is not equivalent to resilient --- it represents uncertainty about a dimension that can be exploited by adversarial input. Per the fail-closed property, uncertainty MUST halt. A claim may be confidently supported on its face, but if adversarial probing was not performed, the confidence applies only to the base claim, not to the claim under adversarial pressure. The un_probed_not_cleared recommendation reflects this: the gate treats the absence of probing as a distinct unresolved risk, not as a cleared risk.¶

Relying parties MAY require a higher threshold mapping for their own gate policies by requiring receipts under a different mapping ID that specifies a higher threshold. They MUST NOT treat a receipt as conformant under a mapping that specifies a different threshold than the one in that mapping document.¶

6.3. Fail-Closed Mandate

If a receipt is missing, malformed, expired, signature-invalid, or its mapping ID cannot be resolved, the relying party MUST treat the gate decision as halt. Implementations MUST NOT default to act under any error condition. This is the "impossible, not tedious" design principle: friction-based controls bypass under adversarial pressure; hard barriers do not.¶

7.1. Three Independent Axes

Verification receipts have three independent staleness axes, each with its own validity window:¶

This revision anchors the evidence axis to evidence_set.retrieved_at rather than a separately declared valid_until. v_evidence and its valid_until convention are deprecated per Section 5.2; a relying party computing evidence-axis staleness for a receipt that carries an evidence_set MUST use its retrieved_at, not a declared expiry, since freshness is a fact about when the evidence was captured rather than a duration the issuer asserts it remains good for.¶

7.2. Staleness Semantics

• Stale signature --- Receipt is invalid; relying party MUST treat as halt.¶
• Stale calibration --- Receipt SHOULD be re-evaluated; relying party MAY honor as soft-stale per its own policy. Verifier issuers SHOULD publish recalibration cadence in metadata.¶
• Stale evidence --- Receipt SHOULD be re-evaluated. MAY be honored for retrospective audit purposes (e.g., post-incident review of a past action) but MUST NOT be honored as a gate signal for new actions.¶

Each axis has a different remediation path; collapsing them into a single TTL would force the most-restrictive cadence to govern all three.¶

8.1. Reproducibility Mandate

Verifier issuers MUST publish:¶

• Anchor dataset name and version.¶
• Anchor seed (or seeded run identifier).¶
• Anchor scoring methodology.¶

Verifier issuers SHOULD publish a reference reproduction harness under a permissive open-source license (Apache 2.0, MIT, or BSD). A working reference implementation reproduced 57.6% on AVeriTeC [AVERITEC], measured 28 May 2026 on the pre-migration Sonar-backed pipeline. It is available at https://github.com/TKCollective/agentoracle-eval-harness as one example of conformance.¶

8.2. Drift Detection

Verifier issuers SHOULD publish a recalibration cadence in the JWKS metadata or the verifier's well-known endpoint. The v_calibration.valid_until field in receipts SHOULD reflect this cadence. Relying parties consuming receipts with stale calibration SHOULD log and surface the staleness rather than silently accept.¶

9.1. SCITT

RFC 9943 [RFC9943] --- the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture, published as a full RFC in June 2026 --- defines the SCITT signing and receipt-envelope architecture, superseding the individual/WG draft draft-ietf-scitt-architecture cited by draft-krausz-verification-state-01. This document is SCITT-compatible: a verification.* receipt MAY be wrapped in a SCITT envelope, and SCITT receipts MAY carry verification.* payloads. RFC 9943 specifies the signing infrastructure; this document specifies a gate primitive that may be transported via SCITT or via plain JWS.¶

RFC 9942 [RFC9942] defines CBOR Object Signing and Encryption (COSE) Receipts, also published June 2026. Where a SCITT transparency service issues a COSE Receipt over a verification.* payload, the two receipt layers are complementary and independently verifiable: the COSE Receipt attests registration in a transparency log; the verification.* JWS attests the pre-action gate decision itself. This document takes no normative dependency on RFC 9942 and does not require a relying party to consult a transparency log to verify a verification.* receipt on its own terms.¶

9.2. Relationship to Decision Records

Related work on decision records for AI agent actions is in progress, notably [I-D.sirkkavaara-vaara-receipt]. The two documents describe different things, and this document states its own boundary explicitly rather than leaving it to be inferred from adjacency:¶

A pre-action verification record, as specified here, establishes whether the factual claims an action rests on were checked, against which evidence, and with what result --- which a decision record does not. See [I-D.sirkkavaara-vaara-receipt] for related work; this document makes no claim about what that specification establishes, and neither format depends normatively on the other.¶

9.3. RATS

RFC 9334 [RFC9334] defines the Remote Attestation Architecture's Evidence->Verifier->Attestation Result->Relying Party vocabulary. A verification.* receipt is an Attestation Result whose gate field (v_gate) is the RP-consumable primitive. This document is consistent with the RATS vocabulary and may be considered a verification-specific Attestation Result profile.¶

9.4. W3C VC Confidence Method

The W3C Verifiable Credentials Confidence Method [VC-CM] defines confidence-as-a-verifiable-property within Verifiable Credentials. This document adopts the same pattern for v_confidence (signed metadata, not gating). Confidence is provenance; the gate is the contract. Alignment, not overlap.¶

9.5. VAP Framework

The Verifiable AI Provenance Framework (VAP) [VAP-FW] is an individual Internet-Draft providing an architectural coordination layer for evidentiary-grade decision trails. A verification.* receipt issuer MAY be considered a verifier profile under the VAP umbrella. This citation is pinned to draft-kamimura-vap-framework-01 (21 July 2026); a future VAP revision may require this reference to be re-pinned.¶

9.6. Mastercard Verifiable Intent (environment.*)

The environment.* constraint family for pre-action attestation of environment state is specified in [ENV-STATE], as part of the Verifiable Intent framework [VINTENT]. This document extends the constraint-family pattern to probabilistic predicates with calibration discipline, as a sibling family rather than a member entry. See Section 4.¶

9.7. Differentiator Summary

Pre-action fail-closed gate. Not signing machinery (covered by SCITT). Not confidence quantification (covered by W3C VC CM). Not just an Attestation Result (covered by RATS). The gate primitive itself, with the version-binding necessary to outlive ruleset evolution.¶

11.1. Composition Non-Interference with environment.* Family

When verification.* composes alongside environment.* on the same mandate, the ordering specified in Section 4.2 (environment.* short-circuits before verification.*) MUST hold. This document inherits that ordering directly from [ENV-STATE] Section 5.5, which specifies that environment.* is not subject to ordering preemption by any other constraint family. A verification.* ACT outcome MUST NOT mask an environment.* HALT outcome; if environment.* halts on any constraint, that halt is final regardless of the verification.* state. Implementations MUST evaluate environment.* to its terminal state before evaluating any verification.* constraint, and a verification.* state SHALL NOT be reached if environment.* has already halted.¶

11.2. Other Security Considerations

Key compromise. Verifier issuers MUST rotate JWKS keys on a published cadence. Receipts signed under a compromised key remain verifiable against historical key state during the rotation horizon. RPs MUST honor key revocation lists where published.¶

Replay attacks. Receipts include iat and exp. RPs MUST verify both against current time, subject to clock tolerance. Claim-binding via v_claim.hash provides resistance to receipt-reuse against a different claim payload.¶

Confidence inflation attacks. A verifier issuer who inflates v_confidence to push more receipts to act would diverge from their published calibration anchor. The reproducibility mandate (Section 8) makes this detectable. RPs SHOULD periodically sample receipts against the issuer's published harness.¶

Selective disclosure. Hash-only claim binding (Section 5.5) permits PII-sensitive verification without exposing claim text in the receipt envelope.¶

Downgrade attacks. A future relying party MUST NOT accept a v0.3-spec receipt against a v0.4-spec gate. The receipt format version is implicitly bound by v_gate_mapping; mismatches between expected and signed mapping IDs are malformed-receipt conditions per Section 5.4.¶

Mapping document tampering. Receipts MUST bind to a content-addressed mapping via the v_gate_mapping_hash field (SHA-256). Mapping documents MUST be hosted such that the SHA-256 digest of the canonical serialization is stable and independently verifiable (e.g., at a content-addressed URL or via a git-tagged manifest). Verifier implementations MUST verify the SHA-256 digest of the fetched mapping document against v_gate_mapping_hash before use; a digest mismatch MUST result in gate decision halt. A relying party that cannot independently verify the mapping document's hash MUST treat the receipt as malformed.¶