Regulation
The EU AI Act asks for records. Here is what a run writes.
Last updated:
The mapping
Obligations on one side, artefacts on the other
| What the regulation asks of an operator | What Reality Graph puts on the table | What it does not do |
|---|---|---|
| Records that show what the system did (Article 12) | A durable local record per run and its review, resolving by exact ID and surviving restarts. | Coding runs on your machine, not an AI system in production. A plain local file: no server, no retention policy, nothing shared. |
| Events traceable back to what actually happened | Changed files and diffs read from Git by Reality Graph itself, not taken from the model's account of its own work. | Git is required, and capture fails closed above 500 KB of scrubbed diff rather than reporting a partial picture. |
| Results that can be checked rather than asserted | Approved commands run as an argv list with no shell, and the observed exit code is recorded, marked either executed by Reality Graph or attested by the operator. | A pass means the command exited zero, not that the task was done correctly. An attested exit code is typed in by a person and is never validated. |
| One consistent account of the outcome | One verdict from one pure function with one call site in the product; a run refuses to persist unless it is bound to a review whose hash matches. | The verdict is a signal for your team, not a certificate, and it does not prove the code is correct. |
| Human oversight, exercised on the actual change (Article 14) | An approval bound to the run, HEAD, scope and validation fingerprint it was given for, and marked stale the moment any of those move. | A local attestation, not identity and not a signature. There are no accounts, and no way to verify who sat at the keyboard. |
| Records protected against quiet alteration | A content digest on every validation receipt, plus an opt-in hash-chained log that detects edits, reordering, dropped and duplicated entries and verifies offline. | Opt-in, and every append is explicit: governed runs are not written to it automatically. Digests catch careless edits, not a determined attacker, and nothing is signed. |
Both articles bind high-risk AI systems. A team writing ordinary software with a coding assistant is usually nowhere near that category, and Reality Graph does not settle the question either way: it classifies no risk category and decides no scope. Roles, categories and the current deadlines are the subject of the article on the EU AI Act for development teams; this page stays on the artefacts.
The artefact trail
What one run writes down, in the order it happens
run-8c31.record.txt
Example – illustrative, not real run datarun 8c31 opened 2026-08-12 09:14 head 4a91f2c
scope app/billing/**, tests/billing/**
checks pytest -q -> exit 0 (executed by Reality Graph)
npm run lint -> exit 0 (attested by the operator)
evidence changed files read from Git (5 files, 118 lines)
verdict VERIFIED WITH LIMITATIONS (one attested result)
approval recorded at head 4a91f2c, bound to scope + validation fingerprint
digest sha256:9f2c… receipt flagged if edited on disk afterwardsTwo of those lines carry the distinction the rest of the record rests on. An executed result carries the exit code Reality Graph read from a command it started itself; an attested one carries what a person typed in, is never validated, and is why this run closed as verified with limitations rather than verified. How the outcome is computed is on the verdict page.
The record persists locally and resolves by exact ID, so the run from six weeks ago opens as readily as this morning’s; export is one explicit command at a time, with no schedule and no shared destination. The approval line behaves the way a reviewer would want: move HEAD, widen the scope or change which checks count, and it goes stale rather than travelling silently to a change nobody looked at. The mechanism is on the approvals page, and where the data physically sits is on the data-path page.
By design
What this page will not tell you
What a run leaves you
- A durable local record per run and its review, resolving by exact ID and surviving restarts.
- Changed files and diffs read from Git, not taken from the model's prose.
- A validation receipt per check with the exit code that was observed, marked executed or attested.
- One verdict per run from a single function with one call site, and the reason beside it.
- An approval bound to the run, HEAD, scope and validation fingerprint, marked stale when any of those move.
- An optional hash-chained log that detects edits, reordering, dropped and duplicated entries.
What it is not
- Compliance. No article of the regulation is satisfied by installing a tool, and nothing here is claimed to satisfy one.
- A certification. None is held at any price, and no external audit stands behind these records.
- A risk classification. Reality Graph does not decide whether a system is high-risk, or whether you are in scope.
- An identity. The approval is a local attestation, not a signature, and no accounts exist to attach a name to.
- A team system. Single operator, one machine: no roles, no shared history, no SSO and no centralised audit.
Validated on Linux with Python 3.12; Windows and macOS are unverified in the current release matrix. The legal assessment stays with you and your counsel or data protection officer.
Questions people actually ask
- Does this make us compliant?
- No. Compliance is a property of your organisation and the system you operate, established by your own assessment, and no tool confers it. What Reality Graph gives you is material for that assessment: a durable record per run, diffs read out of Git rather than taken from the model's prose, receipts carrying the exit code that was observed, and an approval bound to the state it was given for. Whether that speaks to a duty you actually have is your counsel's call.
- Which articles are you even talking about?
- Article 12 on record-keeping and Article 14 on human oversight. Both bind high-risk AI systems, and both describe duties a machine can produce something concrete for. Whether they reach your organisation at all is a scope question this page does not answer.
- Is a Reality Graph record an audit trail?
- Only in the plain sense of those words: a local file that records what happened and, in its chained form, detects edits, reordering, dropped and duplicated entries. There is no centralised audit system, no accounts behind the entries, and nothing is signed or notarised.
- Can we hand these records to an auditor or a customer?
- You can export them: local JSON or Markdown, produced on demand and scrubbed of home paths and secret-shaped strings first. They show which checks ran, who decided what and at which commit. They do not show that the code is correct.
- Does the approval prove a person exercised oversight?
- It proves an approval was recorded locally against one run, one HEAD, one scope and one validation fingerprint, and that it goes stale as soon as any of those move. It does not prove who gave it: there are no accounts and no way to verify a human.
Bring artefacts to the conversation, not adjectives
The next time someone asks how AI-assisted changes are controlled here, the answer can be a record with a date, a diff and a decision on it.