The evidence.* Family: Post-Hoc, Independently Recomputable Evidence Records for AI Agent Actions

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 [BCP14] (RFC2119) (RFC8174) when, and only when, they appear in all capitals, as shown here.¶

1.2. Scope

In scope:¶

• The membership criterion for the evidence.* family.¶

• The family-wide record vocabulary and canonicalization discipline.¶

• One reference record type, evidence.action, specified field by field.¶

• The tri-state verification protocol a verifier executes.¶

• Composition with the pre-action sibling families.¶

• The conformance-vector discipline under which independent implementations demonstrate byte-level agreement.¶

Out of scope:¶

• Signing-key management policy beyond the discipline of Section 9.¶

• Retention, storage, indexing, and discovery of chain files.¶

• Transport of records between parties.¶

• Any claim about which model, prompt, or software produced an action (Section 8).¶

• Normative specification of the payment-reference binding sketched informatively in Section 7.¶

3.1. Sibling Relationship to the Pre-Action Families

[VERIFICATION-STATE], Section 3.1 presents a two-column comparison of the environment.* and verification.* families. The following table extends that comparison with the post-action column this document defines.¶

The pre-action families are fail-closed about acting: uncertainty halts execution. The evidence.* family is fail-closed about believing: uncertainty halts acceptance of the record. The three families meet at the same design intent — ambiguity never resolves in favor of proceeding, whether the proceeding is an action or the acceptance of a claim about one.¶

The split is structural rather than editorial. A pre-action family owns a threshold and derives a permission from it; the evidence.* family owns neither. What carries across all three is the verification model: deterministic canonicalization, primitives inside the signed bytes, a key resolved from a published location, and local recomputation by a party that trusts no runtime.¶

3.2. Membership Criterion

The membership criterion of the evidence.* family is that a record type's verification MUST be independently recomputable and fail-closed. A record type satisfies this criterion if and only if: (1) every field that contributes to a verification verdict is covered by the issuer's signature; (2) the signed bytes are produced under a deterministic canonicalization that an independent implementation can reproduce byte-for-byte from the record's members — for this family, the JSON Canonicalization Scheme [RFC8785]; (3) records within a session are bound into an append-only hash chain such that removal, insertion, or reordering of any record is detectable from the records alone; and (4) a verifier that cannot complete recomputation — an unresolvable key, a failed canonicalization, a broken chain, a malformed member — MUST return UNVERIFIABLE and MUST NOT report the record as valid. A record type whose verification requires trusting the issuer's runtime, whose signed bytes cannot be independently reproduced, or whose verification degrades to acceptance on failure is outside this family regardless of how it is named.¶

As with the pre-action families, the criterion is not a per-type design choice made while a type is being drafted. A record type specification author MUST establish all four properties before proposing the type for the family, and a proposed type that does not demonstrably satisfy all four MUST be rejected from the family on that ground alone.¶

3.3. Namespace

Family members are named under the evidence.* namespace using dot notation. The first component of the type identifier is the literal string evidence; the second component identifies the kind of occurrence the record type commits to; further components may be used by future revisions for sub-classification.¶

The record type specified by this document is evidence.action. Its version token is carried inside the record and is distinct from the type identifier; version-token discipline is specified in Section 4.2.¶

A record type specification author SHOULD choose a second component that names the kind of occurrence recorded (for example, action) rather than the implementation, the issuer, or the wire format. IANA MUST NOT register a type identifier within the evidence.* namespace whose specification does not satisfy the membership criterion of Section 3.2. The namespace and the criterion are coupled deliberately: a verifier encountering an evidence.* identifier relies on the family's discipline holding for that type, and a namespace that admitted non-conforming types would defeat that reliance.¶

3.4. Adding New Family Members

A record type specification author MAY propose a new evidence.* record type by publishing a specification that:¶

(1) demonstrates that the proposed type satisfies all four properties of the membership criterion of Section 3.2;¶

(2) specifies the trust-root mechanism under which a verifier discovers the issuer's signing key, including how the key is bound to an issuer identity and how rotation is handled;¶

(3) specifies a verification algorithm whose terminal states are exactly VALID, INVALID, and UNVERIFIABLE, with no other terminal state and no path from a recomputation failure to VALID;¶

(4) declares every signed member the type adds to the family-wide vocabulary of Section 4.2, and states for each whether it contributes to a verdict;¶

(5) declares the type's MUST-implement signing algorithm and any SHOULD-implement or MAY-implement extension set, under the agility framework of Section 4.5;¶

(6) publishes, under the corpus discipline of Appendix A of this document, a frozen conformance corpus that includes at least one vector whose expected verdict is a rejection; and¶

(7) conforms to the register discipline of [ENV-STATE], Section 6 throughout.¶

These seven requirements correspond to the Expert Review criteria of Section 10.3. A specification missing any requirement is not conforming, and the proposed type MUST NOT be registered until the gap is closed.¶

4.1. Canonicalization

Every hash and every signature preimage in this family is produced from the JSON Canonicalization Scheme [RFC8785]. Implementations of an evidence.* record type MUST apply JCS at every point where bytes are hashed or signed, and MUST NOT substitute any other serialization at any such point.¶

The requirement is load-bearing rather than stylistic. Recomputability is the family's membership criterion, and a non-canonical serializer — one whose object member order, whitespace, or number formatting varies by implementation — makes the same logical value hash differently in the issuer and in the verifier. That divergence appears exactly at the point where the commitment is supposed to be reproducible.¶

For the evidence.action record type, JCS is applied at four points:¶

• record content, to derive the entry hash;¶

• record content, to derive the signature preimage;¶

• the request descriptor, to derive the request commitment;¶

• an event's raw arguments value and raw result value, to derive the arguments hash and result hash.¶

The hash function at every one of those points is SHA-256, and every hash value in a record is carried as the string "sha256:" followed by the lowercase hexadecimal digest.¶

4.2. Family-Wide Record Members

The following members appear, with identical semantics, on every evidence.* record.¶

v — string, required. The record's version token. The token identifies the record type and its wire revision together; it is not the IANA type identifier. For evidence.action the defined tokens are "evidence.action/0" and "evidence.action/1". A verifier MUST reject a record whose version token it does not support, and MUST NOT attempt verification under a different version's rules.¶

seq — number, required. The record's zero-based position within its session's chain.¶

session_id — string, required. The identifier of the session the record belongs to. Chaining is defined within one session_id.¶

ts — string, required. The record's issuance time. The reference implementation writes an ISO 8601 date-time in UTC. The only property a verifier checks over ts is non-regression within a bounded skew (Section 5.1); ts is not a trust anchor (Section 9.5).¶

prev_hash — string, required. The chain link: the entry hash of the preceding record in the session, or the genesis value for seq 0 (Section 4.4).¶

kid — string, required. The identifier of the key the record was signed under, as published in the issuer's key set.¶

key_thumbprint — string, required on "evidence.action/1", absent on "evidence.action/0". The JWK thumbprint [RFC7638] of the signing key. It is inside the signed bytes, and a verifier MUST compare it to the thumbprint of the key it actually resolved before checking the signature (Section 5.1). A record at version "evidence.action/1" that omits this member is malformed, and a verifier MUST NOT verify it.¶

iss — string, optional on "evidence.action/1", absent on "evidence.action/0". The issuer identifier. It is informational: the cryptographic binding is carried by key_thumbprint, and iss is inside the signed bytes so that it cannot be rewritten after signing.¶

jwks_uri — string, optional. An HTTPS URL naming where the signing key for this record is published as a JWK Set [RFC7517]. Because it is inside the signed bytes, it is the signer committing to a publication location rather than a rewritable hint. A verifier MUST reject a record whose jwks_uri is present and is not an HTTPS URL (Section 5.1), and MUST apply the fetch restrictions of Section 9.4 when resolving it.¶

sig — string, required. The signature over the canonical bytes of the record content, encoded base64url without padding. sig is the one member of a record that is not part of record content, and therefore not part of any preimage.¶

Absence and null are distinct under JCS: an absent member does not appear in the canonical bytes at all, while a member whose value is null does. A record type specification author who adds an optional member MUST specify that the member is omitted when it carries no value, and MUST NOT specify a null placeholder, because the two forms produce different canonical bytes and therefore different hashes.¶

4.3. The evidence.action Record Type

An evidence.action record commits to one dispatched action. Beyond the family-wide members of Section 4.2, it carries the following.¶

4.4. Chain Construction

"sha256:" + hex(SHA-256(JCS({
    "v":          <the record's version token>,
    "session_id": <the record's session_id>,
    "marker":     "genesis"
})))

"sha256:" + hex(SHA-256(JCS(record_content)))

4.5. Signature and Algorithm Agility

An evidence.action signature is Ed25519 computed directly over the JCS canonical bytes of the record content. The signature value is encoded base64url without padding.¶

The algorithm identifier and the key representation are those of the JOSE algorithm registration for Edwards-curve signatures [RFC8037], and the signature is a detached signature over canonical bytes rather than a JWS [RFC7515] compact or JSON serialization. An implementation MUST NOT treat an evidence.action record as a JWS object; the signing input is the canonical bytes themselves, with no encoded header and no period-delimited signing input.¶

Ed25519 signatures are deterministic [RFC8032]: the same key over the same message produces the same signature bytes. An implementation MUST NOT introduce nonce or salt material into the signing path, because byte parity of signatures across independent implementations is one of the properties the conformance corpus of Appendix A exists to demonstrate.¶

Following the agility discipline of [ENV-STATE], Section 4.3, algorithm choice is a per-type concern. This document declares Ed25519 as the MUST-implement signing algorithm for evidence.action and declares no SHOULD-implement or MAY-implement extension set. A verifier MUST reject a record whose declared algorithm is not in the supported set for the record type; this rejection is fail-closed and is not a permitted silent downgrade.¶

A specification defining a successor record type MUST declare its own MUST-implement algorithm explicitly, and SHOULD specify the conditions under which the current MUST-implement is deprecated, the migration timeline for verifiers, and the backward-compatibility guarantee during the transition. The family-layer obligation is structural: the choice is made per type, declared explicitly, and honoured by verifiers without fallback.¶

4.6. Strict Ingest

A verifier MUST parse candidate record bytes under a strict profile before computing any hash over them. The strict profile rejects:¶

• a duplicate member name within any object, at any nesting depth; and¶

• any numeric member whose value does not round-trip losslessly as a finite IEEE 754 double-precision value.¶

A verifier MUST treat a strict-profile violation as a terminal parse failure and MUST NOT fall back to hashing the bytes it could not accept. The corresponding verdict is UNVERIFIABLE (Section 5.1).¶

The reason both rules are normative is recomputability rather than hygiene. A permissive parser resolves duplicate member names last-wins, so the bytes an issuer canonicalized and the bytes a verifier reconstructs from the same source text can differ while both parsers report success. A permissive parser also converts a numeric literal outside the exactly-representable range into a nearby representable value without signalling, so a value that entered the issuer's preimage is not the value that enters the verifier's. Both failures land precisely on the commitment that is supposed to be reproducible.¶

The round-trip formulation is deliberately broader than an integer range check. An integer literal whose magnitude exceeds the exactly-representable range fails the round-trip test, and so does a literal whose exponent overflows to a non-finite value. Pinning the rule to round-trip behaviour rather than to token shape is what makes independent implementations reject the identical set: two implementations that each apply their own notion of "too large" would agree on the common cases and diverge on the edges, and a corpus rejection vector would then be conformance-checkable in one implementation and not the other. Appendix B states which part of this rule the reference implementation currently enforces.¶

5.1. Steps

A verifier given a chain file and a key source MUST execute the following sequence and MUST stop at the first failure. Verdicts are named in Section 5.2.¶

1. Parse under strict ingest. Parse every line of the chain file under the strict profile of Section 4.6. A violation yields UNVERIFIABLE.¶

2. Resolve the key. Resolve the key named by the records' key identifier from the applicable key source. Where the source is a published key set, apply the fetch restrictions of Section 9.4. A key that cannot be resolved — an unreachable publication location, a malformed key set, no key under the named identifier, more than one key under the named identifier — yields UNVERIFIABLE. A verifier MUST NOT fall back to a different key source when the higher-precedence source is present but unresolvable, because such a fallback converts an unresolvable key into a verifiable one under a key the record did not name.¶

3. Check the committed publication location. If a record carries jwks_uri and it is not an HTTPS URL, the verdict is INVALID: the signer committed, inside the signed bytes, to a publication location a verifier must refuse to fetch.¶

4. Check the key binding. For a record at a version that carries key_thumbprint, recompute the thumbprint [RFC7638] of the key resolved in step 2 and compare it to the committed value. A mismatch, or an absent key_thumbprint at a version that requires it, yields INVALID. This check precedes signature verification: a verifier that checked the signature first would let a key substituted at the publication location pass by verifying under itself.¶

5. Check sequence. The record's seq MUST equal its zero-based position in the file. A mismatch yields UNVERIFIABLE.¶

6. Recompute canonical bytes. Strip sig, canonicalize the content under JCS, and derive the entry hash. A canonicalization that cannot be completed yields UNVERIFIABLE.¶

7. Recompute the chain link. For seq 0, the record's prev_hash MUST equal the genesis value of Section 4.4.1 computed from the record's own version token and session identifier. For every later record, prev_hash MUST equal the entry hash computed in step 6 for the preceding record. Any break yields UNVERIFIABLE.¶

8. Recompute the request commitment. Rebuild the request descriptor from the recorded event and hash it. A mismatch against the record's request_commitment yields UNVERIFIABLE: the recorded action does not match its own committed identity.¶

9. Verify the signature. Verify the signature over the canonical bytes from step 6 under the key resolved in step 2. A signature that does not verify against a resolved, published key yields INVALID.¶

10. Check timestamp non-regression. The record's ts MUST NOT precede the highest ts seen so far by more than the verifier's configured skew bound. A regression beyond the bound yields UNVERIFIABLE.¶

11. Verify the checkpoint, if present. Apply Section 4.4.3. A checkpoint failure yields UNVERIFIABLE.¶

12. Emit VALID. Only a chain that reaches this step without a failure is VALID.¶

An empty chain file is not VALID. A verifier MUST NOT report VALID for a file that carries no records.¶

A verifier that reports VALID MUST also report which key the chain verified under and where that key was resolved from. Without a caller-supplied pin, VALID means that the chain is internally consistent under the key that was presented, not that it was signed by any particular party; naming the key and its origin is what keeps that distinction visible to the consumer.¶

5.2. The Three Verdicts

VALID — Every check of Section 5.1 completed and passed. The chain is intact, the signatures verify under the resolved key, and the key matches the identity the records committed to.¶

INVALID — The verifier resolved a key and a cryptographic binding failed against it: the committed thumbprint did not match the resolved key, the signature did not verify, the resolved key was not in a caller-supplied pinned set, or the record committed to a publication location that must not be fetched.¶

UNVERIFIABLE — The verifier could not complete recomputation: the key could not be resolved, the bytes could not be accepted under strict ingest, the canonicalization could not be reproduced, the chain did not link, the request commitment did not recompute, or a member was malformed.¶

INVALID and UNVERIFIABLE are distinct verdicts, and a verifier MUST NOT collapse them into one. They answer different questions for a consumer: INVALID says "a key was reached and the record failed against it," and UNVERIFIABLE says "no answer could be established." A consumer that cannot tell the two apart cannot tell a rewritten record from an unreachable key, and the remedies for those two states are not the same.¶

Only VALID exits success. A verifier MUST signal failure for both INVALID and UNVERIFIABLE through whatever mechanism its interface uses for failure, and MUST NOT provide a mode in which either verdict is reported as VALID.¶

5.3. Relationship to Finer-Grained Verifier Vocabularies

The three verdicts of Section 5.2 are the family's interoperable vocabulary. An implementation MAY report a finer-grained result alongside the verdict — for example, distinguishing a linkage break from a request-commitment mismatch, or naming which trust check failed — provided every finer-grained result maps onto exactly one of the three verdicts and the mapping is published. Appendix B records the mapping for the reference implementation, whose result vocabulary is finer than three and whose classification of one case differs from the classification this section specifies.¶

6.1. Non-Interference

An evidence.* record does not gate execution and does not satisfy the membership criterion of the environment.* family [ENV-STATE], Section 3.2: its failure mode is not gating, because it has no execution to gate. The families compose without overlapping. An implementation MUST NOT treat an evidence.* record as a constraint instance, and MUST NOT allow the presence, absence, or verdict of an evidence.* record to influence a pre-action gate decision.¶

The ordering the pre-action families specify among themselves is unaffected by this document. [VERIFICATION-STATE], Section 3.2 requires environment.* constraints to short-circuit before verification.* constraints, and [ENV-STATE], Section 5.5 makes an environment.* halt final. Recording happens after that ordering has run to its terminal state, so an evidence.* record cannot preempt, mask, or re-order any pre-action evaluation.¶

6.2. Recording Failure

An implementation MUST surface a failure to record. Recording is evidence-producing rather than execution-gating, so a silently dropped record is indistinguishable, later, from an action that never happened — which is exactly the survivorship bias the outcome vocabulary of Section 4.3.2 exists to prevent.¶

Whether a recording failure also halts the deployment is a deployment policy decision, not a property of this family. Both postures are coherent and both are observed in practice: a purely observational deployment logs the failure and permits the action to proceed, while a deployment that treats un-recorded effects as unacceptable withholds the result from the agent so that the agent does not act on an un-recorded outcome. This document requires only that neither posture may swallow the failure.¶

6.3. Binding to the Pre-Action Gate Receipt

The gate member of Section 4.3.4 carries gate_receipt, a reference to the pre-action authorization that permitted the action. The intent of the member is the end-to-end property: a verifier resolves gate_receipt to the pre-action receipt, and checks that the pre-action receipt's own request commitment equals the request commitment carried in the record's gate object, so that "what was authorized" and "what was recorded" are the same bytes across the two families.¶

That end-to-end resolution is not implemented. In the reference implementation, gate_receipt is self-anchored: it carries the record's own entry hash, which a verifier can recompute but which references nothing upstream. The member is therefore format-ahead-of-implementation, and this document states it as such rather than describing the intended property as an available one. An implementer MUST NOT infer from the presence of gate_receipt that any deployed recorder today resolves it to an upstream pre-action receipt. The status is recorded in Appendix B of this document.¶

A future revision of this document may specify the resolution rule normatively. It is deliberately not specified here, because the rule would bind two independently versioned families together and the binding has not been exercised end-to-end.¶

9.1. The Limits of an Operator-Signed Record

Every property this family provides is a property of a record signed by the operator of the runtime that produced the action. A verifier that holds the records and the published key can establish that the operator committed to specific bytes and that those bytes have not changed since signing. Nothing in the family establishes that the committed bytes describe the action accurately, that the recorded output is the output a consumer received, or that the signer is independent of the action. Section 8 states these limits in full; they are repeated here because they bound the security analysis of every subsection below.¶

The practical consequence is that the family narrows a dishonest operator's options rather than eliminating them. Post-hoc alteration of a signed member is detectable. Dishonesty at signing time is not.¶

9.2. Key Compromise and Custody

A holder of the signing key can produce any chain that verifies. Every integrity property of this family is conditional on key custody, and this document specifies no custody mechanism.¶

An operator publishing an evidence.* chain MUST publish the corresponding public key at a location under the operator's own control, and MUST NOT rely on a key set published by the specification author or by any implementation vendor. The issuer identity a record commits to is the operator's, not the implementation's.¶

An operator MUST publish a signing key before signing records under it. A verifier resolving a key identifier that is not present in the published key set returns UNVERIFIABLE, and a publish-after-sign order therefore produces a window in which honestly produced records are unverifiable.¶

Key rotation is a publication concern rather than a chain concern: a chain links by content hash, not by key, so a rotation does not break linkage. A verifier MUST NOT accept a chain whose records name a key identifier that is not resolvable in the published key set at verification time merely because an earlier verification succeeded. An operator SHOULD retain superseded public keys in the published key set for as long as records signed under them are expected to be verified.¶

A key set that publishes more than one key under a single key identifier is ambiguous. A verifier MUST return UNVERIFIABLE in that case, and MUST NOT select one of the candidates.¶

9.3. Equivocation and External Witnessing

The chain is tamper-evident with respect to a verifier that holds the records. It is not equivocation-resistant. A signer who controls every copy of a chain can produce two internally consistent chains for the same session that disagree about what happened, and no verifier holding only one of them can detect the other.¶

External witnessing addresses this and is a deployment measure rather than a family property. An operator concerned with equivocation may record chain heads in a public-good transparency log, so that a later divergence between the operator's chain and the recorded head is detectable by a third party. The ceiling of the resulting claim is that a head was recorded in a public-good transparency log. An operator MUST NOT describe a record so anchored as third-party attested: the log records what it was given, and records nothing about the action.¶

Nothing in this document requires witnessing, and no verdict of Section 5 depends on it.¶

9.4. Verifier-Initiated Fetch

A record carries jwks_uri inside its signed bytes, and a verifier that fetches a URL taken from a record it has not yet verified is following an untrusted pointer. Absent restriction, that is a server-side request forgery primitive.¶

A verifier resolving a key set from a location named by a record MUST apply all of the following, and MUST treat any violation as an aborted fetch rather than as a weaker check:¶

• the URL scheme is HTTPS and the port is the HTTPS default;¶

• the host is a name rather than an IP literal;¶

• the host does not resolve to a loopback, link-local, or otherwise non-public address, checked after name resolution so that a rebind between check and connect cannot slip through;¶

• at most one redirect is followed, and only to the same origin;¶

• the response body is bounded and the request is subject to a timeout;¶

• the response carries a JSON content type.¶

An aborted fetch yields UNVERIFIABLE. A verifier MUST NOT respond to an aborted fetch by resolving the key from a different source (Section 5.1, step 2).¶

9.5. Timestamps

The ts member is issuer-asserted and unwitnessed. A verifier MUST NOT treat ts as evidence of when an action occurred, and MUST NOT use ts to order records: ordering is carried by seq and by the hash chain, both of which are covered by the signature.¶

The only property a verifier checks over ts is non-regression within a bounded skew (Section 5.1, step 10). The bound exists because clocks in a distributed deployment disagree, and a strict monotonicity requirement would reject honestly produced chains. An operator SHOULD synchronize the clock of any host that signs records, and a verifier SHOULD choose a skew bound no larger than its deployment requires, because the bound is also the window within which a reordering is not detectable from timestamps alone.¶

9.6. Replay and Record Reuse

A record is bound to its position by seq, to its predecessor by prev_hash, and to its session by session_id, and all three are inside the signed bytes. Lifting a record out of one chain and inserting it into another therefore breaks the linkage check of Section 5.1, step 7, and re-presenting a record at a different position breaks the sequence check of step 5.¶

Replay of a whole chain is a different matter and is not addressed by the chain construction. A chain is a verifiable statement about what an operator committed to, not a statement about when a consumer received it. A consumer that needs freshness MUST establish it outside the record — for example by binding the chain into a protocol exchange that carries its own anti-replay mechanism — and MUST NOT infer freshness from ts (Section 9.5).¶

9.7. Strict Ingest as an Interoperability-Security Property

The strict-ingest profile of Section 4.6 is a security property and not only a parsing convention. Its absence produces a class of divergence in which an issuer and a verifier both report success over the same source text while having hashed different values — through a duplicate member resolved differently, or through a numeric literal silently converted to a nearby representable value. A divergence of that shape does not announce itself: it appears as a verification failure that neither party can reproduce, or worse, as a verification success over a value neither party intended.¶

Pinning the rule to lossless round-trip behaviour rather than to token shape is what makes the reject set identical across implementations. An implementation that applies a narrower rule accepts inputs a conforming implementation rejects, and the two disagree exactly at the edges an adversary chooses.¶

10.1. The evidence.* Namespace

IANA is requested to register the evidence.* namespace as a record type prefix in the registry of Section 10.2. The namespace is the literal string evidence followed by a dot followed by one or more dot-separated components identifying the kind of occurrence a record type commits to and, optionally, sub-classifications.¶

This document is registered as the family-definition document for the evidence.* namespace. A specification proposing a new evidence.* type identifier MUST conform to this document. IANA MUST NOT register a specification that does not conform, regardless of the technical merit of the proposed type.¶

10.2. The evidence.* Record Type Registry

IANA is requested to establish a registry titled "evidence.* Record Types" (or a name the working group prefers) with the following structure.¶

Registry fields. Each registration entry has the following fields:¶

• Type identifier — the dot-separated string under the evidence.* namespace (for example, evidence.action).¶

• Defined In — a reference to the record type specification that defines the type. The reference SHOULD be a stable identifier (RFC number, Internet-Draft name and revision, or a permanent published-document URL).¶

• Version — the version of the type specification at the time of registration.¶

• Version Tokens — the version token or tokens the type's records carry in their v member, as specified in Section 4.2.¶

• Status — one of: Provisional, Stable, Deprecated.¶

• MUST-Implement Algorithm — the per-type signing algorithm declared per Section 4.5.¶

• Conformance Corpus — a reference to the type's frozen conformance corpus per Appendix A, including the identifier under which the corpus manifest is published.¶

• Notes — implementation-status references per [RFC7942], known-issues references, or coordination references with sibling specifications. May be empty.¶

Initial registry contents. This document registers one type identifier, with the following field values:¶

• Type identifier: evidence.action¶

• Defined In: this document¶

• Version: 00¶

• Version Tokens: evidence.action/0, evidence.action/1¶

• Status: Provisional¶

• MUST-Implement Algorithm: Ed25519¶

• Conformance Corpus: the frozen corpus described in Appendix A¶

• Notes: see Appendix B of this document for implementation status and known gaps¶

This document registers no other type identifier.¶

Registration policy. Registration follows the Specification Required policy of [RFC8126], Section 4.6 with Expert Review by designated experts the working group appoints. The criteria the experts apply are specified in Section 10.3.¶

10.3. Expert Review Criteria

A designated expert evaluating a proposed registration MUST verify that the proposed type satisfies all of the following:¶

(1) every field contributing to a verdict is covered by the issuer's signature (Section 3.2, property 1);¶

(2) the signed bytes are produced under a deterministic canonicalization an independent implementation can reproduce byte-for-byte (Section 3.2, property 2);¶

(3) records within a session are bound into an append-only hash chain in which removal, insertion, and reordering are detectable from the records alone (Section 3.2, property 3);¶

(4) a verifier that cannot complete recomputation returns UNVERIFIABLE and never reports the record as valid (Section 3.2, property 4);¶

(5) the type specification declares its MUST-implement signing algorithm and any extension sets per Section 4.5;¶

(6) the type specification publishes, per Appendix A of this document, a frozen conformance corpus that includes at least one vector whose expected verdict is a rejection; and¶

(7) the type specification conforms to the register discipline of [ENV-STATE], Section 6.¶

A proposed registration that fails any of these checks MUST be rejected by the designated experts. Rejection is not punitive; it indicates that the gap is to be closed in the proposed specification before the registration is reconsidered. A designated expert SHOULD identify which check the proposed registration failed and what closure of the gap would look like.¶

A designated expert SHOULD also evaluate a proposed registration for namespace coherence — an identifier that names the kind of occurrence recorded rather than the implementation, the issuer, or the wire format — and for implementation status per [RFC7942]. These additional criteria are guidance; they are not requirements a proposed registration MUST satisfy.¶

10.4. Status Field Lifecycle

The Status field of Section 10.2 has three values.¶

Provisional. The type's specification has been adopted but has not been published as an RFC or equivalent stable document. Implementations of provisional types should expect specification changes.¶

Stable. The type's specification has been published as an RFC or equivalent stable document.¶

Deprecated. The type's specification has been superseded or withdrawn. Deprecation does not suspend the membership criterion of Section 3.2. The Notes field SHOULD reference the superseding specification or document the reason for withdrawal. A verifier MAY continue to support a deprecated type for backward compatibility, and SHOULD log its use distinctly.¶

A status transition MUST NOT change a registered type's version tokens, its MUST-implement algorithm, or its conformance corpus reference; a change to any of those is a revision of the type's specification rather than an administrative status update.¶

11.1. SCITT

The SCITT architecture [RFC9943] specifies signing and receipt-envelope infrastructure for supply-chain transparency, including the transparency-service and receipt machinery an evidence chain would need in order to be witnessed (Section 9.3). This document specifies neither. An evidence.* record is a payload with its own canonicalization and chain discipline; it may be transported in, or registered with, a SCITT transparency service, and this document does not require that it be.¶

11.2. RATS

The RATS architecture [RFC9334] defines the Evidence, Verifier, Attestation Result, and Relying Party vocabulary. The mapping is imperfect and worth stating precisely: an evidence.* record is not RATS Evidence about a target environment's trustworthiness, and it is not an Attestation Result produced by a Verifier distinct from the Attester. It is a self-signed record of an action, produced by the party that performed it. Where RATS separates Attester from Verifier as a trust primitive, this family deliberately does not, and Section 8 states the consequence.¶

11.3. Signed Receipt Formats for Agent Actions

[ACTA-RECEIPTS] defines a signed receipt format for machine-to-machine access-control decisions, and [ASQAV-PROFILE] defines a multi-jurisdiction compliance profile of that format. The two are one lineage rather than two independent designs: the profile describes itself as "an additive overlay on [ACTA-RECEIPTS]" that "does not modify the envelope, the canonicalization rule, the signature object, or the algorithm registry" (Section 3), constrains fields the upstream document leaves optional, and states that "a Compliance Receipt remains a conformant [ACTA-RECEIPTS] receipt" (Section 1.1).¶

The overlap with this document is substantial and worth stating before the differences. Both of those documents canonicalize with JCS [RFC8785], both sign with Ed25519 [RFC8032] over canonical bytes as the mandatory-to-implement algorithm, and both remove the signature member before canonicalizing — [ACTA-RECEIPTS], Section 5.6 records the same null-versus-absent hazard this document records in Section 4.2, requiring that the signature field "be removed from the object, not set to null or to the empty string; these produce different JCS output and break interoperability". An implementer familiar with either document will recognize the canonicalization discipline here.¶

The families are structured differently. [ACTA-RECEIPTS] specifies a single receipt envelope with six receipt types and states, in its Section 9, that it "has no IANA actions", noting a receipt-type registry as possible future work; [ASQAV-PROFILE] requests a registry of extension field names (Section 11.1). Neither defines a namespace whose registration is gated on a family-wide membership criterion, and neither has pre-action siblings to compose with. This document takes the other approach: Section 3.2 states a membership criterion that Section 3.3 makes a registration precondition, and Section 6 specifies non-interference with two pre-action families rather than a single-format lineage.¶

The chaining constructions differ in scope, and the difference matters to a verifier. [ACTA-RECEIPTS] places hash chaining inside an optional Commitment Mode extension, and defines its link as covering the signature: previousReceiptHash is "SHA-256(JCS(receipt)), where receipt is the entire signed receipt object including the signature field" (Section 5.7). [ASQAV-PROFILE] makes linkage mandatory, scopes the chain to the issuer — "each issuer MUST maintain a single linear per-agent chain", with parallel sub-chains within one agent identity "NOT defined by this profile" (Section 5.3) — and roots it at "the all-zero SHA-256 value" (Section 5.3). This document scopes the chain to a session rather than to an issuer (Section 4.2), strips the signature from the link preimage so that the entry hash commits to content independently of signature encoding (Section 4.4.2), and derives genesis from a domain-separated preimage rather than a constant, for the splicing reason given in Section 4.4.1. An implementer composing across these documents should note that the two constructions are not interchangeable and that the two documents cited here do not agree on the digest scope of previousReceiptHash.¶

The verdict models differ. Verification in [ACTA-RECEIPTS] terminates in two outcomes: "if verification succeeds, the receipt is authentic and has not been tampered with. If verification fails, the receipt MUST be rejected" (Section 4.2). [ASQAV-PROFILE] likewise terminates in two — "a receipt that fails any of these checks MUST be reported as non-conformant" (Section 9.1) — while adding an independent-axis report over anchor validity, policy-digest resolution, and duplicate emission, with the instruction that "consumers MUST NOT collapse them into a single boolean before display" (Section 9.3). The tri-state vocabulary of Section 5.2 of this document separates a different pair: a cryptographic failure against a resolved key (INVALID) from an inability to complete recomputation at all (UNVERIFIABLE). That separation is a property of the verdict vocabulary itself rather than of a report layered over a binary outcome.¶

On conformance artifacts the documents converge more than they diverge. [ACTA-RECEIPTS], Section 5.10 publishes an interoperability test suite with a stated minimum set, including a three-receipt chain and a tampered proof that "MUST fail verification", and fixes salts so that vectors "remain reproducible across implementations". What the conformance corpus of this document adds is narrower than the existence of vectors: its manifest digest is pinned in the specification text itself, every pinned value is re-derived from the published receipt bytes by a separate verification path before release, and the signing seed is published so that a third party can re-derive the private key and check signature byte parity rather than only verifying signatures produced by someone else. Appendix A.3 is explicit that this falls short of two independent signing implementations, and that limit is unchanged by the comparison.¶

11.4. The Pre-Action Sibling Families

[ENV-STATE] defines the environment.* family and the family-definition discipline this document follows. [VERIFICATION-STATE] defines the verification.* family and demonstrated the sibling-family pattern. [WALLET-STATE] specifies a signed-boolean primitive over observed state and enumerates, in its Section 12, the adjacent primitives it is not; Section 8 of this document follows that register for the post-action position.¶

12.1. Normative References

[BCP14]

Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.

[RFC8037]

Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, <https://www.rfc-editor.org/rfc/rfc8037>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

12.2. Informative References

[ACTA-RECEIPTS]

Farley, T., "Signed Decision Receipts for Machine-to-Machine Access Control", Work in Progress, Internet-Draft, draft-farley-acta-signed-receipts-02, June 2026, <https://datatracker.ietf.org/doc/html/draft-farley-acta-signed-receipts-02>.

[ASQAV-PROFILE]

Gomes Marques, J. A., "Compliance Profile of Signed Action Receipts for AI Agents", Work in Progress, Internet-Draft, draft-marques-asqav-compliance-receipts-07, July 2026, <https://datatracker.ietf.org/doc/html/draft-marques-asqav-compliance-receipts-07>.

[ENV-STATE]

Borthwick, D. and M. Msebenzi, "Verifiable Intent - environment.* Constraint Family", Work in Progress, Internet-Draft, draft-borthwick-msebenzi-environment-state-01, June 2026, <https://datatracker.ietf.org/doc/html/draft-borthwick-msebenzi-environment-state-01>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

[VERIFICATION-STATE]

Krausz, J., "The verification.* Constraint Family: Pre-Action Fail-Closed Gates for AI Agent Decisions", Work in Progress, Internet-Draft, draft-krausz-verification-state-01, June 2026, <https://datatracker.ietf.org/doc/html/draft-krausz-verification-state-01>.

[WALLET-STATE]

Borthwick, D., "Wallet State Attestation: Signed Booleans about On-Chain State", Work in Progress, Internet-Draft, draft-borthwick-wallet-state-attestation-00, May 2026, <https://datatracker.ietf.org/doc/html/draft-borthwick-wallet-state-attestation-00>.

A.1. The Frozen Corpus

A frozen conformance corpus for the evidence.action record format is published as a bundle containing a specification document, a machine-readable manifest, a key set, six vectors, a reference runner, a deterministic generator, and a second, independent verification path used during bundle authoring.¶

The corpus pins, for every vector, the SHA-256 of the vector's receipt file bytes and the file's byte length; and, for every entry of every vector expected to verify, the request commitment, the entry hash, the signature, the canonical byte length, and the canonical SHA-256. Every pinned value is re-derived from the receipt file bytes by the bundle's independent verification path before publication.¶

The corpus manifest, at the revision this document was written against, has the SHA-256 digest:¶

dad4e77cc5072446832b0b1771de11e2fc14094c6671061366477e60ce214ef3

The six vectors and the property each exercises:¶

The tampered vector is the load-bearing one. It was produced by generating a valid record and then altering one element of the event in the file bytes, leaving the signature unchanged. Two independent checks catch the mutation: the request commitment recomputed from the altered event no longer matches the sealed value, and the canonical bytes of the content differ from what was signed. A verifier that reports the tampered vector as valid is non-conforming. The corpus does not require a specific rejection reason: a verifier that checks the request commitment before the signature reports a commitment mismatch, and a verifier that checks the signature first reports a signature failure. Both are conforming; the rejection is the requirement.¶

The chain-multi vector exists because a verifier that checks per-record signatures without checking linkage would pass every single-record vector. The corpus therefore asserts the linkage equalities explicitly: that the first record's prev_hash equals the genesis value for its session, and that the second record's prev_hash equals the first record's entry hash.¶

The canonicalization-key-order vector carries, in the manifest, both an unsorted arguments value and its JCS canonical form together with that form's byte length, so that an implementer can check their canonicalization path end-to-end rather than only its output hash.¶

Reject vectors for the strict-ingest profile of Section 4.6 are not part of this bundle. They belong to a second, separately frozen fixture described in Appendix A.3.¶

A.2. Verdict Vocabulary in the Corpus

The corpus predates the tri-state vocabulary of Section 5.2 and names its outcomes VALID, TAMPERED, and UNRESOLVED. The mapping is direct: TAMPERED is a rejection reported by the corpus for chain-integrity and content-mismatch failures, and UNRESOLVED is the corpus name for a key that could not be resolved, which this document names UNVERIFIABLE. A future revision of the corpus is expected to adopt this document's vocabulary. Until it does, an implementer comparing the two documents should read the corpus's outcome names as corpus-local labels rather than as this document's verdicts.¶

A.3. Independent Verification, and the Second Frozen Fixture

Conformance in this family is a claim about agreement between implementations, so a corpus verified only by the implementation that produced it establishes little. Two separately frozen artifacts, verified by different means, are in use.¶

The receipt-vector bundle of Appendix A.1 carries a generator and a distinct verification path: the generator writes the vectors, the manifest, and the key set deterministically from a published test seed, and the second path re-derives every pinned hash, signature, and canonical byte length from the published receipt bytes before the bundle is released. Both paths live in the bundle; they are two implementations of the same computation, not two independent parties.¶

That bundle's signing key is derived from a published 32-byte seed. It is a test key and MUST NOT be used to sign production records. The seed is published so that an independent implementer can re-derive the private key, re-sign the canonical bytes, and confirm signature byte parity end to end rather than only verifying signatures produced by someone else.¶

The second artifact is a separately frozen fixture of canonicalization, thumbprint, chain-structure, and strict-ingest reject vectors, held with the reference implementation rather than in the receipt-vector bundle. It is the one exercised three ways: by the reference implementation's own canonicalization path, by an independent implementation of [RFC8785] written by a different author with no shared dependency, and against the values claimed by the fixture's external author, who authored them by reasoning from the relevant specifications rather than by executing the implementation. Its strict-ingest reject vectors are driven through the same harness and fail closed with the expected reasons. The harness exercises the same canonicalization and strict-ingest code path the shipped binary uses; it is not a second reference implementation.¶

Neither artifact establishes byte parity between two independent signing implementations. Appendix A.5 names that as the next tier.¶

A.4. The Conformance Sentence

An implementation claiming conformance MUST reproduce the corpus verdicts, including the REJECT set, identically.¶

A.5. What the Corpus Does Not Cover

The corpus is a v1 tier and names the orthogonal properties a later tier would cover:¶

• Live key-set resolution. The corpus key set is offline; a later tier would exercise HTTPS resolution, rotation, caching, and the failure paths that produce UNVERIFIABLE.¶

• Gate-receipt upstream binding. The gate_receipt member in the vectors carries a pinned literal; a later tier would exercise the end-to-end property of Section 6.3.¶

• Transparency-log witnessing. Equivocation by a signer is not detectable from a single chain (Section 9.3); a later tier would exercise inclusion proofs.¶

• Key rotation across vectors. All vectors are signed by one key.¶

• Dual-implementation signing byte parity. The corpus demonstrates that one signing implementation produces bytes a conforming verifier accepts. It does not demonstrate that two independent signing implementations produce byte-identical records for the same logical event. That tier blocks on the existence of a second independent signing implementation and is the named next milestone.¶

B.1. Reference Implementation

Name and version. @headlessoracle/chirindo, version 0.3.0.¶

Source. github.com/LembaGang/chirindo, Apache-2.0.¶

Coverage. The implementation writes and verifies evidence.action records at both defined version tokens, implements the canonicalization discipline of Section 4.1, the chain construction of Section 4.4, the signature scheme of Section 4.5, the strict-ingest gate of Section 4.6, and the verification protocol of Section 5.1 including key-binding-before-signature ordering. Key resolution follows a documented precedence, and a present-but-unresolvable publication location does not fall back to another key source.¶

Published key set. The implementation resolves keys from a published key set at https://headlessoracle.com/.well-known/jwks.json by default; an operator overrides that default per Section 9.2.¶

Live verification. The verify path has been exercised by hand against the live published key set over HTTPS, and the three verdict classes behaved as specified: a well-formed chain resolved its key and returned VALID; a chain whose committed thumbprint had been altered returned INVALID with a key-binding reason, rejected before the signature check; and a chain signed by a key the published set does not carry returned UNVERIFIABLE with an unresolvable-key reason and no silent fallback.¶

Third-party verification of the corpus fixture. The canonicalization fixture of Appendix A.3 was authored by an external party reasoning from the relevant specifications rather than by executing the implementation's code, and was then verified three ways — the implementation's own canonicalization path, an independent implementation of [RFC8785] by a different author, and the fixture author's claimed values — with byte and hash agreement on every canonicalization vector and on the key thumbprint. The receipt-chain entry hashes in the fixture are derived at fixture-build time from the implementation's own code path and additionally recompute through the independent canonicalizer applied to a harness-side content strip, so the agreement is not an artifact of feeding one object to one canonicalizer twice. Signature authenticity of the fixture's illustrative records was explicitly not established in that exercise; the fixture author held only a public key. The negative cases the fixture describes structurally are separately covered by the implementation's own test suite against a real key.¶

B.2. Known Gaps

The following gaps are stated because the format leads the implementation in each case. An implementer MUST NOT infer the availability of these properties from this document.¶

Strict ingest covers part of the round-trip rule. Section 4.6 requires rejection of any numeric member that does not round-trip losslessly as a finite value. The implementation rejects integer-form literals outside the exactly-representable range and duplicate member names at any depth. An exponent-form literal that overflows to a non-finite value is not yet rejected. Section 4.6 states the rule the implementation is to converge on; the implementation does not satisfy it in full today.¶

The gate member is emitted in one of two shapes, neither complete. The recorder library emits a null gate on every record. The gate implementation emits a populated gate whose gate_family is permit and whose gate_receipt is self-anchored to the record's own entry hash. No deployed implementation resolves gate_receipt to an upstream pre-action receipt (Section 6.3).¶

The fail-closed disposition is not emitted. The decision_source value fail-closed is defined by the format and exercised by a corpus vector. The implementation's decision-source value space is user, config, hook, and n/a; it does not emit fail-closed today. A verifier of earlier vintage that has not learned the value would not be conforming for the corresponding corpus vector.¶

The verifier's result vocabulary is finer than three, and one case is classified differently. The implementation reports valid, tampered, invalid, empty, and unverifiable. Under Section 5.2, its invalid maps to INVALID, its unverifiable maps to UNVERIFIABLE, its empty maps to UNVERIFIABLE, and its tampered maps to UNVERIFIABLE except for the signature-failure case, which Section 5.1 step 9 classifies as INVALID and the implementation reports as tampered. Every one of the implementation's failure results exits non-zero, so the divergence is a labelling difference and not a fail-open path.¶

The payment-reference binding is specified but not built. Section 7 describes a design whose registry carries no confirmed mapping row. No implementation emits a payment reference.¶