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.

Update, later the same day: there are five. openregs/cloud was created a few hours after this went up — private and proprietary, holding the control plane for the hosted product and no copy of the engine. Which side of the line it sits on, and what does and does not run in it, is on the Cloud page.

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.

Update, the next day: an API host exists. cloud.openregs.io is deployed and answers /v1/status; every other route wants an API key and returns 401 without one. Nobody can obtain a key — there is no signup and no billing — so "you cannot use it" is still true while "there is no host" is not. It serves the fixture regime, which is about nothing.

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.

Update, the next day: fixreg@2025.04 was tagged. Build, sign and package went green on real runners and every artefact digest matched the committed release byte for byte. The conclusion above survives for a different reason than it was written for: that tag is keyed, signed with the published fixture key that vouches for nothing, so it minted no Fulcio certificate and no Rekor entry. The keyless path is now configured and tested against a real public Sigstore signature — it has still never run in this pipeline.

Update, 2026-08-05: half of the paragraph above is now wrong, and it is the half that understates. fixreg@2025.04 has its assets attached — 21 files, fetchable and verifiable by anybody with no account:

openregs pull fixreg@2025.04 --from https://github.com/openregs/openregs --into ./vendor

That passes signature, trust, digest, provenance and log-inclusion checks over the fetched bytes. So there are published artefacts now. There are still no Rekor entries, for the reason in the update above: the tag is keyed. And the release is fixreg, which is the fixture — the sentence about no real body of law having been published is unchanged and is the one that matters.

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.

Update, an hour after this went up: the chain walk landed. openregs verify now validates the certificate path to a Fulcio root, checks the identity and issuer against the trust roster, and verifies the Rekor signature and its inclusion proof — all offline. The conclusion above is unchanged, because the gap moved rather than closed: the roster the engine ships with names no root for public Sigstore, so a keyless release is still refused rather than verified. What is owed now is two PEM blocks a person has to fetch from Sigstore's own root and read. The verifier is deliberately forbidden to fetch them for itself, and the reason is the right one — a root fetched at verification time would be a root an attacker could supply.

Update, the next day: the two PEM blocks are in. Public Sigstore's root and intermediate, and Rekor's log key, were fetched from Sigstore's own root, checked against fingerprints published by Sigstore, and reviewed before being merged — merging them is what trusting them consists of. The engine's tests now walk a real signature Sigstore itself published, not a synthetic one. So the gap is closed and the sentence above is wrong from this date. What is still true: no keyless release exists, because the only tag this project has cut is keyed. The path is verified; the pipeline has not run it.

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.