Skip to content
Reality Graph

Regulation

The EU AI Act asks for records. Here is what a run writes.

DiffChecksScopeone ruleverifiedwith limitsblocked
The EU AI Act asks operators of high-risk AI systems for records that show what happened (Article 12) and for human oversight a person actually exercises (Article 14). Reality Graph produces artefacts of that shape as a by-product of how it works: a durable record per run, evidence read out of Git, and an approval bound to the exact state it was given for. It is designed to give your own assessment something factual to stand on. It does not make you compliant, it holds no certification, and the legal assessment stays with you and your counsel.

Last updated:

The mapping

Obligations on one side, artefacts on the other

Two of the duties in the regulation describe things a machine can produce: a record of what happened, and a decision a person made. The table lines those up with what a run writes to your disk, and with the part of each one Reality Graph does not cover.
What the regulation asks of an operatorWhat Reality Graph puts on the tableWhat 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 happenedChanged 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 assertedApproved 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 outcomeOne 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 alterationA 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.
How obligations the EU AI Act places on operators line up with the artefacts a Reality Graph run produces. Producing an artefact is not the same as discharging a duty, and no row here claims otherwise.

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

Nothing below was added for the sake of a regulation. It is the ordinary output of a run, which is the only reason it is worth anything as a record.

run-8c31.record.txt

Example – illustrative, not real run data
run         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 afterwards

Two 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

A page about a regulation is where marketing copy usually goes vague. These are the sentences that would be false, listed so their absence reads as a decision.

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.