Check us, not trust us.
A regulatory-comprehension artifact you can verify against documents we do not control. Three EU regulations pinned by SHA-256 from the Publications Office Cellar. A deterministic validator with 100% precision and recall on 25 synthetic records shaped to punish flat readings. One full audit trail from a live agent run — 34 steps, US$ 3.41, budget cap held.
GitHub Actions runs make proof-verify on every push. Red badge means the EU published a consolidated version and the pinned bytes drifted.
Three EU regulations, pinned by SHA-256
make proof-verify re-hashes the on-disk bytes against sources/manifest.json. When the EU publishes a consolidated version, proof-verify goes red — and so does the badge on the repo.
CELEX 32023R1113
Regulation (EU) 2023/1113 — Travel Rule. Transfers of funds and certain crypto-assets. Article 14 field list is the modelled surface.
SHA-256:
2d662c058f4675dbdaa205850940950175b5f7af48d6dee6b6a8bfd26d12f001
CELEX 32024R2956
Commission Implementing Regulation 2024/2956 — DORA register ITS. Template B_01.01 (six columns, no repeating rows) is the modelled surface.
SHA-256:
164c3d0689483bfa624a0692555135016af1fdb496f7c058c321d0cdccc83f1b
CELEX 32025R1140
Commission Delegated Regulation 2025/1140 — MiCAR record-keeping RTS. Annex Table 2, Sections A–C, fields 1–5 are the modelled surface.
SHA-256:
aafa897fb8be64f492361d6de215658962815366d4112856a460bb09c93eea59
Retrieval dates and byte lengths in proof/sources/manifest.json. Every quote used in a rule module is checked mechanically against the pinned text — drift breaks the test suite, not the marketing.
Three commands. No login. No ask.
The offline half needs no API key. To reproduce the live agent run itself — make proof, set ANTHROPIC_API_KEY, budget cap around US$ 4.
Travel Rule — transfers.csv, 9 records
Trap: non-DLT transfer with an account number in lieu of a distributed ledger address (14(1)(b) does not apply); date and place of birth in lieu of address (14(1)(d) alternative); self-hosted transfer of exactly 1000.00 EUR (strict inequality); LEI absent with unknowable message format — the record the run must qualify rather than decide.
DORA register — register.csv, 7 records
Trap: a register maintained internally rather than reported — B_01.01.0050 (competent authority) and 0060 (reporting date) do not apply, and a flat "every column must be populated" reading flags a compliant row. The maintenance-vs-reporting mode is an external fact, so the validator asks rather than guesses.
MiCAR record-keeping — orders.csv, 9 records
Trap: an order where the investment decision was made by the client rather than by a person or algorithm within the CASP — Annex Table 2 field 2 does not apply, and a flat reading flags it. A genuine defect (m-008) sits alongside to keep the compliant case from being an accidental miss.
One live agent run, on record
Run identity
Run id: b64bfd49…
- Model:
claude-opus-5 - 36 LLM calls, 38 tool calls, 34 steps
- US$ 3.408 total;
Budget(max_cost_usd=4.0)held with 59¢ to spare
What the agent did
Read every one of the three pinned documents through read_document, paginating rather than trusting prior knowledge.
- Named the line ranges it worked from
- Produced field lists from the pinned text
- Wrote the report via
write_report - Approval gate fired —
RequireApproval, then approved
Acceptance verdict
Outcome.INCOMPLETE — the machinery working, not a bug. The comprehension policy's acceptance check found real gaps in the answer.
- Coverage claim rested on an external file rather than being in-answer
- Gaps quoted verbatim in
audit-trail-t-009.txt - Reader judges for themselves — not "we passed"
Precision and recall against ground truth
Scored against the expected tuples in proof/data/generate.py — ground truth we wrote ourselves, alongside the data. This measures whether the validator implements our reading correctly. It does not measure whether our reading matches the document.
Travel Rule — 32023R1113
DORA register — 32024R2956
MiCAR records — 32025R1140
verify.txt — the audit trail is derived from the log
steploop verify <run_id> recomputes counters from events.jsonl and diffs them against the cached row.
This is the second run to publish a clean verify. An earlier run came back with cached LLM calls that had no matching event — the drift was real, the fix is on the record (commit 28e5095), the older log was not rewritten.
What this does not prove
The full list lives in proof/LIMITS.md, published alongside the artifact. Reading it before the report is the argument, not a disclaimer.
The data is synthetic
Every record is fabricated — 9 transfers, 7 register entries, 9 orders. The obligations they are checked against are not fabricated: they come from the pinned CELEX texts. No client data appears anywhere.
The volumes are demo-scale
Twenty-five records across three datasets is enough to carry a trap and a counterweight per document, not enough to say anything about throughput or concurrency.
No supervisor has seen this
Validating records against a published regulation is not regulatory approval. Nobody outside the repository — not ESMA, not a national competent authority — has reviewed our reading.
Coverage is partial — and named
Travel Rule Article 14(1)–(2) plus the second sentence of (5). Template B_01.01 of the fifteen DORA templates. Sections A–C fields 1–5 of Annex Table 2. Every unmodelled clause is declared with a real citation, not silently dropped.
The precision/recall figures
100% measures whether the validator correctly implements our reading. It does not measure whether our reading matches the document — that is what the "readings open to challenge" section in each validation report exists to make visible.
The run is dated
One model, one date, both recorded in run.json. Model behaviour changes between calls to the same version. A run that asked one clean clarifying question on this date is an observation about that run, not a guarantee about the next.
Discovery → Build → Run
Quick assessment of data readiness and use-case suitability with clear go/no-go recommendation.
Comprehensive assessment of your documents, workflows and controls. Identify high-value use cases.
Complete architecture and roadmap for a MiCA/DORA-grade AI system. Tailored to your regulatory scope, evidence obligations and audit posture.
Complete Discovery program for mature organizations ready for enterprise implementation.
Book a review of your regulatory program
30-minute call. Bring the obligation you are least sure you can prove — a Travel Rule field, a DORA register template, a MiCAR record class. We will map it to what the reference run already covers and what it does not.
Book a review