One line per decision — why it decided what it did
An open standard for recording why an AI system decided what it did: one line per decision, capturing the values, evidence, and sources the system reports as decisive — carrying no user content. Model-agnostic, added by system prompt, MIT licensed.
AIO 20002 — an organization records every AI judgement in the shared vocabulary
The standard number is the goal statement. The digits 2·00·0·2 say whose values, in which domain, and which action this document covers.
Organization — teams, institutions, communities
Common — domain-independent
Base document
Record — log every judgement as hierarchy values
What this standard defines — the log grammar (tags, partial output, single-code emission), V/E/S hierarchy notation, the per-decision automatic emit format, and the three output modes. What it does not define — which judgements are right, or any evaluation of what is recorded. A record is material for comparison, not a verdict (non-normative).
About 60 characters, no user content
<aio20002_log> C:MED/IXi | V:Bec<Sda | E:Exp<Gui | S:Usr<Pro </aio20002_log>
No verbatim user content. Only topic-level metadata remains — the C: domain reveals “this was a healthcare question,” comparable to what existing routing logs already disclose.
- C — Context: domain, scope of impact, reversibility, time horizon
- V — Value hierarchy: which value priority prevailed
- E — Evidence hierarchy: which evidence type was decisive
- S — Source hierarchy: which source class was trusted
The ‘<’ reads as “outranked by”: left = deprioritized, right = prevailed. v1.1 allows partial output — context fields the model never assessed are recorded as ‘-’, and unengaged V/E/S layers are omitted instead of force-filled.
Step 2 of the integrity loop — Record
Records gain their baseline from the setting made in the previous step, AIO 20001 · Setting Workshop. The logs recorded here are analyzed in the next step, AIO 20003 · Benchmark.
Conventional logs record what — not why
Latency, token counts, request IDs, inputs and outputs — that is what conventional logs keep. But the questions asked of a deployed system after the fact are almost always “why” questions. Why was one consideration prioritised over another? What kind of evidence moved the decision? Which sources were treated as authoritative? Did any of that change between versions?
The existing answers do not scale. Free-text explanations address one decision at a time; prose cannot be counted, compared, or monitored for drift. Chain-of-thought traces are voluminous, contain user content, and are unsuitable as long-term records. So the layer that matters most for oversight is the layer least available in comparable form.
AIO 20002 makes that layer structured, comparable, and cheap to retain. One line per decision, drawn from a fixed vocabulary, so decisions aggregate across sessions, models, versions, and organisations — and two systems describing the same reasoning produce the same code. That last property is why this is a standard rather than a format: a bespoke schema, however well designed, only ever describes the system that produced it.
Regulatory compliance is one use, not the purpose
Inspect how a deployed system reasons across many decisions, rather than sampled transcripts.
Compare code distributions across model versions, prompt changes, and time.
Give a reviewer the reported grounds for a decision in a form readable at a glance.
Evaluate how different models prioritise under matched conditions.
Reconstruct the reasoning context around a specific decision.
Supply structured reasoning records where a regime asks for interpretability — see the EU AI Act case below.
Regulatory compliance is one use among these, not the purpose of the standard. It is, however, the use with the most developed mapping so far, and it is worked through in detail below.
Public repository — the spec and full prompts
The full AIO 20002 v1.1 specification, drop-in system prompts (EN + KR, all three modes), the validator and parser, and real log examples across domains all live in the public GitHub repository. MIT licensed — modify it, embed it in commercial products. The standard was published as PRISM through v1.0 and redesignated AIO 20002 under the AIO numbering scheme at v1.1; every valid v1.0 log remains valid.
Older models without structured output. The host strips the <aio20002_log> tag.
OpenAI, Gemini, Claude with JSON mode. It arrives as a separate JSON field.
Claude, OpenAI, Gemini with native tool use. It arrives as a separate tool_use block.
In every mode the log stays invisible to the end user — the host strips the tag, or it arrives as a separate JSON field or tool_use block.
Between recording more and retaining less
Oversight regimes push toward recording and exposing more (EU AI Act Articles 12, 13, 14); data-protection regimes push toward retaining less (GDPR Articles 5(1)(c), 17, 25). Both apply to the same system at once. The EU is the sharpest current instance, but the shape of the problem is not specific to Europe.
The usual privacy answer is hashing or pseudonymisation. That resolves the data-protection side and breaks the oversight side: a hash is not interpretable. It preserves integrity and defeats re-identification, but a reviewer reading it learns nothing about why a decision was made — which is the whole point of the record.
The difference is what the transformation preserves. Hashing replaces content with a meaningless string. A value hierarchy replaces it with a meaningful ground — which value outranked which, which evidence type was decisive, which source class was trusted — while carrying no verbatim content.
L3 Reasoning record (C/V/E/S) no verbatim content · longest useful retention L2 Context abstraction domain / scope / reversibility, not the input itself L1 Raw content short retention · access-controlled · deletable L0 Faithfulness verification evidence that L2–L3 labels track actual behaviour
Personal-data density falls as you move up the stack; useful retention period rises. But this is a design target, not a property the format confers. Abstraction is not automatic anonymisation — whether a record is anonymous is a case-by-case factual assessment (EDPB Opinion 28/2024). A reasoning line that can be re-linked to an individual through timestamps, session identifiers, or surrounding context remains personal data, and that call belongs to your DPO.
The EU AI Act — the only completed crosswalk so far
The EU AI Act is the first regime this standard has been mapped against in detail, and currently the only completed crosswalk — not because AIO 20002 is a European instrument, but because its requirements are the most concretely documented.
The reasoning layer does not actually sit in Article 12. Article 12 mandates automatic event logging for risk and operational traceability; it does not require capturing decision reasoning. The reasoning question — which values prevailed, which evidence was weighted, which sources were trusted — belongs to Article 13 (information that lets deployers interpret outputs) and Article 14 (oversight that correctly understands them). AIO 20002 fills the Article 13–14 interpretability need and makes your Article 12 logs readable, rather than filling a gap inside Article 12 itself.
AIO 20002 is a reasoning-trace addition to your existing event log pipeline. It does not, by itself, satisfy Article 12. You still need conventional lifecycle records — user identifiers, timestamps, session IDs (Art. 12(1)) — and the events that let you identify Article 79(1) risk situations, support post-market monitoring (Art. 72), and enable deployer monitoring (Art. 26(5)), which are the Article 12(2) purposes. Biometric systems (Annex III point 1(a)) are additionally bound by the Art. 12(3) content list. If you adopt AIO 20002 without conventional event logs, you remain non-compliant — stated plainly, because some marketing in this space implies otherwise.
What AIO 20002 produces → the provision it supports
| What AIO 20002 produces | EU AI Act provision it supports | Auditor-facing usefulness |
|---|---|---|
| One AIO 20002 line per substantive decision | Art. 12(1)Automatic record-keeping | A machine-generated reasoning trace, complementary to conventional event logs |
| The C: layer (domain / scope / reversibility / time) | Art. 12(2)Traceability of risk situations | A per-decision risk-context tag |
| Aggregate C: distribution across the operating period | Art. 12(2)Operational traceability over time | Volume and category of decisions over time |
| The V: and E: hierarchies | Art. 13Transparency of reasoning (supports; Art. 13's primary frame is deployer-facing transparency) | Reported value priorities and evidence types behind outputs |
| A structured single-line code, grep- and SQL-friendly | Art. 14Human oversight enablement (contributes; Art. 14's core requirement is human stop/override capability) | A format that lets a human auditor inspect AI behaviour at scale |
| Aggregate code distribution across versions | Art. 15Accuracy and robustness monitoring | Drift detection signals across model versions |
| Anomalous code patterns (e.g. unexpected V: flips, S:Ano surges) | Art. 9 · 72Risk management & post-market monitoring (upstream inputs) | A pre-investigation signal source |
Reading guide — “supports” and “contributes to” are deliberately weaker than “satisfies.” AIO 20002 logs alone do not discharge any of these obligations. What they do is give your compliance program structured evidence that auditors and notified bodies reference alongside your governance documentation, conventional event logs, risk management documentation, and post-market monitoring outputs.
What this does NOT claim
- Not proof of true reasoning. LLM self-reports can be post-hoc rationalisation. AIO 20002 logs are reported reasoning, not causal traces. (This limitation applies equally to chain-of-thought, attention traces, and human-written documentation.)
- Not a substitute for independent audit. Internal records need external verification to carry regulatory weight.
- Not a replacement for conventional event logs. See the complementary-layer note above.
- Not automatic compliance. This is a structured evidence layer. Compliance under any regime depends on the full governance system around it — risk management, data governance, conventional logging, transparency, human oversight, accuracy and robustness, quality management, post-market monitoring, and incident reporting.
- Not a sole-source solution. AIO 20002 is one component of a broader toolchain, alongside conventional event-log logging, chain-of-thought capture, NIST AI RMF documentation patterns, and IBM AI FactSheets.
What it is: an open, structured, regulator-legible format for the reasoning layer of your evidence — available today, free, and forkable.
Log Playground — paste and decode
Copy a prompt from the repository, run it in your own AI, then paste the response here to see the log expanded into readable sentences. Load an AIO 20001 setting and it also checks the recorded judgments against the direction you declared. The response body is never stored.
Mapping to other regulatory frameworks
AIO 20002 crosswalks to other major frameworks — the NIST AI Risk Management Framework, ISO/IEC 42001 (AI management systems), Korea's AI Basic Act, and Japan's AI Business Operator Guidelines — are in progress as separate RFCs; the EU AI Act is the only completed mapping so far. Proposals and participation are welcome via GitHub Issues.