TK Collective LLC

USA joe@tanilo.io

General agent verification receipt JWS gate AI evidence pinning This document specifies the verification.* constraint family --- a pre-action, fail-closed gate primitive for AI agent decisions, sibling in shape to the environment.* family used in Verifiable Intent specifications. A verification.* receipt is a JSON Web Signature (JWS) signed artifact carrying a canonical input, a derived binary act/halt output, and a versioned mapping identifier that binds them. A relying party recomputes the gate locally from signed primitives under the named mapping; the verifier never trusts the issuer's runtime. This revision replaces the raw verdict domain of draft-krausz-verification-state-01 (supported/refuted/unverifiable/unknown) with a four-state vocabulary --- verified, contradicted, indeterminate, and not_evaluated --- together with a reason-code mechanism that separates a state's substance from a verifier's own instrument failure, and with an admissibility gate applied before a state is ever assigned. It adds evidence pinning: a receipt MAY carry an evidence_set block that content-addresses the sources considered during verification, so that a verdict can be recomputed offline from the receipt and the pinned bytes alone, without depending on a live retrieval provider. Freshness is anchored to the evidence's own retrieved_at timestamp rather than a separately declared validity window. This shape provides decision explainability and traceability evidence aligned with EU AI Act Article 12 record-keeping obligations and with the Decision Explainability tier of an industry Zero Trust for AI Agents framework published in 2026. The format is forward-compatible across mapping revisions: receipts signed under one mapping ID remain verifiable as correct-under-that-mapping after newer mappings ship. The vectors that content-address a mapping document or an evidence set are historical, digest-anchored artifacts and are unchanged by this revision; nothing in this document alters a previously issued digest.

Introduction AI agents increasingly take economic and operational actions on probabilistic input. A customer-service agent posts content; a procurement agent commits to a supplier; a research agent files a regulatory report. Each action is preceded by a factual claim the agent believes to be true. Today, the infrastructure verifying whether the claim is true before the agent acts on it is fragmented across operator logs (after-the-fact), confidence scores (soft signals), and ad-hoc validation pipelines (not interoperable). This document specifies the verification.* constraint family: a pre-action, fail-closed gate primitive shaped identically to the environment.* family used in Verifiable Intent specifications , but applied to probabilistic predicates rather than boolean state. A verification.* receipt asserts, for a specific claim under a specific ruleset at a specific moment, whether an agent SHOULD proceed or halt. The receipt is JWS-signed and structured such that a relying party can recompute the gate decision locally from signed primitives, without trusting the issuer's runtime. The four properties this primitive needs to satisfy together:

1. Pre-action. The verification happens before the action.
2. Fail-closed. Anything ambiguous halts; "impossible, not tedious."
3. Third-party recomputable. The verifier never trusts the issuer's runtime; signature binds inputs, outputs, and mapping identifier together.
4. Forward-compatible. Receipts signed under one ruleset remain verifiable as correct-under-that-ruleset even after newer rulesets ship.

Property 3 is the load-bearing one and the one most existing primitives stop short of. SCITT signs receipts (necessary but not sufficient). W3C Verifiable Credentials Confidence Method exposes confidence as a verifiable property (useful but not gating). RATS provides the Evidence->Verifier->AR->RP vocabulary (matched here). None fully recompose the gate verdict from signed inputs. Property 4 is the one that becomes a footgun if skipped: rule changes silently invalidate or mis-verify old artifacts. This document is complementary to security frameworks for AI agent deployment, including the Zero Trust framework for AI Agents published by Anthropic in May 2026 , which names decision explainability as non-optional for regulated AI systems. The verification.* constraint family is one credible artifact shape for satisfying that explainability requirement.

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 when, and only when, they appear in all capitals, as shown here.

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.

Terminology Verifier --- Entity issuing a verification receipt. Relying Party (RP) --- Agent or downstream system consuming the receipt at a gate. Gate --- The decision point in the RP's code path where act / halt is consumed. Calibration anchor --- The dataset and seed defining confidence semantics for the verifier's pipeline. Multi-axis freshness --- Signature, calibration, and evidence each carry independent staleness exposure. As of this revision the evidence axis is computed from evidence_set.retrieved_at rather than from a separately declared validity window; see . State (raw) --- One of verified, contradicted, indeterminate, not_evaluated. See for the full vocabulary, its reason codes, and the admissibility gate applied before a state is assigned. This replaces the supported/refuted/unverifiable/unknown domain of draft-krausz-verification-state-01. Reason code --- A machine-readable qualifier carried alongside a reported state that distinguishes how the state was reached. See . Subject --- The specific observation --- not the code, verifier, or vantage point that produced it --- that a reported state describes. See . Admissibility --- A gate applied to an observation before evaluation: whether the observation counts at all. Distinct from the four states, which describe the outcome of evaluating an admitted observation. See . Recommendation (canonical) --- One of confident_supported, un_probed_not_cleared, vulnerable_supported, weak_supported, refuted, unverifiable, error. Derived from primitives under the named mapping. The mapping's own vocabulary is retained unchanged from draft-krausz-verification-state-01 pending a future revision; see . Gate (derived) --- act or halt. Derived from recommendation under the named mapping. Mapping document --- A published, immutable document specifying how recommendations are derived from primitives and how gates are derived from recommendations. Identified by a stable string identifier (e.g., v0.3.0-2026-05-30). Evidence item --- A single retrieved source considered during verification, identified by its URI and, when pinned, by a cryptographic digest of the retrieved content. Evidence set --- The complete, unordered collection of evidence items considered during one verification, together with the metadata that makes it recomputable. Pinned --- An evidence item is pinned when the receipt carries a digest of the retrieved content, such that a verifier holding the same content can confirm it is the content that was judged. An item carrying a URI alone is not pinned. Offline recomputation --- Re-derivation of a verification outcome from the receipt, the referenced mapping document, and the pinned evidence content alone, without contacting the issuer or any retrieval provider.

Verification State Vocabulary This section replaces the raw verdict domain of draft-krausz-verification-state-01 with a four-state vocabulary, a reason-code mechanism, a generalized subject clause, and an admissibility gate applied before any state is assigned. It reflects working-group discussion current as of 2026-09-22, including wg-identity #21 and tsc #4 threads.

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 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 () 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 , 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.

Enumerating the Negatives Behind an Indeterminate Count Committed 2026-09-16 as a direct consequence of a natural experiment comparing HTTP 429 responses across two hosts, one returning over three thousand and the other returning zero, where the zero count was a fact about the requester's own standing with the host and not about the host's behavior: Before an implementation or a report built on this vocabulary publishes any count of the form "N subjects are not doing X," it MUST enumerate the status codes behind the negatives. A negative built from a status about the asker --- the verifier's own instrument, vantage point, or standing --- is not a negative about the subject being observed, and MUST be attributed to instrument_failure or absence as appropriate rather than folded into a substantive contradicted or indeterminate count.

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.

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

The verification.* Constraint Family

Sibling-not-Member Relationship to environment.*

Property	environment.*	verification.*
Predicate	Boolean (state matches or does not)	Probabilistic in [0,1]
Threshold ownership	Oracle-defined, fixed-semantic	Calibration-anchored, mapping-versioned
Freshness	Single TTL	Multi-axis
Gate shape	Binary halt	Binary halt

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 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 for the world-state-read sibling.

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

Receipt Format

JWS Envelope Verification receipts MUST be issued as JSON Web Signatures (JWS) . 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 (); 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, ) and ES256 (). 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 at /.well-known/jwks.json unless an alternate JWKS location is published in the issuer's metadata.
• typ: verification-receipt+jws.

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 . 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 .
• v_reason_code (string, REQUIRED when 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 , 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 .

Provenance (signed, not gating):

• v_method (string, OPTIONAL) --- Self-describing verifier pipeline identifier.
• v_calibration (object, OPTIONAL) --- Calibration anchor metadata. See .
• v_sources_used (array of strings, DEPRECATED) --- Source labels actually consulted in this evaluation. Deprecated by this revision in favor of evidence_set.sources (), 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 (), 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 for its full structure.

Standard JWT claims :

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

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.

The evidence_set Member A receipt payload MAY carry an evidence_set member. When present it MUST be an object with the following members:

evidence_set_version (string):

Version identifier for this block's semantics. This document defines "ao-evidence-set-v1".

retrieved_at (RFC 3339 timestamp):

MUST equal the bytewise-least retrieved_at among all entries in sources, pinned and unpinned alike, comparing the UTF-8 bytes of the member as carried. Well-defined because sources is non-empty and every entry carries the member. A value that is not the bytewise-least such value is malformed; gate decision = halt; reported condition set_retrieved_at_not_bytewise_least.

source_count (integer):

Total number of evidence items considered. MUST equal len(sources) and MUST be greater than zero: a present evidence_set MUST carry at least one entry in sources. An issuer with no sources to report MUST omit evidence_set entirely; resolves that case as unknown for the evidence step without failing it. Reported condition on violation: evidence_set_names_no_sources.

pinned_count (integer):

Number of entries with pinned: true. MUST be less than or equal to source_count.

fully_pinned (boolean):

true if and only if pinned_count equals source_count and source_count is greater than zero.

evidence_root (string or null):

Merkle root over the pinned items per , or null when pinned_count is zero. MUST be non-null when pinned_count is greater than zero.

sources (array):

One entry per evidence item, per .

fully_pinned is stated rather than left to be derived, so a reader can determine that a set is partial without recounting the array. Partial pinning is an honest state and is not a defect; concealing it is. Zero pinned items is legal and is not an empty set: an evidence_set naming three sources, none pinned and each carrying a valid unpinned_reason, is well-formed, its evidence_root is null, and its fully_pinned is false. The prohibition is on a set naming no sources, never on one that pins none. Fallback when a count is declared absent. When source_count is absent, its operand for any check in this section is len(sources). When pinned_count is absent, its operand is the count of entries with pinned: true (well-defined because pinned is REQUIRED and boolean per ). When source_count, pinned_count, and fully_pinned are all absent, resolution derives all three the same way and MUST NOT halt for want of the declared members: validation and resolution alike are not skipped merely because a member that could be reconstructed from sources was not declared.

Source Entries Each entry in sources MUST be an object with:

url (string, REQUIRED):

The URI used for retrieval, carried without normalization --- no case folding, percent-encoding changes, query reordering, or trailing-slash adjustment.

snippet_sha256 (string or null, REQUIRED):

Lowercase hex SHA-256 of the retrieved content bytes exactly as received --- no transcoding, trimming, whitespace collapsing, case folding, or Unicode normalization --- or null if not pinned. There is no character-encoding step: the digest is over bytes, not over text.

retrieved_at (RFC 3339 timestamp, REQUIRED):

Retrieval time for this item. MUST be in UTC with the Z designator and exactly three fractional-second digits. This canonical form is required for every entry, pinned and unpinned alike, evaluated before any branch on pinned, because the sort in and the set-level comparison above are both bytewise. Reported condition on violation: retrieved_at_not_canonical_form.

pinned (boolean, REQUIRED):

MUST be exactly the JSON value true or false. An entry where pinned is absent, null, or of any type other than boolean is malformed; gate decision = halt; reported condition pinned_absent_or_not_boolean. This closes the domain to exactly two values before any rule in this document that ranges "over every entry, pinned and unpinned alike" is evaluated.

content_kind (string or absent/null, REQUIRED when pinned is true):

One of snippet, excerpt, full_resource, naming what the digest covers. On an unpinned entry, content_kind MUST be absent or null (the two are equivalent); on a pinned entry it MUST be present.

resource_sha256 (string, OPTIONAL):

Digest of the full resource, where the full resource was also obtained. MUST be absent when content_kind is full_resource (in that case snippet_sha256 already is that digest). This rule ranges over every entry regardless of pinned: an unpinned entry carrying content_kind: full_resource together with a non-null resource_sha256 is malformed under the same rule as a pinned one. Reported condition: snippet_digest_present_for_full_resource.

unpinned_reason (string, REQUIRED when pinned is false):

One of no_content_returned (the retrieval attempt returned no content bytes --- covers refusal, paywall interception, robots exclusion, and transport failure alike) or provider_metadata_only (the retrieval surface returned metadata about a resource without its content).

Possession, not composition. An issuer MUST pin every evidence item for which it received content bytes; pinned MAY be false only where no content bytes were received for that item. The digest is computed over the content bytes as received, before or alongside any judgement; whether the bytes are kept afterward is irrelevant to pinning. An item with pinned: false and no unpinned_reason, or a value outside the two-value domain above, is malformed; gate decision = halt. An issuer that received content bytes for an item and declares either unpinned_reason value has signed a false statement: the format cannot verify possession from the receipt, but it converts selective pinning from a permitted state into a lie. A composition rule --- pin every source that refutes the state --- cannot be written, because "refutes" is the issuer's own classification; possession is different in kind because whether bytes arrived is a fact about the issuer's own process, not a judgment about a source. Entry distinctness. No two entries in sources may record the same retrieval. Two entries record the same retrieval when they are identical in url and retrieved_at and, where both are pinned, also identical in snippet_sha256 and content_kind. This rule ranges over every entry in sources, pinned and unpinned alike: sources carries one entry per item considered, an issuer MUST NOT omit an item it could not pin, and a second entry for one retrieval overstates source_count. For an unpinned entry snippet_sha256 is null and content_kind is absent, so those members distinguish nothing and url with retrieved_at decides; an absent member is not equal to a present one. A pinned entry and an unpinned entry sharing url and retrieved_at are, by the same rule, one retrieval recorded twice. Two entries sharing url, snippet_sha256, and content_kind and differing only in retrieved_at record two legitimate retrievals of the same content and are not duplicates. Violation is malformed; gate decision = halt; reported condition duplicate_bound_tuple.

Evidence Root Construction evidence_root is a Merkle root over the pinned items only; unpinned items contribute nothing. Leaf. For each pinned item, in the canonical order defined below: where url and retrieved_at are their UTF-8 bytes as carried, snippet_sha256 is its 64 lowercase hexadecimal characters encoded UTF-8 (not the 32 raw bytes they represent), and content_kind is its UTF-8 bytes. No member may contain an octet 0x00, so delimiter injection is unreachable. Every member the preimage binds MUST also appear in the canonical sort key below, and the sort key MUST bind no member the preimage does not; any future widening of the preimage MUST extend the sort key in the same revision. Interior node. In the interior node, left and right are the 32 raw octets of the child digests, not their hexadecimal form. This differs from the leaf preimage deliberately: a leaf's members are values carried in the receipt as strings and enter as their UTF-8 bytes, whereas a node's children are outputs of this function and enter as the octets the function produced. The 0x00 separators in the node preimage are retained for consistency with the leaf form; unlike the leaf, they are not what makes the node preimage unambiguous, since both children are fixed-length 32-octet digests whose boundaries follow from position. A child digest may itself contain 0x00 octets, and this is harmless. Termination. When the pinned set contains exactly one item, evidence_root is that item's leaf; no interior node is formed. Applying the node function to a single leaf paired with itself is forbidden, for the same second-preimage reason the odd-node rule gives below. Odd node. When a level has an odd number of entries, the final entry is promoted unchanged to the next level, retaining its rightmost position. It MUST NOT be duplicated and paired with itself; duplication admits the well-known second-preimage ambiguity in which a tree with a duplicated final leaf and a tree with that leaf genuinely present twice produce the same root. Canonical order. Leaves are sorted ascending by url; where two entries share a url, by snippet_sha256; where they share both, by content_kind; and where they share all three, by retrieved_at. All four comparisons are bytewise over the UTF-8 encoding of the member as carried. The sort key is exactly the set of members bound by the leaf preimage, so two entries compare equal on the key only if their leaves are identical --- which the entry-distinctness rule above forbids within a well-formed set --- and the order is therefore total. Sorting makes the root independent of retrieval rank. Domain separation. The two distinct prefixes ensure a leaf hash can never be reinterpreted as an interior node, and that an evidence root can never collide with any other hash tree defined by this document or composed alongside it. When pinned_count is zero, evidence_root MUST be null; an implementation MUST NOT emit a root over an empty set.

What an Evidence Set Does Not Establish A pinned evidence set establishes that specific content was considered and that a verifier holding the same bytes can confirm it is the content that was judged. It establishes nothing about:

• Whether the source has since changed. A pinned digest lets a later holder of bytes determine whether they hold the bytes that were judged. It says nothing about whether the source at that URI has changed since, and a reader will take a weaker sentence the stronger way if this is not stated plainly.
• Completeness of disclosure. The set records what the issuer listed. This document forbids omitting a retrieved item, and nothing in the receipt can detect an omission; that is a rule against a false statement, not a mechanism that makes the statement's truth verifiable.
• The time of retrieval, independently vouched. retrieved_at is an issuer assertion with no external anchor. The digest therefore pins content as of a moment the issuer alone vouches for; an auditor years later holds the content and does not hold the moment.
• Unbiased selection. The format does not establish that a pinned subset was chosen without regard to the state being reported. What it establishes is that leaving a possessed item unpinned is a lie, and that any partial set makes no offline-recomputation claim.
• Why content was absent. no_content_returned records that no content bytes arrived. It does not distinguish a server that declined from an issuer that never requested, and the receipt cannot be made to: both are the same fact about the issuer's possession. This collapse is deliberate --- the possession rule reaches only items for which bytes actually arrived, and an issuer that never requested a source it should have requested is outside what this format establishes.

Independence An issuer MAY include an independence member within evidence_set, naming a method identifier, a distinct_registrable_domains count among pinned sources, and an implementation-defined score or null if not computed. This document does not define how independence is computed, and deliberately does not: a specific heuristic frozen into a specification becomes un-implementable by parties whose corpora differ and cannot be revised at the speed the problem moves. What is specified is the obligation to declare the method by identifier, so that two receipts carrying independence measures can be compared only when they name the same method. A verifier MUST NOT compare score values across differing method identifiers, and MUST NOT treat the absence of an independence member as a defect.

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

Evidence-Set Resolution Step A step defined in this document resolves to exactly one of two tokens: resolved, when the step's evidence requirements are met, or unknown, under the conditions stated below. An implementation MUST emit one of these two tokens for the evidence-set step and MUST NOT emit any other value. If the receipt carries an evidence_set, a relying party MUST resolve it as follows:

1. Verify source_count, pinned_count, fully_pinned, and set-level retrieved_at per (falling back to the derivations there when a count is absent); verify every entry against , including the possession rule, the entry-distinctness rule, and the pinned/content_kind/resource_sha256/retrieved_at-form rules. Any inconsistency is a malformed receipt; gate decision = halt; the implementation reports the specific violated condition named in the rule it failed. When a receipt violates more than one condition, an implementation MUST halt and MAY name any one of the violated conditions, except where this document states a precedence explicitly.
2. If evidence_root is non-null, recompute it from the sources entries per and compare. A mismatch is a malformed receipt; gate decision = halt; reported condition root_not_recomputable_from_sources. A pinned entry whose snippet_sha256 is absent or null MUST be rejected here, before any root computation is attempted --- gate decision = halt; reported condition snippet_sha256_absent_when_pinned --- rather than allowed to reach root construction and surface as a downstream error.
3. When fully_pinned is false (declared or derived), this step resolves unknown, and the receipt MUST NOT be presented as satisfying offline recomputation. This is a resolution of this step, not a member of the payload.
4. If the verifier holds candidate content for a pinned item, compute its SHA-256 and compare with snippet_sha256. A mismatch resolves unknown for that item and MUST NOT halt. The verifier's report MUST carry a per-item reason for every entry in sources, pinned and unpinned alike, distinguishing content_not_held from content_differs; an unpinned entry's reason is trivially content_not_held and MUST NOT be omitted from the report for being trivial. This distinction belongs in the report, never in the v_verdict domain: a verifier holding different bytes knows its bytes differ and does not know why.
5. A receipt carrying no evidence_set resolves unknown for this step and MUST NOT fail it. Receipts issued before this section existed remain valid and continue to verify exactly as before.
6. A properly declared partial evidence set is not invalid and the receipt is not malformed. An implementation MUST NOT treat an unknown resolution under (c) or (d) as a validity failure or a rejection.
7. A verifier MUST treat an unknown resolution as a distinct category and MUST NOT present it as a weaker or partial form of a satisfied offline-recomputation claim. A verifier that reports, displays, summarizes, or forwards an outcome MUST carry the distinction into whatever it emits.

Steps (a) and (b) are checks on the receipt's internal consistency and are answerable offline by any verifier. Step (d) is a check against external content and is answerable only by a verifier that holds it; a verifier that cannot obtain the content has learned nothing about the receipt's validity and MUST NOT report that absence as a defect in the receipt.

Claim Binding The verified claim MUST be bound to the receipt via v_claim: 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.

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

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.

Binary-Halt Gate Semantics

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 .

State	Conf.	Adversarial	Recommendation	Gate
verified	>= thr	resilient	confident_supported	act
verified	>= thr	not_checked	un_probed_not_cleared	halt
verified	any	vulnerable	vulnerable_supported	halt
verified	< thr	resilient	weak_supported	halt
verified	< thr	not_checked	weak_supported	halt
contradicted	any	any	refuted	halt
indeterminate	any	any	unverifiable	halt
not_evaluated	any	any	unverifiable	halt
error (see below)	n/a	n/a	error	halt

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 , 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 () 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 rather than silently assumed.

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.

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.

Multi-Axis Freshness

Three Independent Axes Verification receipts have three independent staleness axes, each with its own validity window:

Axis	Field	Remediation
Signature	exp	Key rotation; verifier MUST reject expired signatures
Calibration	v_calibration.valid_until	Recalibrate verifier pipeline against current anchor
Evidence	evidence_set.retrieved_at (OPTIONAL; falls back to per-source retrieved_at per when the set-level member is absent)	Re-retrieve and re-pin evidence; usually shorter window than calibration

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

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.

Calibration Anchor Requirements

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

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.

Relationship to Related Work

SCITT RFC 9943 --- 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 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.

Relationship to Decision Records Related work on decision records for AI agent actions is in progress, notably . 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 for related work; this document makes no claim about what that specification establishes, and neither format depends normatively on the other.

RATS RFC 9334 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.

W3C VC Confidence Method The W3C Verifiable Credentials Confidence Method 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.

VAP Framework The Verifiable AI Provenance Framework (VAP) 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.

Mastercard Verifiable Intent (environment.*) The environment.* constraint family for pre-action attestation of environment state is specified in , as part of the Verifiable Intent framework . This document extends the constraint-family pattern to probabilistic predicates with calibration discipline, as a sibling family rather than a member entry. See .

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.

Open Issues This section names what this revision does not settle, so that it is tracked rather than silently assumed resolved.

1. Independent implementation of evidence pinning is still pending. Every implementation run against the evidence-pinning rules to date () has extended an existing implementation rather than been built cold from the specification text alone. A from-text reconstruction is understood to be in progress. Until an independent cold build lands and is cross-checked, this document does not claim evidence pinning has had an independent implementation in the sense its own conformance discipline requires; that remains an open issue tracked here rather than a precondition for submission.
2. The malformed-condition enumeration diff. This document's evidence-pinning rules name a set of reported conditions (pinned_absent_or_not_boolean, duplicate_bound_tuple, evidence_set_names_no_sources, set_retrieved_at_not_bytewise_least, retrieved_at_not_canonical_form, snippet_digest_present_for_full_resource, snippet_sha256_absent_when_pinned, and others named inline above). Whether this list is complete against every malformation the specification text actually states has not been verified name-for-name against an independent enumeration, and remains open.
3. The pinned-and-unpinned duplicate-identity pair. A pinned entry and an unpinned entry sharing url and retrieved_at are treated as one retrieval recorded twice under the entry-distinctness rule of , but no conformance vector in the companion fixture corpus currently exercises that specific pair. Candidate for a future revision.
4. The recommendation and gate mapping vocabulary is unrenamed. maps the new four-state vocabulary onto draft-krausz-verification-state-01's existing v_recommendation values (confident_supported, un_probed_not_cleared, and so on) one-for-one by position. Those values still read as though derived from a supported/refuted axis. Whether the recommendation layer should itself be restated in reason-code-aware terms is not resolved here.
5. REQUIRED members with a derivation fallback. marks source_count, pinned_count, and fully_pinned as members of the evidence_set object while also specifying that a verifier MUST derive each from sources when it is absent. This document treats the two statements as compatible --- REQUIRED for the object's shape, with a stated fallback rather than a validation failure when an issuer omits one --- but a future revision should either soften the member table's language or state the fallback as the sole requirement.
6. The capture relationship, as stated in , is this document's own formulation of a term used without further gloss in working-group discussion. Comments are invited on whether it matches that usage.
7. The v_verdict claim name is unrenamed. gives the claim a new four-value domain this revision but keeps its existing wire name, v_verdict, rather than renaming it to v_state to match the vocabulary's own terminology, because a rename is a breaking wire change against every draft-krausz-verification-state-01 implementer and against production issuance that emits v_verdict today. Whether and how to rename the claim is deferred to a future revision, pending an assessment of migration cost across existing implementers.
8. The media-type registration request is incomplete. names verification-receipt+jws as a media type to be registered but does not supply the RFC 6838 registration template or state the top-level media type (application/) the subtype registers under. A complete template is deferred to a future revision.

Security Considerations

Composition Non-Interference with environment.* Family When verification.* composes alongside environment.* on the same mandate, the ordering specified in (environment.* short-circuits before verification.*) MUST hold. This document inherits that ordering directly from 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.

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 () makes this detectable. RPs SHOULD periodically sample receipts against the issuer's published harness. Selective disclosure. Hash-only claim binding () 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 . 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.

IANA Considerations This document requests the following IANA registrations: Media type: verification-receipt+jws (to be registered in the IANA Media Types registry following the procedures of RFC 6838). JWT claim names: v_verdict, v_reason_code, v_subject, v_confidence, v_adversarial_result, v_recommendation, v_gate, v_gate_mapping, v_gate_mapping_hash, v_method, v_calibration, evidence_set, v_claim (to be registered in the JSON Web Token Claims registry; v_verdict was already registrable under draft-krausz-verification-state-01, and this revision changes its domain per rather than replacing the claim name). v_sources_used and v_evidence remain registrable for the receipts issued under draft-krausz-verification-state-01 that carry them, and are marked DEPRECATED for new issuance per rather than withdrawn from the registry. Well-known URI: Verification issuers using HTTPS SHOULD publish their JWKS at /.well-known/jwks.json per existing Section 4.7 conventions. No new well-known URI is requested. The verification.* and environment.* constraint families are related sibling namespaces. Coordination on a joint constraint-family registry shared with the environment.* family () is deferred to all interested parties (Krausz, Borthwick, Msebenzi) for resolution outside the scope of this document. This document does not commit to a specific registry structure, nor does it assert agreement from the environment.* authors on any registry arrangement. The cross-referencing between verification.* and environment.* as related constraint families stands as documented, independent of any future registry decision.

Informative References Anthropic PDF, 36 pages World Wide Web Consortium W3C Working Draft Verifiable Intent Working Group Verifiable Intent Working Group Draft v0.1

Acknowledgments This revision's evidence-pinning and four-state vocabulary work drew on review, defect reports, and external comparison from a number of people, each credited here for their specific, actual contribution rather than a generic thanks:

• Michael Msebenzi (headlessoracle/LembaGang) reconstructed the evidence-pinning rules by extending an existing implementation across revisions 6 through 8, identified the arithmetic and encoding defects recorded across the findings referenced in , and independently reran cross-format verification of the composed receipt envelope to VALID after each correction. His work is the largest single source of the corrections this document incorporates, and is also the reason distinguishes confirmed-by-extension from a cold build.
• Pote (poteshniy) identified the 3-of-5 pinned-evidence defect, proposed the signed_only-to-bytes_attested rename adopted in the evidence-pinning rules, signed off on revision 7, and separately reviewed the v0.4 extension queue, surfacing the optional-typ, filtered-canonicalization, attacker-selected-snapshot, unsigned-anchor, underspecified-proof, and null-ambiguity findings that shaped the sealed-evidence review branch.
• Pablo Play proposed an alternate reading of Finding 35 that is preserved in the evidence-pinning rules, and is undertaking the from-text cold reconstruction of the evidence-pinning specification that tracks as an open item.
• Melchiorre Oliva ran the natural experiment behind --- a live measurement across two hosts returning 3,008 negative results on one and zero on the other under HTTP 429 conditions, committed 16 September 2026 --- and is the source of the operative test this document adopts for enumerating status codes behind a negative before it is published.
• navigatorbuilds (Elara Protocol) supplied the Status/Check/Verdict roll-up example that generalizes from, and separately audited thirteen production call sites of their own three-outcome verifier's absence-side state, confirming by direct count that the finding/absence distinction this document draws in matches how that state has actually been used in already-published rows.
• babyblueviper1 confirmed, in the same cross-project naming discussion, that their own conformance-registry taxonomy had no published enum requiring remapping under the finding/absence split, and endorsed that split as the correct cut.
• Marcus Still (stillmarcus24) published a four-state verification taxonomy --- AGREE/DISAGREE/INDETERMINATE/NOT_EVALUATED, with a ten-case executable acceptance contract, in x402 TSC issue #4 --- which served as this document's external compatibility reference point for its own four-state design. He confirmed 7 of 7 absence-side production call sites at commit 901ca6a, then endorsed the four states plus reason-code mechanism adopted in on x402 TSC issue #4 on 2026-09-20.
• Henri Sirkkavaara proposed the shape of the boundary statement in --- that it state what a pre-action verification record establishes that a decision record does not, and stop there, without characterizing his own specification.