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. 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 4 is specific to mappings between probabilistic primitives and binary outputs.¶

3.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] §5.5. Environment evaluation is typically cheaper (no oracle roundtrip) and a failed environment constraint moots the verification. See also Section 9 for the non-interference security property this ordering provides.¶

4.1. JWS Envelope

Verification receipts MUST be issued as JSON Web Signatures (JWS) [RFC7515] in compact serialization.¶

• alg: ES256 mandatory. Other algorithms optional and SHOULD follow 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.¶

4.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 supported, refuted, unverifiable, unknown.¶
• 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, 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.¶

Provenance (signed, not gating):¶

• v_method (string, OPTIONAL) --- Self-describing verifier pipeline identifier.¶
• v_calibration (object, OPTIONAL) --- Calibration anchor metadata. See Section 7.¶
• v_sources_used (array of strings, OPTIONAL) --- Source labels actually consulted in this evaluation.¶
• v_evidence (string, OPTIONAL) --- URI pointer to evidence corpus, if persisted.¶

Standard JWT claims [RFC7519]:¶

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

4.3. 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.
4. Confirm candidate_recommendation == v_recommendation.
5. Compute candidate_gate = mapping(v_recommendation).
6. Confirm candidate_gate == v_gate.
7. Verify exp/nbf against current time, subject to clock tolerance
   per Section 6.
8. If all match -> 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.¶

4.4. 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.¶

4.5. 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": "supported",
  "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:1ad513cd0cfcc1fcd78136375268ba85c50cc267de8d9f92a9a3e61f5d672288",
  "v_claim": {
    "hash": "a3f1c2d4e5b6789012345678abcdef0123456789abcdef0123456789abcdef01"
  }
}

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.¶

4.6. 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.¶

5.1. Decision Table

The reference mapping v0.3.0-2026-05-30 defines the following decision table. Future mappings MAY tighten or extend this table; the structural shape (binary act/halt output derived from canonical recommendation) MUST be preserved.¶

5.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.¶

5.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.¶

6.1. Three Independent Axes

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

6.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.¶

7.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 reproducing 57.6% on AVeriTeC [AVERITEC] is available at https://github.com/TKCollective/agentoracle-eval-harness as one example of conformance.¶

7.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.¶

8.1. SCITT

The SCITT WG architecture document [SCITT] defines the Supply Chain Integrity, Transparency, and Trust signing and receipt envelope. This document is SCITT-compatible: a verification.* receipt MAY be wrapped in a SCITT envelope, and SCITT receipts MAY carry verification.* payloads. SCITT specifies the signing infrastructure; this document specifies a gate primitive that may be transported via SCITT or via plain JWS.¶

8.2. 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.¶

8.3. 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.¶

8.4. VAP Framework

The Verifier Abstraction Pattern framework [VAP-FW] is an individual Internet-Draft providing verifier abstraction conventions. A verification.* receipt issuer MAY be considered a verifier profile under the VAP umbrella. (Editorial note: this section's citation MUST be pinned to a specific VAP version at submission time; individual drafts move and expire.)¶

8.5. 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 3.¶

8.6. 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.¶

9.1. Composition Non-Interference with environment.* Family

When verification.* composes alongside environment.* on the same mandate, the ordering specified in §3.2 (environment.* short-circuits before verification.*) MUST hold. This document inherits that ordering directly from [ENV-STATE] §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.¶

9.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 7) makes this detectable. RPs SHOULD periodically sample receipts against the issuer's published harness.¶

Selective disclosure. Hash-only claim binding (Section 4.4) 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 4.3.¶

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.¶