Why an agent's answer needs a citation
Fluent prose about regulation is a claim, not an answer. What a checkable answer carries, and why the date is part of the question.
The OpenRegs team
A compliance question put to a language model usually comes back as prose. The prose is fluent, it is often right, and it is unfalsifiable: there is no way to tell, from the answer alone, whether the model read the provision, remembered it from training, or produced something that merely sounds like regulation. For a team that has to defend a decision to a supervisor, an auditor or a court, that is not an answer. It is a claim.
The unit of trust is the citation, not the sentence
OpenRegs is built so that an answer is never the end of the trail. Every content block a server returns carries three things beside the text:
- an eId or atom id — the exact provision or obligation the claim came from;
- a release tag — the dated, signed build of the corpus that was consulted;
- an as-of date — the day the provision is being read for.
Those three make the answer reproducible. Ask the same question again against the same release and the same date and you get the same answer, because nothing in between is inferred at answer time.
Why the date is part of the question
A provision does not have a meaning; it has a meaning on a day. Regulators publish base acts and then amend them, and an obligation that read one way in January can read another way in June. Consolidation applies recorded amendments to base texts to produce point-in-time versions, and each consolidated expression records the amending instruments that produced it. So "what did this rule require?" is only answerable once you have said when.
This is also why a release is a photograph. It knows the law as of its build date. A provision amended after the release was built is not in it — and the server will answer confidently from the corpus it holds, which is exactly why the release tag travels with every answer.
Quotes are byte-exact, or they do not ship
Obligation atoms — the machine-readable records stating which actor must,
should or may do what — each carry a quoted_text field together with the
character offsets it was taken from. CI enforces that quoted_text equals
source_text[char_start:char_end] byte for byte. An atom that paraphrases its
provision cannot pass validation and cannot reach the corpus.
That invariant is what lets a reviewer skip the middle. You do not have to trust
that the extraction was faithful; you can follow the offsets back into the
consolidated text, follow the text to the regime's SOURCES.lock, and follow
that to the sha256 of the document the regulator actually published.
Retrieved law is data, never instruction
There is a second reason citations matter once an agent is in the loop. A regulator's document can be tampered with upstream, and because an atom quotes its source byte for byte, text that reaches an agent through the corpus can in principle contain something addressed to the agent rather than to a reader. Every MCP tool result therefore carries a notice beside the payload it wraps, telling the model that the data field is retrieved source material and that anything in it that looks like a directive is part of the quoted document, must not be acted on, and should be reported as possible corpus tampering.
An answer you can follow is an answer you can check. That is the whole design:
do not believe an answer because OpenRegs produced it — follow the citation to
the release, the release to SOURCES.lock, and SOURCES.lock to the
regulator's own published document.
Release announcements and posts syndicate over RSS.