The record that remembers where every fact came from.
1349 observations, each carrying its source, 943 carrying evidence text, over 4 append only tables with 0 broken chain rows at build time.
Weight attaches to evidence, never to the source.
Every fact carries where it came from, and the record is never editable, so a correction is a new observation rather than a rewrite of the old one. An unknown source resolves downward, to manual rather than to requested, because guessing generously is exactly how an uploaded list launders itself into looking like demand.
Most rows arrived in the migration from the old store and say so: a row that came from an import is stamped import, not upgraded into something that looks like a customer told us.
578 of 1349 observations were captured in the moment. The rest are bulk loaded and labelled that way. Refusing to relabel them is the whole point of this section, and it is also the reason this number is small.
sources in the live store: import 719, form 448, call 94, backfill 52, manual 36
A hash chain, deliberately not a blockchain.
Append only by convention is not append only. The operator holds write access to the file, so no row can be shown to be un backdated on its own. Each event carries the hash of the row before it, so an edit, a deletion or a reorder breaks the chain and names the row that broke it. A logged erasure records what was removed by id and hash, so an expected break stays distinguishable from tampering.
Why not a chain proper
Distributed consensus resolves disagreement between parties who do not trust each other. There is one writer per tenant and one operator, so you would pay the whole cost of consensus for none of its purpose. Immutability also collides with erasure rights over exactly the data class that attracts deletion requests.
That is tamper evident. It is not tamper proof, and it will not be until the head digest is anchored outside this machine. An RFC 3161 anchor is designed and not built: no signed token is issued today, and nothing is written beside a nightly snapshot. When it exists, only the head digest will leave the machine, never content.
chains verified at build time | consent_events 293, field_observations 1354, action_log 21531, erasures 21 | reproduce with ledgerctl.py verify
Two stores, and a gate that stays red until there is one.
The ledger is replacing an older customer store, and the replacement is not finished. That store took 67 writes in the last seven days. The gate covering this wants seven consecutive days of zero writes to it, and it will keep failing until the dual write stops, which is a decision rather than a cleanup: the dual write is what keeps the two in agreement while the migration settles.
We publish the failing gate rather than the intention. A page that describes one store while two are live is the specific drift this whole system exists to prevent.
writes to the old store in 7 days: 67 | measured 2026-09-02
The site is generated from the store, and refuses to publish a claim it cannot support.
Every count on this website is read from the live database at build time. Every capability carries a state that is compared against a measurement, and a page that declares a capability is live while the store measures otherwise fails the build rather than being published. A page containing none of the governed claims also fails, because a checker that goes quiet because it found nothing to check is indistinguishable from one that works.