Retrieval-augmented generation solved a real problem: language models answering from memory about things they were never taught. It is now the default architecture for enterprise AI, and it works. But when the subject of the question is a company — is this entity active, who controls it, what did it file — RAG only moves the trust problem down one layer. The answer becomes as reliable as whatever the retriever happened to find. Registry-grounded AI is the stricter standard that regulated workflows are converging on, and the difference between the two comes down to a single question: what does the citation actually resolve to?
Definition
Registry-grounded AI is an approach to grounding in which every fact an AI system states about a company resolves to a named official government register, a specific record or filing within it, and the date it was retrieved. It differs from conventional retrieval-augmented generation in two ways: the class of source it draws on, and the granularity at which attribution is carried. RAG cites the passage it retrieved. Registry-grounded AI cites the register that holds the fact.
The short version
Grounding is the goal; RAG is one method. The two get used interchangeably in vendor material, which is why teams end up comparing architectures rather than comparing what their answers can prove.
RAG’s citation resolves to a passage. That is enough for a policy document or a product manual. It is not enough for a fact about a legal entity, because the passage is a report of the fact rather than the record of it.
Registry grounding is a requirement, not an architecture. You can meet it through an API, a retrieval index, a tool call or an MCP server. What has to be true is that the register, the record identifier and the retrieval date survive all the way to the answer.
What RAG actually fixed
The original insight behind retrieval-augmented generation, introduced by Lewis and colleagues in 2020, was that a model does not need to memorise the world if it can look things up at inference time. Fetch relevant material, place it in the context window, generate from that rather than from weights. It addressed the two most obvious failure modes of raw language models: they invent specifics, and their knowledge stops at a training cut-off.
That is a genuine advance and it is not in dispute here. Almost every serious enterprise AI system now retrieves before it answers.
What RAG did not do — and was never designed to do — is guarantee anything about the material it retrieves. Barnett and colleagues, in a 2024 study of three production deployments, catalogued seven distinct failure points in RAG engineering and made an observation that has aged well: a RAG system can only really be validated in operation. Pre-deployment testing will not surface the failure modes that appear when a corpus grows, when query patterns shift, or when upstream sources go stale. The characteristic production failure is silent. The system returns a fluent answer, raises no error, and nobody discovers the problem for months.
The gap that opens when the subject is a company
For most enterprise retrieval, passage-level citation is proportionate. If an assistant tells an employee what the travel policy says and points at the paragraph, that is a complete and checkable answer. The document is the authority.
Company facts do not work that way. Whether an entity is active, who its directors are, what its registration number is, who holds its shares — these are matters of official record, filed on a date with a specific authority. Any document describing them is a report of the record, one step removed and possibly stale.
So when a retrieval pipeline returns a passage stating that a company is active, it has told you what some text claimed. It has not told you what the register holds. Three things are missing, and each of them is the kind of thing a second-line reviewer asks about:
- Which authority. “Our index” is not an answer. The named register and its identifier for that entity is.
- As of when. Company status changes. A citation without a date describes a moment nobody can pin down, and a stale answer delivered confidently is worse than no answer, because it manufactures assurance.
- Under what right. Most data contracts predate agentic AI and were written for dashboards and reports. Whether they license retrieval, agents or embedded AI use is a question legal tends to ask after the system is built.
What this looks like when it goes wrong
Carillion plc was one of the largest suppliers of construction and facilities-management services to the UK public sector. Ask an ungrounded model about it and you will get a fluent, well-organised, present-tense description of a going concern.
Companies House records the company as being in Liquidation. Winding-up commenced on 15 January 2018. The last accounts on the register cover the period ending 31 December 2016.
The important thing about this failure is how ordinary it is. There is no fabricated statistic, no invented executive, no imaginary subsidiary. Every clause in that description was accurate in 2017. The model is not malfunctioning — it is reporting the world as its training corpus described it, and doing so with no mechanism to notice that eight years have passed.
This is why passage-level citation does not rescue the situation. A retrieval pipeline pointed at a 2017 industry report would return a passage that fully supports the answer. The citation would resolve, the reviewer would be satisfied, and the answer would still be wrong. What was missing was never a source. It was a date.
Attribution granularity: the axis nobody specs
The academic literature on grounding has moved steadily towards finer attribution, precisely because coarse attribution is expensive to verify. Conventional RAG operates at passage-to-response granularity; entailment-based approaches tighten that to the sentence; more recent work on traceable generation pushes towards claim-level grounding, on the reasoning that a reader should not have to read a page to check one statement.
Company data admits one further step, because company data is structured. A fact about an entity is a field, and a field can carry its own source, its own filing reference and its own retrieval timestamp — independently of every other field in the record.
This matters more than it sounds, because freshness is not uniform across a company profile. Legal status may have been confirmed this morning while the financial statements were filed eight months ago. Record-level attribution collapses those into one date and hides the difference. Field-level attribution is the only granularity at which a reviewer can tell whether the specific fact they relied on was current when the decision was made.
What a registry-grounded field carries
The record shown is real and checkable: GLOBAL DATA INTELLIGENCE LIMITED, company number 09410808, incorporated 28 January 2015, status Active, last accounts made up to 31 January 2025. It is our own entity, which is the point — a worked example in an article about verifiability should be one the reader can verify. It takes about thirty seconds at Companies House.
There is a fifth question that gets asked less often and matters more than any of them: can you reconstruct this answer six months from now? An audit does not ask what your system says today. It asks what it said in March, on what basis. That is an archival requirement as much as a retrieval one, and it is the requirement most AI stacks discover late.
A confidence score is not a citation
Systems that assemble company data by combining recorded facts with inferred connections often surface a single numeric confidence alongside the result. It occupies the same visual position a citation would, and reviewers read it the same way. They are not the same thing. A confidence score is a claim the system makes about its own output; a citation points at something outside the system that can be checked independently. Confidence scoring is genuinely useful for ranking and triage. It is not evidence, and a fact arriving with a score but no named register is a modelled estimate presented in the grammar of a verified one.
Company data built to survive the fifth question
Global Database is a registry-native source: company data sourced first-party from 400+ official government registries across 200+ countries, covering 600M+ company profiles — identity, status, directors, shareholders, ownership linkage and filed financials. Data is returned with source attribution and timestamps, so a field can be traced back to the register it came from and the point at which it was retrieved.
When the data doesn’t change but the truth does
The Carillion case is the easy version: something happened, and a system that never re-checked missed it. There is a harder version, and it is the one that should worry anyone running a cached company-data layer.
On 26 March 2025, FinCEN published an interim final rule that redefined “reporting company” under the Corporate Transparency Act to cover only entities formed under the law of a foreign country and registered to do business in the United States. Every entity formed in the US — and every US person — became exempt from beneficial-ownership reporting. The GAO later put the scale of it plainly: the expanded exemption applies to over 99 per cent of entities that previously were required to report.
Now consider what that did to a US beneficial-ownership dataset captured in 2024. Not one field changed. No record was superseded, corrected or withdrawn. The values a system had cached remained exactly what the register said when they were collected.
What changed was the meaning of the absence. Before March 2025, a US entity with no beneficial-ownership record was plausibly non-compliant. After it, the same blank is simply what the regime now produces. An AI grounded on that snapshot will answer questions about US ownership with perfect internal consistency and no idea that the ground beneath it moved.
Why a retrieval timestamp is the only thing that catches this
No amount of retrieval quality detects a change in the law. No confidence score reflects it. The one property that lets a reviewer catch it is knowing the date a value was collected, and being able to ask what the rules were on that date. A field carrying retrieved_at: 2024-11-03 is checkable against a regulatory timeline. A field carrying no date is not.
The objection every engineer raises: latency and cost
Registry grounding implies resolving facts against a source rather than reading them out of an index you already control. The reasonable objection is that this trades a sub-10 ms vector lookup for a network call, on every field, forever. Presented that way it sounds like provenance is something you buy with latency.
It isn’t, because the trade is not all-or-nothing. Company fields differ enormously in how fast they go stale, and the delivery route should follow the volatility rather than the ideology.
A legal name and an incorporation date do not change. Index them, refresh on a slow cycle, serve them locally. Directors and filed financials change on filing cycles — cache with a sensible TTL and refresh on change notification rather than on a timer. What genuinely needs resolving at answer time is the small set of fields where being wrong has consequences: entity status at onboarding, dissolution, ownership at the moment of a decision.
In practice that is a handful of fields per decision, not a lookup per token. The architectural point is that provenance is metadata, not a call pattern: a bulk-indexed field can carry its register, filing reference and retrieval timestamp exactly as a live-resolved one does, provided the pipeline was built to preserve them. Teams that discover the cost problem usually have not made this split — they are resolving everything live because their bulk layer discards attribution on ingest, which is a data-modelling failure rather than a physics one.
The freshness claim needs a number
Whichever route a field takes, the answer to “how current is this?” should be a timestamp, not an adjective. “Real-time”, “continuously updated” and “always fresh” are unfalsifiable. A retrieval timestamp per field is checkable, and it is what lets a reviewer decide whether a cached value was acceptable for the decision that was actually made.
RAG and registry grounding, side by side
| Conventional RAG | Registry-grounded | |
|---|---|---|
| What it is | A retrieval architecture | A requirement on what it resolves to |
| Unit of retrieval | A passage of text | A field on a resolved entity |
| The citation resolves to | The document retrieved | The register, the record, the date |
| Freshness is | A property of the index | A property of each field |
| Entity identity | String matching on names | A registry identifier |
| Typical failure | A plausible answer, wrong source | The field is absent, and says so |
| Audit trail | Depends on index versioning | Travels with the value |
| Best suited to | Policies, manuals, internal docs | Counterparty and supplier facts |
Read across each row. The shaded column is the stricter standard, not the better product — see the limits below.
The row worth dwelling on is the failure mode. A well-built registry-grounded system fails by returning nothing — the field is not published in that jurisdiction, or has not been filed. That is an operationally useful failure: it routes to a human. A retrieval pipeline fails by returning something plausible, which routes nowhere at all.
Where registry grounding does not help
Three limits. Being precise about them is what makes the rest of this usable.
Credit scores, risk ratings, sentiment and firmographic estimates are modelled outputs. No register holds any of them, so none of them can be registry-grounded. They can still be valuable — they need labelling as modelled rather than shelving next to register facts as though they shared their provenance.
The UK’s PSC register is the instructive case precisely because it is among the most open in the world. The data is self-reported and unverified, and ownership is disclosed in bands rather than exact figures.
Registry grounding gives you traceability to the authoritative record. It does not make the record correct, and any vendor implying otherwise is overselling.
The CJEU struck down blanket public access to EU beneficial-ownership registers in November 2022 and member states diverged immediately — some closed access within days, some kept their registers open under national law. Under AMLD6 access is being rebuilt on a legitimate-interest basis, on deadlines several member states have already missed.
“Isn’t this a data vendor inventing a requirement that describes its own product?”
Yes, partly. We sell registry-sourced company data, and an argument that registry sourcing is the right foundation for AI grounding is transparently an argument that suits us. Worth answering directly rather than leaving it to sit there.
Anyone can run the test, against anyone
The ten questions below are not calibrated to our answers. They are what a second-line reviewer asks of any source, and they run against our API as readily as against a competitor’s. A requirement only its author can evaluate is marketing. One a stranger can check in fifteen minutes is a specification.
The specification disqualifies us in four places
Not as a rhetorical concession — as a list, below, with the alternative named.
We are early to naming it, not inventing it
The pressure comes from audit and procurement, and it has a date attached: Annex III obligations under the EU AI Act land on 2 December 2027. Someone was going to write this down. A sound definition should survive being written by an interested party, because every claim in it is checkable.
Where this specification does not favour us
| If the job is | Buy this instead |
|---|---|
| Credit scoring and risk decisioning | A credit bureau. The value sits in the scoring model, not in where the inputs came from. |
| Investigating deliberately opaque structures | An investigations platform. Graph tooling and analyst workflow are a different product from a data layer. |
| Ownership in a jurisdiction that publishes none | Nothing we sell. We return null. An aggregator will return an inference, and sometimes it is right. |
| Sentiment, intent or firmographic estimates | A modelled data provider. No register holds any of it, so none of it can be registry-grounded at all. |
If a standard does not disqualify anyone, it is not a standard. It is a brochure.
How to test whether your system is registry-grounded
Run this against your own stack, or against a vendor during evaluation. It takes about fifteen minutes and it is more informative than a demo.
01–03Can it name the source?
Ask whether a specific company is currently active.
The baseline. Every system answers this one.
Ask which official register that status came from.
Note whether it names a register, or describes its own pipeline.
Ask for the register’s own identifier for the entity.
Not your internal ID. The authority’s.
04–06Can it place the fact in time?
Ask when the value was retrieved, and when it was filed.
Two dates, not one.
Ask the same of a second field, then compare the dates.
If they are identical, attribution is probably record-level, not field-level.
Reconstruct an answer the system gave last month.
An audit asks what you said in March, and on what basis.
07–08Does it admit what it cannot answer?
Check whether a confidence score sits where a source should.
A score is a self-assessment. A citation points outside the system.
Ask what happens where a jurisdiction publishes nothing.
It should return nothing. An estimate presented as fact is the failure.
09–10Can you actually use it?
Read your data licence for AI usage rights.
Confirm in writing that it covers retrieval, agents and customer-facing AI.
Hand the transcript to whoever signs off second-line review.
Ask one question: would you defend this?
If steps two through four produce an answer, you have registry grounding. If they produce a description of the pipeline, you have retrieval — which may well be fine for your risk profile, but it is worth knowing which one you have before an auditor establishes it for you.
One prediction, stated plainly enough to be wrong. By the end of 2027 we expect “name the source register and the retrieval date for each field” to appear as a routine line item in enterprise data RFPs for regulated use cases — not because buyers become more principled, but because procurement writes its questions backwards from audit, and the audit date is now fixed. If that has not happened by then, the argument in this piece was early at best and wrong at worst.
Why this is becoming a procurement question
The EU AI Act’s data-governance, traceability and record-keeping obligations for high-risk systems were rescheduled by the Digital Omnibus, which received final Council approval on 29 June 2026. Stand-alone Annex III systems now face a 2 December 2027 date; AI embedded in regulated products under Annex I moves to 2 August 2028. Article 50 transparency obligations were not postponed and still apply from 2 August 2026. That leaves roughly one procurement cycle to establish where a system’s company data comes from — which is why the question is appearing in RFPs ahead of the deadline rather than after it.
If you are choosing a source rather than auditing one, the evaluation criteria are covered in our buyer’s guide to company data APIs. For how these facts get used in an onboarding workflow specifically, see KYB vs. KYC in 2026. And for the ownership questions that are hardest to ground — because the underlying disclosure varies so widely — our comparison of company financial data sources sets out where the records actually exist.
Get registry-sourced company data your way
However your system consumes it: connect the MCP server so agents can resolve entities as a tool, query the API to resolve facts at answer time, take bulk data to build and index your own retrieval layer, or research entity by entity in the online platform. Registry-sourced coverage across 200+ countries, with identity, status, ownership and financials.