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

World regulation as a git repository.

OpenRegs turns published regulation into structured, machine-readable obligations, kept in git. Every amendment lands as a diff you can subscribe to. Every obligation quotes the provision it was read out of, and can be mapped to the control that discharges it. Your systems — and the agents acting for them — read it over REST or MCP and answer with citations somebody can check.

See what is openRead the documentation

Where this stands today. The machinery is built and runs. The law is not loaded yet: one regime exists and it is a synthetic fixture, deliberately about nothing. Everything below describes the engine, not a corpus you could query for an answer about your own obligations. Which regimes are named, and what state each is in.

The problem

Regulatory change is tracked in spreadsheets, by people reading PDFs

Not because anyone thinks that is a good idea. Because the law is published as prose, and prose is the only form anybody has been given. Everything expensive about compliance follows from that one fact.

How it works now
The method a regulated firm actually uses, and what it costs.
  • A change arrives as a PDF or a web page. Nothing about it is machine-readable, so the first step is always a person reading.
  • Whether it touches you is decided from memory, by whoever happened to read it.
  • What it changed is described in a recital, not shown as a diff. Nobody sees the old words beside the new ones.
  • The link from a duty to the control that discharges it lives in a spreadsheet one person maintains.
  • Six months later, nobody can reconstruct what the rule said on the day a decision was taken under it.
  • Every downstream system re-does the same reading, differently, and the answers quietly disagree.
What a repository gives you instead
The same six problems, answered by the shape of the data rather than by more effort.
  • The consolidated text is data, and every obligation quotes the provision it was read out of, byte for byte.
  • A release is dated. You ask what a provision said on a day, and the answer names the release it came from.
  • Between two releases there is a diff, classified substantive or editorial, naming the instrument that did it.
  • That diff is a feed. Subscribe by jurisdiction, regime or entity type, and a signed notification is retried on a schedule and logged either way.
  • The mapping from duty to control is a file in your repository, reviewed like any other file.
  • A substantive change to a duty one of your controls discharges fails a check in the pull request that adopts it.
Follow one change through
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 — and with the diff against the release before it, so what changed travels inside the thing that changed. 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.

Subscribing to change

Every change lands as a diff you can subscribe to

A corpus somebody has to remember to re-read is a corpus that goes stale. What a team needs is to be told, where they already work, that something they depend on has moved — and to be stopped from adopting it unexamined.

  1. 01
    The change becomes a diff
    Two releases of one regime, compared: every unit and every obligation added, changed, removed or deprecated. Each is classified substantive or editorial — editorial only where the amending act's own recital says so, or the texts are equal under the whitespace policy. The manifest ships inside the release, so the diff travels with the data.
  2. 02
    You subscribe to it
    The same entries are served as a JSON Feed and an RSS feed, and POSTed to an endpoint you nominate — filtered by jurisdiction, regime and entity type, signed with your own secret, five attempts over two hours, deduplicated on a delivery id that survives every retry. Miss all of them and you lose nothing: a release is immutable and addressable by its tag forever, and every attempt is in the log either way.
  3. 03
    It opens the pull request
    A supplied CI job — a GitHub Action, or the equivalent GitLab pipeline — moves the release your control mapping pins, runs the impact check for exactly that move, and renders the result as the request body: which control, whose it is, what changed, and the citation. A substantive change to a mapped duty fails the check, so the bump cannot merge unreviewed.

A notification is not evidence. The signature on a delivery proves the messenger held your secret — not that the law says anything — so the second half of a subscriber's handler pulls the release and verifies it before a byte of it is used.

All three are commands in the open engine, run by whoever publishes a release. There is no feed of ours you can point a subscriber at today, and what these have to announce is a fixture.

Control mappings

From “here is the law” to “here is what we do about it”

An obligation is only useful once somebody has said which control discharges it. OpenRegs specifies that mapping as a file — one entry per obligation, pinned to one release — and ships the commands that read it. The mapping is yours and stays in your repository; the format is part of the open spec, so a mapping can be validated, reviewed and diffed like any other file, and shared if you want to share it.

  • One entry says one of exactly two things: a control covers this duty, or it does not apply here and here is the reason. An entry that means anything else is rejected.
  • openregs coverage reports every duty that binds your entity profile on a date as mapped, waived or unmapped — and applicability comes from the release, so a duty an in-force derogation disapplies is reported as such, with the derogating provision cited.
  • Mapped plus waived plus unmapped equals applicable, by construction. A gap cannot be rounded away, and every gap is listed individually with its citation.
  • The report is JSON and one self-contained HTML file — no stylesheet, script or font fetched — stamped with the release tag, the commit, the as-of date and when it was generated.
  • openregs impact intersects a release move with the same file and exits non-zero when a duty one of your controls discharges has changed substantively.
The coverage reference

openregs coverage --entity-profile operator --as-of 2025-06-01

3 applicable: 1 mapped, 1 waived, 1 unmapped

fixreg@2025.04 · Fixture Bank plc

  • FIXREG-Art5.3-Ob1mappedCTRL-INC-014
  • FIXREG-Art5.2-Ob1waivednot applicable, with rationale
  • FIXREG-Art5a-Ob1unmappeddesignate a compliance contact

Real output, over the fixture regime — twelve synthetic articles about nothing, and the consuming repository the test suite runs this against. It is what the report looks like, not what your obligations are.

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.

Which law, and when

One regime is loaded, and it is a fixture

Everything above describes machinery that exists and runs. This is the corpus it runs over, stated so that no reader has to guess. Evaluating OpenRegs today means evaluating the machinery, not the content.

FIXREG — the fixture regimeIn the corpus
Fixture Regulation (EU) 2024/1: twelve synthetic articles, an amending act that moves a reporting threshold, and one deliberate coverage gap. It is the corpus the test suite asserts against, and it is about nothing. It stays in the engine repository permanently.
MiFID II, DORA, the AML directives, Basel as the CRR enacts itNamed, not started
The acts OpenRegs is being built to carry first, because that is where change is fastest and the cost of missing one is highest. Not one of them has been captured, parsed, reviewed or published. There is no date, and nothing on this site should be read as saying otherwise.
The UK, and the US CFRPlanned
legislation.gov.uk and the eCFR are two of the four publishers the ingestion adapters already target, each with its own mapper and golden fixtures. Targeting a publisher is not the same as holding a corpus: no UK or US instrument has been reviewed into one.
Regulation outside financial servicesSame engine
Financial regulation is the entry point, not the boundary. A regime is texts, obligations and a cross-reference graph; the adapters read EUR-Lex, legislation.gov.uk, the eCFR and gazette PDFs, which publish all law rather than one sector, and no term in the schemas or the entity taxonomy names an industry.
Shared mappings to common control frameworksNot published
The mapping format is part of the open spec and the tooling reads any file written in it, so mappings can be maintained and published in the open the way the corpus is. None has been. Today a mapping is one firm's file, in one firm's repository.

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.

Browse the core repositoryJoin the Cloud waitlist

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