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.
⚖️ Built for two directions at once. Oversight rules push toward recording more — EU AI Act Articles 13–14. Data-protection rules push toward retaining less — GDPR Articles 5, 17, 25. AIO 20002 keeps the reasoning readable while carrying no user content. How, and under what conditions →
-red.svg){kind=icon}
ℹ️ v1.1 — renamed and extended (July 2026). This standard was previously published as PRISM. It is now designated AIO 20002 under the AIO standard numbering scheme. v1.1 also introduces partial output: context fields the model never assessed are recorded as
-and unengaged V/E/S layers are omitted instead of force-filled. Every valid v1.0 log remains valid, and the tools in this repo still accept the legacy<prism_log>tag. Details in the CHANGELOG and SPECIFICATION.
What AIO 20002 is — and isn't. AIO 20002 records reported reasoning — the values, evidence, and sources a model says drove a decision — not causal traces of its internal computation. That distinction is deliberate and load-bearing: it defines both what the record is good for and what it cannot be asked to prove. See What this does NOT claim.
<aio20002_log>
C:MED/IXi | V:Bec<Sda | E:Exp<Gui | S:Usr<Pro
</aio20002_log>
Approximately 60 characters. No verbatim user content. Topic-level metadata only (the C: domain reveals "this was a healthcare question" — comparable to what existing routing logs already disclose).
The line decodes as:
- 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.
Conventional logs record what an AI system did — latency, tokens, request IDs, inputs and outputs. They do not record why it did it.
That gap matters because 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 can be aggregated across sessions, models, versions, and organisations — and so two systems describing the same reasoning produce the same code.
That last property is the point of a standard rather than a format. Shared vocabulary is what makes records from different systems comparable at all; a bespoke schema, however well designed, only ever describes the system that produced it.
| Use | What the record supports |
|---|---|
| Behavioural auditing | Inspect how a deployed system reasons across many decisions, rather than sampled transcripts |
| Drift detection | Compare code distributions across model versions, prompt changes, and time |
| Human oversight | Give a reviewer the reported grounds for a decision in a form readable at a glance |
| Model comparison | Evaluate how different models prioritise under matched conditions |
| Incident investigation | Reconstruct the reasoning context around a specific decision |
| Regulatory evidence | Supply structured reasoning records where a regime asks for interpretability — see the EU AI Act case |
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.
Records of this kind run for years across large numbers of decisions. Format determines whether they stay usable.
| Property | AIO 20002 code | JSON equivalent |
|---|---|---|
| Length | ~60 chars | ~300+ chars |
| Output token cost | ~25–40 tokens (model-dependent) | ~150+ tokens |
| Privacy | No verbatim content; topic-level metadata only | Risk of context leakage |
| Aggregation | Direct grep / SQL after extraction | Requires flattening |
| Reviewer scan rate | High | Low |
The log is a structural fingerprint, not a summary. Conversation content stays in the conversation log. The AIO 20002 line captures only what is needed for behavioural comparison at scale.
For deployments at >1M logs/day, plan an ETL pipeline (Airflow / Spark / ClickHouse / similar). The Python parser (tools/aio20002_parser.py) is suitable for batch validation and small-scale querying, not for streaming aggregation.
Wherever oversight duties and data-protection duties apply to the same system, they pull in opposite directions. Oversight regimes push toward recording and exposing more; data-protection regimes push toward retaining less. The EU is the sharpest current instance — the AI Act's Articles 12, 13 and 14 against the GDPR's data minimisation (Art. 5(1)(c)), right to erasure (Art. 17), and data protection by design (Art. 25) — but the shape of the problem is not specific to Europe.
Both sets apply at once. Logs accumulate inputs, interaction traces, and decision parameters — records an operator is obliged to keep and, simultaneously, obliged to minimise and delete on request.
The usual privacy answer is to hash or pseudonymise. 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.
| Approach | Traceability | Interpretability | Data minimisation |
|---|---|---|---|
| Raw content logging | Yes | Yes | Poor — accumulates personal data |
| Hashing / pseudonymisation | Yes | No — opaque by construction | Yes |
| Abstracted reasoning record | Supports | Yes — records the grounds | Conditional — see below |
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. The record stays readable to a human reviewer without carrying the material that made it sensitive.
AIO 20002 does not replace raw logs. It sits above them:
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
(incl. fields a regime requires verbatim)
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. The layer you are asked to keep longest is the layer carrying the least personal data.
This is a design target, not a property the format confers. Four caveats belong with the table above.
- Abstraction is not automatic anonymisation. Whether a record is anonymous is a factual, case-by-case assessment — see 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, with the minimisation and erasure obligations that follow. Whether a given deployment clears that bar is a question for your DPO — not one a log format can answer, and not one this repository claims to have settled. The retention picture above holds only where it is genuinely cleared.
- Faithfulness is the load-bearing assumption. A reasoning record that does not track the model's actual behaviour delivers privacy and false assurance at the same time. That is why L0 sits in the stack rather than beside it. See What this does NOT claim.
- Raw fields are still required in places. Some regimes mandate verbatim content for particular system classes, and incident investigation generally needs L1.
- Not reflected in harmonised standards. No standards body deliverable currently specifies a reasoning-record layer. Being early is a position, not an endorsement.
Three output modes — pick the one your model supports.
| Mode | When to use | User sees log? |
|---|---|---|
| A. Inline tag | Older models without structured output | No (host strips <aio20002_log> tag) |
| B. Structured output (JSON) | OpenAI, Gemini, Claude with JSON mode | No (separate JSON field) |
| C. Tool call | Claude, OpenAI, Gemini with native tool use | No (separate tool_use block) |
System prompts (drop into your existing system message):
Value vocabulary: the 19-value profile (Schwartz et al. 2012, Refined Theory of Basic Values) — the single value profile of the standard since v1.1. (The coarser 10-value 1992 profile was retired in v1.1; legacy v1.0 logs using it remain valid historical records but must not be aggregated with 19-value logs.)
system_prompts/aio20002_v1_en_inline_19v.md— Mode Asystem_prompts/aio20002_v1_en_json_19v.md— Mode Bsystem_prompts/aio20002_v1_en_tool_19v.md— Mode C
Critical: In all modes and profiles, the AIO 20002 log is for audit storage only — never shown to end users. Mode A requires the host to strip the tag. Modes B and C provide separation natively.
System prompt drop-in is a quick first step. Full deployment requires:
- Output validation (handling malformed codes)
- Wiring
aio20002_codeinto your existing log pipeline (database, S3, SIEM) - Hashing at storage time
- A retention policy aligned with your sector requirements
- Drift monitoring on aggregate distributions
The system prompt addition itself takes minutes. Production deployment typically takes longer.
from anthropic import Anthropic
client = Anthropic()
AIO20002_TOOL = {
"name": "record_aio20002_log",
"description": "Record the AIO 20002 log for a substantive decision.",
"input_schema": {
"type": "object",
"required": ["code"],
"properties": {"code": {"type": "string"}}
}
}
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=2000,
system=AIO20002_MODE_C_PROMPT, # from system_prompts/aio20002_v1_en_tool_19v.md
tools=[AIO20002_TOOL],
messages=[{"role": "user", "content": user_input}]
)
# User-facing text and audit log are separate blocks
user_facing = ""
aio20002_code = None
for block in response.content:
if block.type == "text":
user_facing += block.text
elif block.type == "tool_use" and block.name == "record_aio20002_log":
aio20002_code = block.input["code"]
# user_facing → user interface
# aio20002_code → audit log storageWire aio20002_code into your existing log pipeline. Run tools/aio20002_hash.py at storage time for chain integrity.
| Provider / Model | Profile | Mode A | Mode B | Mode C |
|---|---|---|---|---|
| Anthropic Claude (Sonnet 4.5) | 10v | tested | tested | tested |
| Anthropic Claude (Sonnet 4.5) | 19v | tested | tested | tested |
| OpenAI GPT family | both | expected to work; community validation in progress | expected to work | expected to work |
| Google Gemini family | both | expected to work; community validation in progress | expected to work | expected to work |
| Open-source models (Llama, Mistral) | both | expected to work; community validation pending | varies by inference stack | varies |
We will update this table as community validation reports come in. Output token cost depends on tokenizer; expect roughly 25–40 tokens per code in practice (model-dependent). Measure on your stack before sizing.
The EU AI Act is the first regime this standard has been mapped against in detail, and currently the only completed crosswalk. It is included here because it is the most demanding published articulation of what an interpretability record has to do — not because AIO 20002 is a European instrument.
Crosswalks to other regimes are open contributions. If you have worked AIO 20002 against NIST AI RMF, ISO/IEC 42001, a sectoral regulator, or a national AI statute, a mapping document is a welcome pull request. Nothing below should be read as implying equivalent mappings exist elsewhere; they do not yet.
AIO 20002 is a reasoning-trace addition to your existing event log pipeline. It does not, by itself, satisfy Article 12.
You still need to log:
- User identifiers, timestamps, session IDs — your conventional lifecycle records under Article 12(1)
- The events that let you identify Article 79(1) risk situations, support post-market monitoring (Article 72), and enable deployer monitoring (Article 26(5)) — the Article 12(2) purposes every high-risk log must serve
- Biometric systems only (Annex III point 1(a)): period of use 12(3)(a), reference database 12(3)(b), input data searched 12(3)(c), persons verifying results 12(3)(d) (cross-refers Article 14(5)). Non-biometric high-risk systems are not bound by this 12(3) content list — they remain bound by 12(1)–(2), specified differently, not more lightly.
AIO 20002 augments these with a per-decision reasoning fingerprint. It does not replace any of them.
A common compliant deployment looks like:
[Conventional event log] → input/output/timestamp/user-ID
+
[AIO 20002 reasoning log] → C/V/E/S code per substantive decision
+
[Hashing layer] → SHA-256 chain over both, for tamper-evidence
↓
[Audit storage] → indexed, retained per Article 12 requirements
If you adopt AIO 20002 only, without conventional event logs, you remain non-compliant. We mention this prominently because some marketing in this space implies otherwise — it is not true.
On 7 May 2026, the Council and Parliament reached provisional political agreement on the Digital AI Omnibus. If adopted as negotiated, the high-risk timeline that drove the original urgency of this repository has been pushed back — but not removed. The structured-logging problem is still very real; the enforcement clock just moved.
| Obligation | Previous date | New date (Omnibus) |
|---|---|---|
| Annex III stand-alone high-risk systems — Articles 9–17, including Art. 12 logging | 2 August 2026 | 2 December 2027 |
| Annex I product-embedded high-risk systems | 2 August 2027 | 2 August 2028 |
| Article 50 transparency (gen-AI output marking, deepfake disclosure) — not a GPAI provision; GPAI = Arts 53–55 | 2 August 2026 | Application unchanged (2 August 2026); transitional compliance to 2 December 2026 for systems already on the market (4-month grace — Recital 20 & new Art. 111(4)) |
| Prohibited practices (Art. 5) | Already in force (Feb 2025) | Unchanged |
| General-purpose AI model obligations (Art. 53–55) | Already in force (Aug 2025) | Unchanged |
The Omnibus is provisional until the Council and Parliament formally adopt the regulation amending Regulation (EU) 2024/1689. The dates above reflect the political agreement of 7 May 2026 and are expected to be finalised through ordinary legislative procedure. Confirm against the published amending regulation before treating any date as final. Sources: Council press release, 7 May 2026; European Parliament press release, 16 Mar 2026; Digital Omnibus on AI — Legislative Train.
-
The Article 12 logging requirement is still coming. It applies in roughly 19 months (Dec 2027) for Annex III systems and roughly 27 months (Aug 2028) for Annex I product-embedded systems. The CEN/CENELEC harmonised standards work continues in parallel and is unlikely to land materially earlier than the new enforcement dates.
-
The standard-vacuum window is now longer, not shorter. Operators who were waiting for the harmonised standard before designing their reasoning-log layer now have more time to make the wrong architectural choice. The case for adopting a deployable open pre-standard during this window is stronger, not weaker.
-
December 2026 is a deadline many teams should also be watching. Article 50 transparency obligations apply to far more systems than Annex III high-risk classification. Article 50(2) still applies from 2 August 2026; systems already on the market get a transitional 4-month compliance period to 2 December 2026 (Recital 20 & new Article 111(4)). The Commission had proposed six months and Parliament three — the agreed text landed at four.
-
Penalty caps are unchanged. Article 99 still sets penalty caps at €15 million or 3% of worldwide annual turnover for operator-obligation breaches and €35 million or 7% for prohibited practices. The delay reduces when, not whether, those caps apply.
Article 12 mandates automatic event logging for risk and operational traceability — its purposes run to Article 79(1) risk identification, Article 72 post-market monitoring, and Article 26(5) deployer monitoring. 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). Conventional logs (latency, token count, request ID) cover much of Article 12, but none of them carry that interpretive layer — and Article 12 does not ask them to. 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.
Official harmonised standards (CEN/CENELEC) are still under development. Their delivery window has not been extended in line with the new enforcement dates. Operators cannot wait for them to begin structured logging.
This repository is a working pre-standard you can deploy today as one component of a broader compliance program. The longer runway is a feature: it lets early adopters accumulate 12–24 months of baseline behavioral data before enforcement, instead of scrambling for retrofit evidence in 2027.
The left column lists what AIO 20002 technically produces. The right column maps each item to the EU AI Act provision it supports (not single-handedly satisfies). Your full compliance program — risk management, data governance, post-market monitoring — must be built around the entire Article 9–17 obligations, not AIO 20002 alone.
| 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 | Machine-generated reasoning trace, complementary to conventional event logs |
C: layer (domain / scope / reversibility / time) |
Art. 12(2) — Traceability of risk situations | Per-decision risk-context tag |
Aggregate C: distribution across operating period |
Art. 12(2) — operational traceability over time (period-of-use specifics are 12(3)(a), biometric only) | Volume and category of decisions over time |
SHA-256 chained hash via tools/aio20002_hash.py |
Integrity / tamper-evidence — Recital 71 (traceability & lifetime logging) with Art. 15(4)–(5) (robustness/integrity); not literal Art. 12(3) text | Chain-of-custody evidence for the log stream |
V: and E: hierarchies |
Art. 13 — Transparency of reasoning (supports; Art. 13's primary frame is deployer-facing transparency) | Reported value priorities and evidence types behind outputs |
| Structured single-line code, grep- and SQL-friendly | Art. 14 — Human oversight enablement (contributes; Art. 14's core requirement is human stop/override capability) | Format that lets a human auditor inspect AI behaviour at scale |
| Aggregate code distribution across versions | Art. 15 — Accuracy and robustness monitoring | Drift detection signals across model versions |
Anomalous code patterns (e.g. unexpected V: flips, S:Ano surges) |
Art. 9 & 72 — risk management & post-market monitoring (upstream inputs that may lead to an Art. 73 report) | Pre-investigation signal source |
S: source hierarchy |
Context only — not a formal Art. 10 mapping (Art. 10 governs training/validation/test data quality, not per-decision telemetry) | Per-decision record of which source class was trusted |
Reading guide: "Supports" and "contributes to" are deliberately weaker than "satisfies." AIO 20002 logs alone do not discharge any of these obligations. They 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. See DISCLAIMER.md.
For Article 12(3) specifically: that subsection lists minimum logging contents for biometric identification systems (Annex III point 1(a)) and does not generically require hashing. The hash tool we provide is a defensive integrity measure, not a literal Art. 12(3) implementation.
On "risk" in Article 12(2): the operative threshold is external. Through Article 79(1) it takes the meaning of a "product presenting a risk" under Article 3(19) of the Market Surveillance Regulation (EU) 2019/1020, extended to fundamental rights — the bar that triggers evaluation, corrective action, withdrawal, or recall. Built-in logs must be able to surface that, a heavier standard than recording what merely looks risky.
On the Omnibus and this repository's premise: the May 2026 delay does not modify Articles 9–17 themselves; it modifies when they apply. The substantive obligation that motivates this crosswalk — auditable per-decision reasoning records — has not been altered.
Stated plainly so your engineers, legal counsel, and any assessor know what they are reading:
- 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 section 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. Other relevant approaches include conventional event-log logging, chain-of-thought reasoning capture, NIST AI RMF documentation patterns, and IBM AI FactSheets. Pick the combination that fits your governance program.
What it is: an open, structured, regulator-legible format for the reasoning layer of your evidence — available today, free, and forkable.
What AIO does and doesn't do. AIO defines the vocabulary, the regulatory crosswalks, and conformance criteria. AIO does not build or operate your logging system, retention infrastructure, or monitoring pipeline.
On the EU AI Act specifically, AIO does not:
- act as a notified body / conformity-assessment body, or issue EU AI Act compliance certifications — that is the role of accredited notified bodies and competent authorities;
- audit a deployer's regulatory compliance.
Separately, AIO does run its own programs and may offer optional, standalone certification against AIO's own standards — for example an AIO 20002-Compliant conformance mark, training courses and their certificates, and certification for future AIO measurement frameworks. These attest alignment with an AIO standard; they are not a determination of compliance under any statute, and the standard remains free to use without them.
AIO 20002 is a protocol, not a platform or a compliance service. Implementing, operating, and any regulatory audit belong to the parties below; AIO 20002 is the common format they plug into.
| Role | What they do | Where AIO 20002 fits |
|---|---|---|
| Operator / deployer | Build event logs, retention, risk & post-market monitoring | Emit the AIO 20002 code per decision; wire it into the log pipeline |
| Compliance team / consultancy | Implement and assess the governance program for clients | Use AIO 20002 as the structured reasoning layer; apply the relevant crosswalk |
| Notified body / competent authority | Conformity assessment & certification | Read AIO 20002 logs as auditor-supporting evidence (reported reasoning), alongside the rest of the technical file |
| AIO | Maintains the format, crosswalks & conformance criteria; offers optional AIO 20002 conformance certification & training (not statutory certification) | — |
| File | Purpose |
|---|---|
SPECIFICATION.md |
Complete v1.1 code specification (includes output mode definitions) |
DISCLAIMER.md |
Scope, limitations, non-warranty terms |
system_prompts/ |
Drop-in system prompts (EN + KR; 10v + 19v; all 3 modes) |
examples/ |
Real-world log examples across 7 domains |
tests/validate.py |
Validator with multi-mode extraction (--profile=10v|19v) |
tools/aio20002_parser.py |
Code extraction and structured parsing |
tools/aio20002_hash.py |
SHA-256 integrity helper (independent and chained hashes) |
docs/integration_guide.md |
Per-provider integration guide |
docs/README_KR.md |
한국어 문서 |
MIT. Use it, modify it, embed it in commercial products. Attribution appreciated, not required. See LICENSE.
This standard is a technical specification, not legal advice. Using it does not guarantee compliance with any regulation. See DISCLAIMER.md for full scope and limitations.
AI Integrity Organization (AIO), a Swiss-registered nonprofit working on AI governance and behavioral auditability.
For the academic background of the AIO 20002 framework, see the working papers:
- S. Lee (2026a). AI Integrity: A New Paradigm for Verifiable AI Governance. arXiv:2604.11065 [cs.AI].
- S. Lee (2026b). PRISM Risk Signal Framework: Hierarchy-Based Red Lines for AI Behavioral Risk. arXiv:2604.11070 [cs.AI].
- S. Lee (2026c). Measuring the Authority Stack of AI Systems: Empirical Analysis of 366,120 Forced-Choice Responses Across 8 AI Models. arXiv:2604.11216 [cs.AI].
The 19-value profile draws specifically on:
- Schwartz, S. H., Cieciuch, J., Vecchione, M., Davidov, E., Fischer, R., Beierlein, C., et al. (2012). Refining the theory of basic individual values. Journal of Personality and Social Psychology, 103(4), 663–688.
- Issues / suggestions: GitHub issues
- Commercial inquiries: 2sk@aioq.org
- Website: aioq.org