Reading, 9 September 2026
An obligation asks a record to show something. Who intervened. When it was written. What a conclusion rested on. Whether an action was permitted or refused. Those questions are not about any particular format, so the answer to them should not depend on which format a deployer happens to have bought.
This page reads four record formats against the same set of questions, and says for each one where the answer lives, or that it does not live anywhere. One of the four is maintained by the author of this page. It is in the table on the same terms as the others, graded by the same code, and it is worse than one of them on two rows. That is stated here rather than left to be found, because a reading published by an interested party is worth exactly what its disclosure is worth.
| Format | Read at | What it is for |
|---|---|---|
| Testimony Record | draft-clifford-testimony-record-02 | A record of what a system believed, what supported it, what contradicted it, and the decision that followed. |
| EMILIA Protocol authorization receipt | draft-schrock-ep-authorization-receipts-12 | An evidence artifact binding an enrolled approver key to one canonical action before it executes. |
| OpenTelemetry GenAI span | open-telemetry/semantic-conventions-genai, model/gen-ai/registry.yaml | Telemetry. Not an oversight record and not trying to be, and it is here because it is what most deployers already emit. |
| SCITT transparent statement receipt | RFC 9943 | A proof that a statement was registered in an append-only log. A carrier and an anchor. |
field means the format carries it in a named member. by construction means the format establishes it structurally rather than in a field, and the reason is given. absent means it has been read and is not carried, which is not the same as nobody having looked.
| What an obligation asks | Testimony Record | EMILIA receipt | OTel GenAI span | SCITT receipt |
|---|---|---|---|---|
| who intervened | approver.id | payload.reviewer_id | absent: seventy two gen_ai.* attributes on 9 September 2026 and not one for an approver. gen_ai.agent.id is the agent itself | absent: the issuer of a statement is not the person who approved an action |
| where that identity was resolved from | identity_source | by construction: the receipt is a user-verified WebAuthn assertion under an enrolled key | absent: no human identity to resolve | absent |
| when each row was written | at | payload.reviewed_at | startTimeUnixNano | iat |
| what a stated conclusion rested on | source | absent: the receipt commits to the action, not to what the reviewer was shown of it | absent: no person appears, so nothing records what was put in front of one | absent |
| whether an action was permitted or refused | verdict | payload.decision.outcome | absent: gen_ai.tool.call.result is what came back, which is a different fact | absent |
| why a refusal was refused | reason | payload.decision.principal_reasons | absent | absent |
| where an action's risk class came from | risk_source | absent | absent | absent |
| anything that would show the rows unaltered | digest | by construction: a signature over RFC 8785 canonical bytes committing to the action hash | absent: a collector may drop, sample and rewrite spans by design, so a span that arrives is not evidence one was emitted | by construction: an inclusion proof against an append-only log |
| what the system did | action_type | payload.decision.decision_type | gen_ai.tool.name | absent |
| who or what the record is about | subject | payload.decision.subject_ref | absent | sub |
| which decision this attaches to | decision | payload.decision_digest | gen_ai.tool.call.id | absent |
| which user or session acted | absent: no member names the session as distinct from the approver | absent: the approver is named, the session is not | absent: gen_ai.conversation.id is a conversation, not an account | absent |
| the device or location it acted from | absent | absent | absent | absent |
| what the system held to be true | proposition | absent: a receipt commits to an action, not to reasoning, and does not claim to | absent: a span records that a call happened, never what was believed | absent |
| whether two stored facts disagreed | sides | absent | absent | absent |
| the network address it acted from | absent | absent | absent | absent |
The last two rows are the ones that separate these four. Three of them are records of an authorisation: who allowed what, bound how well. One is a record of what a system held to be true and what contradicted it. That is not a scoreline either, because the other three are not trying to carry it, but it is why a reader cannot substitute one for another. EU AI Act Article 86 asks an affected person's question, the main elements of a decision, and only those two rows speak to it at all.
Three of these four ask a deployer to adopt something. The fourth is the pipe an enterprise already has: almost everybody running agents in production is already emitting OpenTelemetry, because that is where their traces go.
Counted on 9 September 2026 from model/gen-ai/registry.yaml, the GenAI semantic conventions carry seventy two gen_ai.* attributes. Searching all seventy two for approver, human, authorisation, oversight, review, principal, consent and actor returns nothing. There is gen_ai.agent.id, which is the agent's own identifier, and reading that as an approver would tell a reader they can say who approved when what they have is the agent approving itself.
The count was sixty one on 8 September, against the old location in open-telemetry/semantic-conventions before the GenAI conventions moved to their own repository. The conventions are growing quickly, so re-count this rather than cite it.
This is not a criticism of OpenTelemetry, which is a telemetry carrier and has never claimed to be an oversight record. It is a statement about what a deployer whose logs are spans can produce, which is a different thing and a more consequential one, because it is not a choice they made about oversight. It is a gap they will discover when somebody asks.
The SCITT column is mostly absent and that is not a criticism. A transparency receipt is not trying to answer these questions. Read its integrity row and disregard the rest.
On where an identity was resolved from, the Testimony Record carries a string that the emitter writes. An EMILIA receipt carries a user-verified signature under an enrolled key, so the answer is a property of the artifact rather than a claim inside it. A string can say webauthn and be wrong. A signature cannot.
On showing the rows unaltered, both work, and the EMILIA construction is the stronger of the two because it binds the approver to the exact action before it runs rather than sealing a record after it.
On what a reviewer was shown, neither format carries it. The EMILIA author says so themselves and has published a separate draft about the problem, draft-schrock-ep-presentation-binding-00, which proposes a deterministic renderer so that a verifier can re-derive the rendering from the signed bytes. That is further than this project has taken the same question.
The tool behind this page can also read a format nobody has declared, by matching field names. That is useful for reconnaissance and it is not safe next to a statutory clause, and the reason is a mistake it made on 9 September 2026.
Reading an EMILIA receipt against Colorado, it reported that the record could evidence section 6-1-1701(15)(a), the reviewer considering relevant available primary evidence. It could not. The field payload.decision.subject_ref had matched a signal named source on nothing but the fragment the two names share. subject_ref names the applicant.
So a format that has been read is declared, a format that has not is inferred and every report says which. A declaration removes the guessing and not the checking: it says where a signal would live, and a record still has to have put something there.
It is not a score. Counting the filled cells in each column would compare what the three formats were built for, not how well they were built. A record of a whole case answers more questions than one authorization receipt, because it is a different kind of document.
It is not a conformance assessment. Whether an obligation is met is a judgement somebody qualified makes on evidence. This says where the evidence would be.
It is not an endorsement of any of the three, including the one maintained here.
Each reading is of a published document at a named revision, on a named date. If a format has been misread, that is cheap to demonstrate and the correction changes this page and the date on it. The declarations are published as data in spec/formats.py so that anybody can rerun them without asking, and each one records where it was read and when.
Formats not yet read are missing rather than judged. A format is added when somebody has read it against these questions, not when somebody asks for it to be added.
The readings are CC BY 4.0, which asks for attribution, so the reference is here rather than left to be composed. This block is generated from the page it sits on, so a date that moves here moves in the citation too.
Clifford, T. (2026). Which record formats can evidence a human review, and which cannot. Machine Testimony. https://machinetestimony.org/formats/@misc{clifford2026formats,
author = {Clifford, Troy},
title = {Which record formats can evidence a human review, and which cannot},
year = {2026},
note = {Machine Testimony, read 9 September 2026},
url = {https://machinetestimony.org/formats/},
}This page carries no DOI. It cites its dated URL, and saying so is the point: a citation naming a deposit that does not exist is worse than one naming a page that does.