Four repositories, and where the line is drawn

OpenRegs started as one repository holding everything: the spec, the engine, the fixtures, the docs and the deploy scaffolding. It is now an organisation, and the pieces that were always separate concerns are separate repositories with their own licences, their own visibility and their own CI.

Two of those are closed, and saying so plainly is the point of this post. A marketing site and, later, a hosted product’s control plane are commercial things. Everything the project asks you to trust — the engine, the spec, the corpus, the verification — is in the first repository, in the open, and that is not a coincidence about how the work happened to be organised. It is the line.

The two commitments

These are the commitments the split was designed around. They are written down because “we would never do that” is not a commitment, and because an open-core project that has not said where the line is has not really drawn one.

Public-law corpus data is always open, under CC BY 4.0. The commercial line is drawn at operations, not data.

Anything required to self-host stays open source. The commercial repository contains only the control plane around the open-source data plane — never a fork of it.

What the first one rules out: a tier where the law is the product. There is no version of OpenRegs where a regulation, an atom, a graph edge or a consolidated text sits behind a payment. The corpus licence is recorded in each release’s own metadata, so it travels with the artefact rather than living on a page we control. What is sold is running the thing — hosting it, keeping it fresh, holding private regimes for people who have them, attesting to what was served and when.

What the second one rules out: the failure mode where the open engine slowly becomes a demo. If a capability is needed to stand the system up yourself, it belongs in the engine, and the hosted product consumes the same released artefacts as everybody else rather than a better internal build. There is no private fork to drift away from.

Neither commitment is generous. Both are the terms on which a compliance tool can reasonably be believed: the argument for OpenRegs is that you can check its answers, and you cannot check what you cannot obtain.

What is true today

Everything in this section was verified while writing it, not recalled.

Four repositories are live, with the licences and visibility in the table above.

The engine’s CI is green on main — seven jobs: lint, typecheck, tests, canon checks, conformance, end-to-end and the benchmark. main is protected, including against administrators: five checks are required to merge, force pushes and branch deletion are refused, and a separate rule makes release tags immutable once pushed.

docs.openregs.io is live, 56 pages. One of them is generated per CLI command — 27 commands, plus an index — rendered from the parser the CLI itself uses, so a flag that changes in the code changes on the documentation site or the build fails. The documentation content lives in the engine repository and is pulled in at build time against a pinned commit; the docs repository never forks it.

Signing is keyless. There is no long-lived signing key anywhere — not on a laptop, not in a secret store. A release job mints a short-lived OIDC token from GitHub, Fulcio issues a certificate for ten minutes naming the workflow that asked, the signature is recorded in the public Rekor transparency log, and the certificate expires. The identity that vouches for a release is the workflow itself, which is a thing you can read, rather than a key, which is a thing somebody has to keep.

What is not true yet

This is the more useful list.

The cloud product does not exist. Not in beta, not in private preview — there is no service, no console, no API host. The Cloud page describes what is intended and takes an address if you want to hear when that changes. Pricing is a placeholder for the same reason.

No real body of law has been published. The engine ships one regime, fixreg, and it is a fixture: Fixture Regulation (EU) 2024/1 and a handful of acts around it, synthetic throughout, deliberately about nothing. It exists so the test suite can assert on a corpus whose every digest is known, and it is about as much use for compliance as a chess problem is for a war. EU, UK and US CFR corpora are planned and none has been published. If you are evaluating OpenRegs today, you are evaluating machinery, not content.

The signing pipeline has not signed a public release yet. It is implemented and merged; no release tag has been pushed through it, so there are no published artefacts and no Rekor entries to point at. Described above as how it works, which is true, and not as something you can go and check, which is not yet.

Offline verification is partial. openregs verify rebuilds a release and checks its digests, its manifest and its log inclusion proofs without a network, and that works today for the fixture regime. What it cannot do yet is walk a Fulcio certificate chain — so for a keyless release it cannot bind the signing key to the workflow identity by itself. It refuses rather than passing quietly, and prints the cosign command that does answer the question. Closing that gap is in flight.

Why bother saying all this

Because the alternative costs more than it saves. Every claim above is one a reader could check, and the ones that would not survive checking are in the second list with a reason. An open-core announcement is an argument about trust before it is an argument about anything else, and a project that overstates its position on the day it asks to be trusted has answered the only question that mattered.

The engine, the spec and the fixtures are at github.com/openregs. How the licences divide is covered on the Open source page, and what you may do with the name is on the trademark page.