Who needs a Data Fidelity Register?

Any organisation whose published facts are read, quoted or acted on by people it never meets, and increasingly by machines acting for them. If an assistant, a search engine, a data vendor or a counterparty’s system can get a basic fact about you wrong, a register is what puts the correct version somewhere they can find, read and check it.

In practice that has meant organisations whose public record has drifted from what they actually published, a headcount that lags reality, a legal form that changed and did not propagate, a figure that circulates in a version they never issued. It applies most sharply where the facts carry consequence: a company that has delisted, restructured, been acquired or rebranded, where the outdated version is still the one the machines repeat. But the need is general. Any organisation that publishes facts about itself, financial, legal, operational, or about the standards it meets, has a record worth making legible and verifiable rather than leaving to be inferred.

What does it give them?

One place, on the organisation’s own domain, where its key facts are published as structured data a machine reads directly, each fact bound to the public source it came from and sealed so anyone can confirm it is unchanged. It does not replace the organisation’s filings, its website or its press releases. It sits over them as a layer that is reachable, machine-legible and independently checkable, which none of those three is on its own.

The most visible reason this matters is a chat assistant stating a wrong figure with full confidence, but the same failure runs through any system that reads a fact without a person checking it: a model answering from stale training, a data vendor repeating an old number, a counterparty’s tool pulling the wrong version. The register gives all of them one correct, checkable source to reach for.

Who produces the register?

Apparat does. Building one is a pipeline: a model reads the organisation’s public documents and proposes facts, a separately configured model reviews each against its cited source, and then the candidates are checked by hand before anything is sealed. The organisation supplies the documents and confirms scope; Apparat does the extraction, the verification and the sealing. The detail of that process is under How a register is made below.

Who keeps it up to date?

Apparat carries the updates, on a rhythm that follows the flow of relevant disclosures rather than a fixed schedule. Most of what an organisation publishes does not touch the register: a register tracks the facts within its defined scope, not the whole newsflow. So an update happens when something in scope actually changes, a new results figure, a change of legal form, a new accreditation, and the register is re-sourced and a new sealed release published. A quiet period means no updates because there is nothing in scope to update, not because the register has been left.

What exactly does Apparat do, and is it a paid service?

Apparat builds and operates the register: it turns an organisation’s public documents into sealed, verifiable facts, publishes them on the organisation’s own domain, anchors each release in a public log, and maintains the record as things change. It also delivers the register in a state machines can find and read, the structured data, the discovery files, the crawlability, so that the facts are not just correct but reachable. That is a paid engagement.

What Apparat does not do is vouch for the truth of the sources. It verifies; it does not judge. And the parts that let anyone trust a register, the format and the tool to check it, are open rather than sold: the specification is published under CC BY 4.0 and the reference verifier under the MIT licence. What is commercial is the making and running of a register; what is open is everything needed to trust the result without us.

What does the organisation have to do to put one in place?

On the technical side, one thing: point a subdomain at the register with a single DNS record. The register then lives on the organisation’s own domain. Nothing is deployed into the organisation’s systems, no code, no application, no dependency on Apparat staying online, and the register does not touch the organisation’s existing site. In practice this is a few minutes of work for whoever manages DNS, and it raises no security review, because there is nothing running to review.

Two things on the organisation’s side then make the register effective. A link to it from the main site: this is not optional, because a register that nothing points to may never be found or re-crawled, and a link is what makes it discoverable. And, where the organisation’s DNS provider also filters bot traffic, keeping the register’s subdomain clear of any rule that would block the very agents it exists to serve, the one thing that can quietly stop a correct register from working. Most organisations also add the register to their homepage’s own structured data, closing the loop so a machine sees the organisation and its register vouch for each other.

What does the organisation receive?

A complete register site, served on its own domain: the facts in a form a person can read and a form a machine can parse, the cryptographic proof of each release, and the files that tell machines how to find and read it. It is self-contained and static, the same set of files anyone can verify, with nothing to install and nothing that has to keep running behind it.

What does it cost?

It depends on scope, how many documents, how much of the public record, how much curation the facts require, so there is no list price. A register is a paid engagement with a setup and ongoing maintenance; the honest way to size it is a short conversation about what yours would cover.

What does “verified” actually mean here?

It means one specific thing: that a value in the register is faithful to the public source cited beside it, and has not changed since it was sealed. It does not mean the source is correct. A register proves fidelity to a source, not the truth of the source, and that distinction is the whole design rather than a caveat on it.

The reason to draw the line there is that fidelity is checkable and truth is not. Whether a company’s published revenue figure is accurate is a question for an auditor. Whether the register reports that figure exactly as the company published it, unaltered, is a question anyone can settle with a hash. Apparat answers the second, and answers it in a way that needs no trust in Apparat.

What if the source is wrong?

Then the register carries the wrong value, faithfully, and the seal confirms it was reported exactly as the source stated it. This is intended. Apparat verifies; it does not judge. If a company published an incorrect figure, the register is the place that shows precisely what was published and when, which is more useful than a corrected value with no provenance.

Where a fact is later superseded, by a correction, a restatement, a change of legal form, the register records the new value in a new release, and the earlier one stays in the history rather than being overwritten. What the register removes is the ambiguity about what was said and when, not the disagreement about what is true.

Does a register go out of date?

The facts in it do not, by their nature. A corporate fact is point-in-time: a revenue figure for a given year, a legal form as of a given date, a headcount at a stated moment. It was true then and stays true, and each fact in the register carries the period it applies to, so it is never presented as a claim about now that could quietly lapse. Two figures from different years sit side by side as two dated facts, not as one that has gone stale.

What changes over time is the record, not the facts already in it: when a new figure is published or a fact is superseded, the register gains a new dated entry and a new sealed release. Keeping it current is a matter of adding what is new, not of the existing facts decaying.

How does a fact get into the register?

It passes through a pipeline whose steps narrow at each stage, and the last word is a person’s.

A model reads the organisation’s public documents and proposes candidate facts, each as a value with its period, its unit, the exact passage it came from and the address of that source. A second, separately configured model reviews each candidate against its cited passage. Then the candidates are checked by hand: a fact is admitted only if its source establishes it plainly, and anything whose citation does not support it is rejected rather than smoothed over. Only the facts that survive that review are sealed and published.

What stops it drifting from the truth over time?

Two things: scope and maintenance. Scope, because a register states what it is of, a defined set of the organisation’s own public documents, so a reader knows what it can and cannot answer. Maintenance, because when a fact changes it is re-sourced and republished, and because each fact keeps a stable address, an earlier citation still resolves after the correction. A register is kept, not filed and forgotten.

How is a single fact sealed?

Each fact is reduced to six fields, and a SHA-256 hash is computed over their canonical form. That hash is the seal. Change any one of the six and the seal no longer matches, which is what makes tampering detectable.

The six are chosen deliberately. They are the fields that make a value mean something and let it be traced: what it is, its magnitude, its unit, the period it covers, the exact quoted passage it came from, and the address of the source. Anything a register could change without changing the fact, presentation, ordering, styling, is outside the seal, so a register can be reformatted without breaking a single seal. The seal covers what is asserted, not how it is shown.

How is a whole release sealed, and why not just sign each fact?

The individual seals of a release are combined into a single value using a Merkle tree, and it is that one root value, the release commitment, that is signed and published. A Merkle tree lets a release of hundreds of facts be committed to with one hash, while still allowing any single fact to be proven part of it without revealing or rehashing the rest.

Signing each fact separately would have been simpler and worse. It would produce hundreds of signatures to manage, and it would say nothing about the release as a whole, which release a fact belongs to, whether any were added or removed. The Merkle root commits to the exact set of facts in one value, so a reader can confirm not just that a fact is sealed but that it belongs to this release and this release is complete.

What makes the release tamper-evident after the fact?

The signed release commitment is submitted to a public transparency log, Sigstore’s Rekor, which is an append-only Merkle log: entries can be added but not altered or removed, and anyone can query it. Rekor returns a log index, which the register records in its release file. A verifier can then confirm the commitment is present in a public log that Apparat does not control.

The reason to use a public log rather than a private timestamp is independence. A timestamp Apparat issued would be worth exactly as much as trusting Apparat. An entry in a public, append-only log operated by a third party is something a verifier checks against that third party, so the proof does not route through us at all.

Can I verify a register without trusting Apparat?

Yes, and this is the point of the whole construction. The format is an open specification and the tool that checks a register is open-source, so verification depends on no one, including us. A reader recomputes the six-field seals from the published facts, confirms they combine to the release commitment, checks the signature, and finds the commitment in the public log. If every step agrees, the register is exactly what was published, unchanged.

Nothing in that procedure asks the reader to trust Apparat’s word. The specification is published under CC BY 4.0 with a citable DOI; the reference verifier is published under the MIT licence. A register that Apparat is no longer around to defend still verifies.

Can a register cite independent sources, or only the organisation’s own?

Either. A register is not limited to what its subject publishes. It can draw on public registries, regulators and other independent records as readily as on the organisation’s own documents, and each source is sealed the same way. What a register covers is a scoping decision made at the start, not a property of the format: a register built only from an organisation’s results releases will answer financial questions and stay silent on legal identity, because no results release states a legal form, while one that admits the registry record answers both.

Where a fact is contested, the strongest use of independent sources is to carry both: the organisation’s version and the independent one, same fact, same period, each with its own source, so a reader sees the agreement or the difference rather than being handed a single resolved answer. What the register never does is decide between them; it shows what each source says and lets that stand.

How is this different from a timestamp, a notary, or schema.org markup?

Each of those does one of the three things a register does, and only one. A timestamp or notary proves a document existed at a time and has not changed, but says nothing about the single facts inside it and is not structured for a machine to read. Schema.org markup makes facts machine-readable, but carries no proof and is usually buried in a page. A register does all three at once, on the same facts, in the same place: each fact reachable, structured, and independently checkable.

What about personal data and the right to erasure?

A register is built to hold an organisation’s public disclosures about itself, not personal data, and the extraction is scoped to exclude personal information rather than seal it. The posture is data minimisation: what should not be in a permanent, sealed record is kept out of it at the point of extraction.

On erasure, the honest position is that removing a fact means ceasing to serve it, publishing a release in which it no longer appears, rather than reaching back into an append-only log to un-anchor history, which is neither possible nor desirable. Whether that satisfies a specific legal obligation is a question for counsel and for the particular facts, and Apparat does not claim to settle it in the abstract.

Does a register replace Wikipedia, or an official filing?

No. A register and an encyclopaedia are different objects doing different jobs. An encyclopaedia is a collaborative, edited account of a subject; a register is the dated, verifiable record of what an organisation has itself published. A well-built system uses both, and the register is often the source an encyclopaedia should cite rather than a substitute for it.

Nor does a register replace the official filing it draws from. It makes the fact in that filing reachable, structured and checkable, and points back to the filing as its source. A register is a provenance layer over public disclosures, not a new authority above them.

What is open, and what is proprietary?

The specification and the verifier are open. The format is published under CC BY 4.0 with a DOI, and the reference verifier under the MIT licence, so anyone can read the format and check a register without Apparat. What is not open is the engine that produces a register, the extraction and sealing pipeline. Everything needed to trust a register is public; what Apparat keeps is the means of making one.

What happens to the register if Apparat is no longer around?

It keeps working. A register is static files on the organisation’s own domain, with no service running behind it and no call back to Apparat at any point, so nothing stops if Apparat does. Every release stays verifiable against the public log by anyone, using an open specification and an open-source verifier that do not depend on us. The one thing that would stop is new releases, since maintenance is the part Apparat does, but the record as it stands remains live, readable and checkable indefinitely. The design goal was that trusting a register never means trusting Apparat’s continued existence.

Who is behind Apparat?

Apparat is run by Thomas Meister, from Paris. It comes out of twenty years in corporate communications, and one preoccupation that every communications professional shares: making sure an organisation’s facts and figures stay clean and accurate once they leave its hands and are carried by someone else, a journalist, an analyst, a database. Thomas Meister on LinkedIn.

Machines are the new carrier, and they change the problem. A figure that used to pass through people who could be briefed and corrected now passes through systems that read whatever they can find and repeat it at scale, with no way to tell a current fact from a stale one. Apparat is the response: the same discipline of getting the record straight, rebuilt for the readers that matter now.

None of which you have to take on faith. The register does not depend on Apparat’s size or its continued existence, because it verifies against a public log using an open specification and an open verifier. That was a deliberate choice: the work should stand on its own, whoever is behind it.