The machinery runs. The service is not open.
OpenRegs Cloud is hosted, verified serving — the engine's API over public regime releases, with the accounts, keys, metering and billing that make it something you buy rather than something you operate. The control plane exists, runs against a pinned engine, and is deployed at cloud.openregs.io — which answers 401 to everyone, because there is no way to obtain a key. Nothing but a fixture to serve, and no price. This page is about which is which.
What you can use today, without us
The engine, the schemas, the pipeline and the fixture corpus are open source and usable now. Cloud will not gate them: anything required to self-host stays open, so the hosted product is a way to avoid operating the pipeline and never a way to get access to it. See what is open, or read the documentation.
What runs
Five things are true of the hosted product as it stands. None of them is a service you can reach.
A control plane, in front of a pinned engine
openregs/cloud is a private repository holding the commercial half: API keys, per-key metering, plan limits rendered into the engine's own policy file, and the check that refuses to route traffic to an instance serving under anything but a verified release. It is the second closed repository in the project, after this website.
The data plane is the open engine, and cannot quietly stop being it
The engine is built from the public repository at a pinned commit and consumed as an artifact. There is no fork and no vendored copy — and that is a check rather than a promise. The build fails on a committed engine directory, on an import of the engine package, on a source file carrying its Apache-2.0 header, and on the pin and the deployment disagreeing about which commit is running.
Nothing is answered from a release that was not verified first
The engine verifies a release before it offers a transport at all, and answers 503 on every route until it has. In front of it, the control plane asks a running instance what its answers are actually stamped with, and routes to it only while that answer is “verified” — checked against a live response rather than against the configuration that was meant to produce one.
Both halves of that have been run, not argued
A local stack answers an authenticated query with citations into the corpus, stamped “verified”. Handed a deliberately corrupted copy of the same release — the reporting threshold in one article overwritten with a figure nine times larger, the same number of bytes, so the database still opens and still answers — the data plane refuses to start and the control plane returns 503 “posture_unverified”. Not a stale answer, not a degraded one, and not the corrupt one. Both are scripts, so they are run rather than remembered.
The engine will not be on the internet, even when the product is
Only the control plane is ever published. The data plane declares no public service at all, and where it runs it has no public address of any kind — it is reachable across a private network and nowhere else, so a request that has not been through authentication and metering cannot reach the thing that answers it. That is a property of how the two are configured rather than a rule somebody has to remember.
What does not exist
The longer list, on purpose. An open-core product is an argument about trust before it is an argument about anything else, and the claims that would not survive checking belong here with a reason.
Anything you can sign up for
No endpoint has been published, nothing is open for signup, and there is no console, no trial and no key we could issue you. The waitlist below is a waitlist — not a queue for something already running.
A real body of law
One regime exists and it is a fixture: FIXREG, synthetic throughout, twelve articles about nothing, built so the test suite can assert against a corpus whose every digest is known. EU, UK and US CFR corpora are planned and none has been published. Evaluating OpenRegs today means evaluating machinery, not content.
A published artifact you could check for yourself
No release has been tagged or published anywhere. The signing pipeline is implemented and merged, and it has not signed a public release, so there is nothing to download, no transparency-log entry to look up, and no verification you can run that does not start with a clone.
Keyless verification anybody could rely on
The verifier walks a Sigstore bundle offline — certificate chain, identity, log inclusion — against public Sigstore's own roots, which the engine now ships and which are checked in its tests against a real signature Sigstore published. Those roots were fetched from Sigstore's root and reviewed by a person, because a root fetched at verification time would be a root an attacker could supply. What has not happened is a keyless release: the one tag that exists is keyed, so the pipeline has never exercised the path.
A signature that vouches for anything, even on the fixture
The one release that does verify end to end is signed with a key derived from a published seed, and the trust roster marks it as a fixture with the note that such a key vouches for nothing: anybody can sign with it. It exists so a fresh checkout can run the whole chain offline, forever, without asking anyone for anything — not so that it can be relied on.
A price, or anything that could take a payment
No pricing has been decided. The right numbers depend on measured cost per answer at a real corpus size, and the corpus is twelve fixture articles. There is exactly one plan in the code and it sits at the engine's own open default rate limit, so that the free tier is visibly the engine's default rather than a product decision nobody made.
There is also a status page. It reports nothing yet, and says so rather than showing a tick for a service nobody is watching.
What the first release covers
In
- Hosted verified serving of public regime releases, over REST and MCP
- Accounts, organisations, membership; API keys with rotation and revocation
- Per-key metering and usage-based billing
- A console, and a public status page
- One region
Out, deliberately
- Private regimes. Internal policy and non-public guidance through the same pipeline is the strongest enterprise hook and the one that needs tenancy isolation designed before it is built, not during.
- Signed attestation and audit-log export. It is a different promise from the stamp on a response: a receipt a third party can re-check for themselves. Selling it before it exists is the fastest way to lose the account that asks for it.
- A freshness SLA. There is nothing to measure. A promise about how fast a change at the regulator reaches a release you can query needs a real corpus published on a real cadence; before that, a number would be a guess.
- SSO and SCIM. The seam is left where they will go. Building them for a product with no customers would be building against an imagined one.
- Multi-region, and high availability beyond one region. One region, and the honest availability story that goes with it.
What “verified” will mean
Every answer carries two stamps the engine adds in one place: what was checked before that release was served, and the non-advice disclaimer beside the release tag it applies to. verified is the strongest of three values, and it means five checks — signature, trust, digests, provenance and log inclusion — passed over that release before the server answered anything at all. The other two are digests, an unsigned local build, and skipped, verification waived.
Three things it does not mean, which sales copy must not imply:
It describes the release, not your response
The stamp is a startup-time fact about the release being served, repeated on every answer — not a re-verification per request. It is also not a receipt: you cannot take a response body and prove to a third party that we served it. That capability is real, and it is explicitly outside the first release.
It is not a claim that the law is correctly represented
What provenance guarantees is narrower and checkable: that quoted text equals its span in the source, byte for byte, and that the source traces to a published document with a digest and a retrieval instant. Whether a provision was read correctly is a reviewer's judgement, and the non-advice disclaimer says so on every answer.
It says nothing about freshness
Verified means these bytes are the bytes the canon published. It does not mean the regulator has not moved since.
Where the line falls, and how you can tell
“Anything required to self-host stays open source” is a slogan until it has a test, so here is the test. Take a feature away from the hosted product and hand a competent operator the public artifacts — the open image, a public release, the documentation. If without it they cannot obtain the same answer with the same provenance stamp, the feature belongs in the open engine. If what they lose is only somebody operating it for them — an account, a key, a bill, a dashboard, a person on call — it belongs in the commercial repository.
The first real test case went against the commercial side
MCP is stdio-only in the engine today, and the engine's own source says the SDK's HTTP transports are a deployment decision rather than a capability it owes — which reads as an invitation to build the network-reachable endpoint in the hosted product, where it would be faster. The test above says no: a reachable MCP endpoint is a capability, not an operation, and building it privately would make it hosted-only, which is exactly what the commitment forbids. It lands in the engine; the hosted product puts authentication, quota and metering in front of it.
Why the repositories are split the way they are · The two commitments
Tell us you want this
Leave an address and we will get in touch when OpenRegs Cloud opens. No newsletter, no drip campaign.
Heads up: no list and no mailing system are connected yet, so this form will refuse rather than store anything. It is wired and waiting on its configuration. What we keep.