Skip to content
OpenRegs
Open core — Apache-2.0 engine, CC BY 4.0 corpus

AI agents that follow the law.

OpenRegs turns financial regulation into versioned, machine-readable, cryptographically verifiable data. Your agents connect over MCP and answer with citations into verified, point-in-time law — so the people who have to defend those answers can check them instead of trusting them.

  • Every answer cites

    An eId or atom id, back to the official text

  • Point in time

    The law as it stood on the date you ask about

  • Signed releases

    Verified before anything is served

How it works

From a regulator's PDF to an answer you can defend

Six stages, each handing a checked result to the next. Every one of them leaves a trace, which is what makes the last one — the answer your agent gives — something an auditor can follow back to source.

  1. 1. Ingestion

    Take the regulator's own document

    Watchers poll the official publishers — EUR-Lex, legislation.gov.uk, the eCFR, national gazettes — and keep the exact bytes they published, filed under the fingerprint of those bytes. Nothing downstream can quietly differ from what was fetched.

  2. 2. Consolidation

    Apply the amendments, date by date

    Regulators publish a base act and then amend it. The engine applies those amendments in order to reconstruct what the text actually said on any given day, and records which amending instrument produced each change.

  3. 3. Atomization

    Turn duties into records a system can act on

    A model proposes small records — who must do what, under which conditions — each quoting its provision word for word. The model proposes; it never decides. A human maintainer reviews and merges every one.

  4. 4. Canon

    Keep it in the open, under review

    Texts, duties and the cross-reference graph live in git, where every change is attributable and every change is checked: schemas, provenance, permanent identifiers, graph integrity.

  5. 5. Release

    Publish a dated, signed edition

    The reviewed corpus is compiled into dated artifacts and signed, with provenance attached. The same corpus commit always builds the same bytes, so a release can be reproduced and checked rather than taken on trust.

  6. 6. Serving

    Answer, with the receipt attached

    A REST API and an MCP server answer against one pinned release, always returning citations — and verify signatures and provenance before serving anything. The same release runs inside your own network, giving the same answers.

What every answer carries

Built to be checked, not trusted

Compliance and litigation risk does not come from an agent being wrong once. It comes from nobody being able to tell. These are the properties that make the difference.

Provenance, end to end
Every canonical text traces to the fingerprint of the document the regulator published. No entry in that ledger, no publication.
Quotes, not paraphrases
A duty carries the exact characters it was read out of. A record that paraphrases its provision fails validation and never reaches the corpus.
Answers scoped to a date
Every answer names the release it came from and the date it was answered for, because a provision only means something on a day.
Reproducible builds
The same corpus commit produces byte-identical artifacts, so a release can be rebuilt independently and compared rather than believed.
Permanent identifiers
Identifiers are never reused. A citation you wrote into a control, a policy or an audit file still points at the same thing years later.
Refuses what it cannot verify
Signatures, digests and provenance are checked before a release is unpacked or served. An artifact that does not verify is not answered from.

Read the engine before you trust the answers.

The pipeline, the schemas, the checks and the fixture corpus are all public. That is the argument: you do not have to take our word for how an answer was produced.

Self-hosting needs nothing you cannot get under an open licence.