Network Working Group R. Sharif Internet-Draft CyberSecAI Ltd Intended status: Standards Track October 4, 2026 Expires: April 7, 2027 The Typed-Evidence Record: A Legally-Operative, Trust-Graded Record Format for Machine-Generated Evidence draft-sharif-typed-evidence-record-00 Abstract A tamper-evident record establishes that data has not been altered. It does not, by itself, establish what legally-operative fact the data evidences, nor how far the data may be relied upon. This document defines the Typed-Evidence Record (TER): an interoperable record format in which a machine-generated record, such as a record of an action taken by an autonomous agent, is expressed as a set of legally-operative facts, carries an evidence grade reflecting its level of cryptographic attestation, carries a per-fact robustness indication, and carries the result of an independent integrity verification of its source. A Typed-Evidence Record binds to, and does not replace, the underlying signed record it describes. This document specifies the record format and the requirements a record and a relying party MUST meet to be interoperable. It does not specify how the legally-operative facts are produced from a source record; that is an implementation concern outside the scope of this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 7, 2027. Sharif Expires April 7, 2027 [Page 1] Internet-Draft Typed-Evidence Record October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Relationship to the Agent Audit Trail . . . . . . . . . . . 4 4. The Typed-Evidence Record . . . . . . . . . . . . . . . . . 5 4.1. Legally-Operative Facts . . . . . . . . . . . . . . . . 5 4.2. Absence as a Fact . . . . . . . . . . . . . . . . . . . 7 4.3. Per-Fact Robustness . . . . . . . . . . . . . . . . . . 7 4.4. Evidence Grade . . . . . . . . . . . . . . . . . . . . 8 4.5. Source Verification Result . . . . . . . . . . . . . . 9 4.6. Attestation and Reproducibility Fields . . . . . . . . 10 4.7. Source Binding and Chain of Custody . . . . . . . . . . 10 4.8. Schema Version . . . . . . . . . . . . . . . . . . . . 11 5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Relying-Party Processing . . . . . . . . . . . . . . . . . 12 7. Conformance . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Example Typed-Evidence Record . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Automated and artificial-intelligence systems increasingly take, or materially influence, actions that have legal, financial, safety and regulatory consequences. When such an action is later disputed, a party must be able to reconstruct and demonstrate, to an independent third party, what occurred. A substantial body of work addresses the integrity of the records such systems emit. Records may be signed, hash-chained, anchored and independently recorded, so that alteration after the fact is detectable. The Agent Audit Trail [AAT] is one such record format. Sharif Expires April 7, 2027 [Page 2] Internet-Draft Typed-Evidence Record October 2026 Integrity is necessary but not sufficient. A record may be perfectly tamper-evident and yet not usable as evidence, because integrity does not establish: o what legally-operative fact the record evidences (who acted, on whose behalf, upon what, for whom, under what authority, whether the action was permitted or refused, at what level of competence, with or without human involvement, and when); nor o how far the record may be relied upon, which depends on the cryptographic attestation of its source and of the system that produced it. This document defines the Typed-Evidence Record (TER): a record format that expresses these facts explicitly, carries an evidence grade reflecting the attestation level of the source, carries a per- fact robustness indication, carries the result of an independent integrity verification of the source, and binds to the source record it describes. A Typed-Evidence Record is a record ABOUT a source record. It does not replace the source record and does not weaken its integrity properties; it augments a signed record with the typed, graded and verified information a relying party needs in order to treat the record as evidence. Scope. This document specifies: o the set of fields a Typed-Evidence Record carries and their meaning (Section 4); o the encoding of those fields (Section 5); o how a relying party processes a Typed-Evidence Record (Section 6); and o the requirements a record and a relying party MUST meet to be interoperable (Section 7). Out of scope. This document does NOT specify how the legally- operative facts are produced from a source record, how the evidence grade or the robustness indication is computed, or how a producer achieves reproducibility. These are implementation concerns. A conforming Typed-Evidence Record may be produced by any means, provided the resulting record meets the requirements of this document. This separation is deliberate: it allows the record format to be an open, interoperable target while leaving producers free to differentiate. Sharif Expires April 7, 2027 [Page 3] Internet-Draft Typed-Evidence Record October 2026 This document does not claim priority over, or precedence among, other Internet-Drafts concerning agent or machine evidence. It defines one specific layer: a typed, graded record format situated above a signed source-record format such as [AAT]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Source record: a machine-generated record that is the subject of a Typed-Evidence Record. A source record MAY be signed and hash- chained, for example a record conforming to [AAT], or MAY be unsigned, for example a line of plain text. Typed-Evidence Record (TER): a record conforming to this document that expresses legally-operative facts about a source record, together with an evidence grade, per-fact robustness, a source verification result, and a binding to the source record. Legally-operative fact: an item of information about a source record that corresponds to a question a legal or regulatory process asks of the record, drawn from the registry in Section 4.1. Producer: an entity that creates Typed-Evidence Records from source records. Relying party: an entity that consumes and verifies Typed-Evidence Records. 3. Relationship to the Agent Audit Trail The Typed-Evidence Record is designed to sit above a signed source- record format. The Agent Audit Trail [AAT] is the REFERENCE source- record format for this document: a Typed-Evidence Record that describes an AAT record carries the AAT record's canonical hash as its source binding (Section 4.7), and a relying party verifies the AAT source record using the mechanisms AAT defines (canonical hashing, signature verification and chain linkage). The Typed-Evidence Record is not limited to [AAT]. A source record in any format that provides, or can be reduced to, a canonical representation and a content hash MAY be the subject of a Typed- Evidence Record. Where the source record is unsigned, the Typed- Sharif Expires April 7, 2027 [Page 4] Internet-Draft Typed-Evidence Record October 2026 Evidence Record records this (Section 4.4, Section 4.5) and is graded accordingly. 4. The Typed-Evidence Record A Typed-Evidence Record is an object with the fields defined in this section. Unless stated otherwise, a field is REQUIRED. 4.1. Legally-Operative Facts A Typed-Evidence Record carries a set of typed facts, each assigned to one category from the registry below. The registry is version- pinned (Section 4.8): a record states the registry version under which its facts were assigned, so that a record remains interpretable against the exact registry that produced it. The initial registry defines fifteen categories in three groups. Attribution and act: o actor: the entity that performed the act. o principal: the person or party on whose behalf the act was performed, or whose data was involved. o act: the operation performed. o object: the resource or data acted upon. o recipient: the party to which data or an output was sent or disclosed. Provenance: o model-identity: the model or system that produced an output. o model-version: the version or build of that model at the time. o prompt: the input, instruction or query provided. o output: the material produced. Classification and authority: o data-classification: the sensitivity class of the data involved. o authority-basis: the source of authority relied upon, for example a policy, a consent, a statute or a grant. Sharif Expires April 7, 2027 [Page 5] Internet-Draft Typed-Evidence Record October 2026 o authorization-outcome: whether the act was permitted or refused. o competence-level: the level of authority held relative to the level required. o human-intervention: human approval or override, or its documented absence. o temporal-validity: the time at which the act occurred and whether the authority relied upon was valid at that time. Each typed fact is an object carrying at least: o category: one of the registry category identifiers above. o value: the extracted text or value assigned to the category. o robustness: a robustness indication for the fact (Section 4.3). A Typed-Evidence Record MAY carry more than one fact in the same category. A category for which no fact is present is treated as described in Section 4.2. 4.2. Absence as a Fact Where a category is not satisfied by the source record, a Typed- Evidence Record SHOULD record the absence explicitly, as a fact whose value states that the category is not present, rather than omitting the category silently. For example, the absence of a human approval is recorded as a fact in the human-intervention category stating that no human approval is present on the source record. Recording absence explicitly allows a relying party to distinguish "the category was considered and found absent" from "the category was not considered". 4.3. Per-Fact Robustness Each typed fact carries a robustness indication, which is one of: o robust: the fact is reported with high confidence. o fragile: the fact is reported with low confidence and SHOULD be reviewed by a human before being relied upon. A Typed-Evidence Record MAY additionally carry, for a fact, a numeric margin whose interpretation is producer-defined; the "robust" and "fragile" indications are the interoperable values. A relying party Sharif Expires April 7, 2027 [Page 6] Internet-Draft Typed-Evidence Record October 2026 that automates any consequence from a typed fact SHOULD take the robustness indication into account and SHOULD NOT rely without review on a fact marked fragile. 4.4. Evidence Grade A Typed-Evidence Record carries an evidence grade for its source record. The grade reflects the cryptographic attestation level of the source and is one of: o A: the source record is signed and its generating model, where applicable, is an open-weight model identified by a weights digest and an inference configuration sufficient for the underlying action to be re-executed and independently reproduced. o B: the source record is signed and, where applicable, anchored, but its generating model is a hosted or otherwise non-reproducible model; the record is verifiable as a record but the underlying action is not re-runnable. o C: the source record is unattested, for example a raw log, an export, or plain text; it is typed and legible, but its provenance is asserted and not proven. The grade is a property OF THE SOURCE as reflected in the record; it is not a statement about the quality or correctness of the underlying decision. Increasing the attestation of a class of source records, for example by adding a signature, or by pinning an open-weight model, raises the grade of that class from C toward A. A relying party MUST NOT treat a Grade C record as independently proven. A relying party MAY require a minimum grade for a given purpose. 4.5. Source Verification Result A Typed-Evidence Record carries the result of an independent integrity verification of its source record. The result is one of three states: o verified: the source record's integrity was checked and holds, for example its recomputed canonical hash matches, its signature verifies against a published key, and its chain linkage is consistent. o tampered: the verification scheme is established to operate upon the source bundle, as evidenced by at least one record in the bundle verifying, and the source record nonetheless fails Sharif Expires April 7, 2027 [Page 7] Internet-Draft Typed-Evidence Record October 2026 verification. o inconclusive: the source record could not be verified because its verification scheme could not be reproduced, or because there was nothing to verify, for example an unsigned source. The "tampered" state MUST NOT be reported where the failure is attributable to a verification scheme that could not be reproduced; such a case is reported as "inconclusive". This requirement prevents a record from being falsely reported as tampered merely because the verifier did not implement its scheme. 4.6. Attestation and Reproducibility Fields A Typed-Evidence Record carries fields that allow a relying party to identify what produced the typed facts: o producer-id: an identifier of the producer or producing tool, including a version. o model-digest: a cryptographic digest, for example a SHA-256 digest, of the model or resource used to assign the typed facts, where applicable, so that a relying party can confirm which resource was used. o typing-digest: a cryptographic digest over the typed facts of this record. o environment-attestation: OPTIONAL. An attestation of the environment in which the typed facts were produced, for example a remote-attestation quote from a trusted execution environment. These fields describe the provenance of the typed facts. This document does not require, and does not define, any particular production method; it requires only that these identifying fields be present so that a relying party can establish what produced the record. 4.7. Source Binding and Chain of Custody A Typed-Evidence Record binds to its source record by carrying: o source-hash: the canonical content hash of the source record. o source-ref: OPTIONAL. An identifier or locator of the source record. A Typed-Evidence Record MAY itself be signed and hash-chained, and Sharif Expires April 7, 2027 [Page 8] Internet-Draft Typed-Evidence Record October 2026 where it is, it SHOULD use the signing and chaining mechanisms of the source-record format it is paired with, for example [AAT]. A signed Typed-Evidence Record that carries the source-hash provides a chain of custody from the typed facts back to the source record they describe. 4.8. Schema Version A Typed-Evidence Record carries a schema-version field identifying the version of this format and of the category registry (Section 4.1) under which the record was produced. A relying party MUST interpret the record against the identified version. Categories are added only additively within a major version; removal or redefinition of a category requires a new major version. This discipline ensures that a record produced under one version does not change meaning when a later version is published. 5. Encoding The default encoding of a Typed-Evidence Record is a JSON [RFC8259] object. The following member names are defined. Implementations MUST ignore unknown members for forward compatibility. o "schema_version" (string, REQUIRED) o "source_hash" (string, REQUIRED): hexadecimal or base64url. o "source_ref" (string, OPTIONAL) o "grade" (string, REQUIRED): one of "A", "B", "C". o "verification" (string, REQUIRED): one of "verified", "tampered", "inconclusive". o "facts" (array, REQUIRED): each element an object with members "category" (string, REQUIRED), "value" (string, REQUIRED) and "robustness" (string, REQUIRED, one of "robust", "fragile"), and an OPTIONAL "margin" (number). o "producer_id" (string, REQUIRED) o "model_digest" (string, OPTIONAL) o "typing_digest" (string, REQUIRED) o "environment_attestation" (object, OPTIONAL) Where a Typed-Evidence Record is signed, the signature and chaining Sharif Expires April 7, 2027 [Page 9] Internet-Draft Typed-Evidence Record October 2026 members are those of the paired source-record format and are computed over the canonical form of the record excluding the signature value, as that format defines. 6. Relying-Party Processing A relying party that consumes a Typed-Evidence Record: 1. MUST read the schema_version and interpret the record against the identified version; if the version is not understood, the relying party MUST NOT rely on the record. 2. MUST independently verify the source record where it is able, using the source-record format's own mechanisms and the source_hash, and MUST compare the result to the "verification" field; if they disagree, the relying party MUST treat the record as inconclusive. 3. MUST NOT treat a record with "grade" of "C" as independently proven. 4. SHOULD take the per-fact "robustness" into account and SHOULD NOT rely without human review on a fact marked "fragile". 5. MAY confirm the producer and the resources used by means of the "producer_id", "model_digest" and "typing_digest" fields. 6. Where the record is signed, MUST verify its signature using the paired source-record format's mechanisms before relying on it. 7. Conformance A Typed-Evidence Record conforms to this document if it carries every REQUIRED field of Section 5 with values of the specified form, assigns each fact to a category of the registry version it names, and reports a grade and verification state from the defined sets. A producer conforms to this document if every record it emits conforms, and if the verification state it reports for a source record is the state an independent verifier would obtain, in particular if it reports "tampered" only in the circumstances of Section 4.5. A relying party conforms to this document if it processes records as described in Section 6. This document deliberately does not make conformance depend on how a producer computes facts, grades or robustness, so that the format is Sharif Expires April 7, 2027 [Page 10] Internet-Draft Typed-Evidence Record October 2026 an open interoperability target. 8. Security Considerations A Typed-Evidence Record is a statement by a producer about a source record. Its trustworthiness depends on (a) the integrity of the source record, which is established by the source-record format and reflected in the "verification" field, and (b) the trustworthiness of the producer, which a relying party establishes from the signature on the Typed-Evidence Record, the producer_id, and any environment attestation. A relying party MUST NOT treat the typed facts as more trustworthy than the source they are drawn from. In particular, a Grade C record carries facts whose provenance is asserted and not proven, and such facts can be fabricated at the source. The grade and the verification state are claims carried in the record. A relying party that requires assurance of these claims MUST verify the source independently (Section 6) rather than relying on the carried values alone; a signed Typed-Evidence Record binds the carried values to a producer, but does not by itself prove the source was verified, which is why independent verification is required. Facts in categories such as prompt, output and object may contain personal or sensitive data. Producers SHOULD apply appropriate minimisation, for example carrying a hash of a sensitive value rather than the value, consistent with the evidential need. The model_digest and typing_digest fields allow detection of a change in the producing resource; they do not by themselves attest that the resource was trustworthy, for which an environment attestation is provided. 9. IANA Considerations This document requests IANA to establish a registry titled "Typed- Evidence Record Categories", with an initial set of the fifteen category identifiers in Section 4.1. The registration policy is Specification Required [RFC8126]. Each entry carries the category identifier and a reference. This document further requests registration of the media type "application/typed-evidence+json" for a Typed-Evidence Record encoded as JSON, per [RFC6838]. [Note to RFC Editor and IESG: an IPR disclosure under BCP 79 relating to methods of producing the information carried in this format has Sharif Expires April 7, 2027 [Page 11] Internet-Draft Typed-Evidence Record October 2026 been filed with the IETF. This format document specifies only the record format and its processing, and does not specify any such method.] 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017. [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. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013. 10.2. Informative References [AAT] Sharif, R., "The Agent Audit Trail", draft-sharif-agent-audit-trail, work in progress. Appendix A. Example Typed-Evidence Record The following non-normative example describes a signed source record in which an agent executed a refund, under a human approval, and grades it B. { "schema_version": "ter-1", "source_hash": "25e6c073c5c6334b19824d7414c9060205f69ec3cb2a58c2", "grade": "B", "verification": "verified", "producer_id": "example-typer/1.0", "model_digest": "sha256:e67e8cc0ec4be9aa7e53059c5d656d91aaed3c", "typing_digest": "sha256:1632a41f8ee8b378127fb17db6d33ebb08567", "facts": [ Sharif Expires April 7, 2027 [Page 12] Internet-Draft Typed-Evidence Record October 2026 { "category": "actor", "value": "urn:agent:ops-1", "robustness": "robust" }, { "category": "act", "value": "refund", "robustness": "robust" }, { "category": "object", "value": "acct:cust-123", "robustness": "robust" }, { "category": "authority-basis", "value": "OAuth payments:write", "robustness": "robust" }, { "category": "competence-level", "value": "L3", "robustness": "robust" }, { "category": "human-intervention", "value": "approved by user:sarah.k", "robustness": "robust" }, { "category": "authorization-outcome", "value": "ALLOW", "robustness": "robust" } ] } Author's Address Raza Sharif CyberSecAI Ltd London, United Kingdom Email: raza@cybersecai.co.uk URI: https://aat-standard.org Sharif Expires April 7, 2027 [Page 13]