The observation ledger

Our core claim — “this business was first observed on this date” — is only worth something if you don't have to take our word for it. This page is how you don't. Below is the machinery, explained in plain language, and the daily published roots that let anyone check our history against math instead of against our reputation.

A hash is a fingerprint for data: feed any content through the function and you get a short string that changes completely if even one character of the input changes. In our ledger, every observation's fingerprint is computed over two things — the observation itself, and the fingerprint of the observation before it. Think of a notebook where each page ends with a summary of that page plus the previous page's summary, copied forward. Tear out page 40 and rewrite it, and page 41's copied-forward summary no longer matches — nor does 42's, or any page after. To alter one entry you'd have to rewrite every entry that came after it, and as the next section explains, we've already handed out proof of what those entries said.

A Merkle root compresses a whole day of observations into a single fingerprint. Pair up the fingerprints of every observation from the day, fingerprint each pair, pair up the results, and repeat until one string remains — that string is the root, and it depends on every observation beneath it. It works like a wax seal on a sealed box of the day's records: the seal doesn't reveal what's in the box, but once it's published, we can't swap, insert, or remove a single record without the seal breaking. We publish that seal every night, in public, where we can't quietly take it back. If we later claimed a business was “first observed” on a date before its real first observation, the fabricated entry would fail to match the root we published for that day. The math tattles on us.

Nothing in the ledger is ever edited or deleted. When a privacy or legal removal is required, a redaction flag hides the record from public view — but the record, its hash, and its place in the chain stay put, and the redaction itself goes through an audited procedure. This sounds like a technicality until there's a disagreement. A business disputes an observation? The original evidence and timestamps are still there, unmodified, exactly as recorded. Someone accuses us of doctoring history to favor a customer — or the founder's own company? The chain and the published roots make that accusation checkable, in either direction. An editable database settles disputes by trust in the operator. Ours settles them by recomputation.

1. Pick a claim to test — say, an entity page stating “first observed” on a given date.
2. Pull that entity's observations from the public API (see the API docs); each row includes its ledger hash.
3. Recompute each hash yourself — sha256 over the previous row's hash plus the row's canonical content — and confirm the chain links.
4. Recompute the Merkle root for the day in question from the day's observation hashes.
5. Compare your root against the one published in the table below (ideally against an archived copy of this page — the Wayback Machine works). Match: the history is intact. Mismatch: you've caught us, and we'd expect you to publish that.

No permission, account, or cooperation from us is required for any of these steps. That's deliberate. An audit process that needs the auditee's help isn't one.

How observations are collected, scored and error-checked is documented in full on the methodology page.