What a receipt check actually returns

Why this page is a schema and not a screenshot

The natural thing to publish here would be a real receipt from a real run. We are not doing that, because it would mean publishing a customer’s records, and that is their decision rather than ours.

The other option would be to mock one up and present it as real. On a page arguing that vendors overstate their evidence, fabricating evidence would be an unusually direct way to prove the point against ourselves.

So what is published instead is the part that is actually checkable: the shape of what the verifier returns, field by field, as it exists in the code. A screenshot proves nothing anyway — it is an image a vendor made. A schema you can hold us to is worth more.

Verdict one: intact

Carries the number of anchors checked and the number of rows they cover. It means every anchor recomputed to its stored hash.

What it proves: the ledger has not changed since it was sealed.

What it does not prove, and this is the part usually left out: it says nothing about whether the entries were true when they were written. A confidently wrong record, sealed, verifies as intact forever. It also says nothing against anyone who can rewrite the seals, because our chain head has never left our own infrastructure — so the check is comparing the ledger against a reference that lives beside it.

Verdict two: altered

Carries the first anchor that failed, the hash expected, the hash actually computed, and — when the row count came back short — how many rows are missing.

It names the FIRST failure specifically, because everything after it is downstream: one changed row invalidates every hash that covers it, so a list of every broken anchor would be a list of one problem repeated. The first one is where to look.

The separate missing-rows field exists because deletion and modification are different incidents with different explanations, and a verdict that lumped them together would send you looking for the wrong thing.

Verdict three: unanchored

Carries nothing, because there is nothing to report. Nothing has been sealed yet, so there is nothing to check.

This state exists on purpose and it is the reason the verdict is not a boolean. A system with only pass and fail has to file "I have not checked" under one of them, and it will not file it under fail — so the absence of evidence quietly becomes evidence of absence. Naming the third state is the only way a caller can tell "nothing has changed" apart from "I would not know".

The same three-valued discipline applies to re-verification, and there the unknown state is common rather than rare: most integrations offer no way to read a record back by its id, so the honest answer for those is that we cannot check, not that the record is good.

The precedence that decides whether a receipt points anywhere

A receipt is only as useful as the destination identifier it carries, and providers return that under whatever name they like. The capture layer looks for a link first, in this order: permalink, permalink_url, url, htmlLink, html_link. Anything that parses as an http address wins, because a link is the strongest form — the reader opens it and sees the artifact themselves.

Failing a link, it looks for a timestamp, and records delivery against the channel it was sent to. Failing that, it takes a message id.

And if none of those are present, it returns nothing. Not a guess, not a placeholder: the receipt is written without a pointer.

That last branch is the honest limit of this whole mechanism, and it is worth being blunt about. A provider that returns its identifier under a name not on that list produces a row that is true and useless — it records that something happened with no way to open it. Every name on the list was added by someone noticing a provider we had missed. There will be more.

Where approval is recorded

A receipt that records what happened but not who allowed it answers half the question. The approval is stored with the channel it came through, and the channel is a closed set: the app, Slack, or Telegram.

Keeping the channel rather than just the person matters for a reason that only shows up in a dispute. "Approved by a person" and "approved by a person in a Slack thread that three colleagues could see" are different evidential positions, and the second one is checkable by someone other than us.