A chain answers only for what arrived
Take a plain audit log. Each entry has a sequence number, a payload, and the hash of the previous entry. Entry one has no predecessor. Entry two embeds the hash of entry one, entry three embeds the hash of entry two, and the rest repeat the pattern.
A verifier holding entries one through seven can recompute every hash edge. If entry four changed, entry five no longer points at it. If entry three vanished while four through seven remain, the numbering is wrong and the hash edge into entry four has nothing valid to land on. Interior deletion is loud. That is the easy case, and it is the case every design review talks about.
So the verifier can answer one question with real force: was anything in the material received altered after the chain was built? For entries one through seven that answer is local. No trust in the publisher is required. The bytes either connect or they don't.
A different question looks similar and isn't: is entry seven the latest entry?
The chain has no way to answer. Entry seven has no successor in the verifier's hand, so there is no entry eight whose predecessor hash commits to it, and there is also no visible slot where entry eight should have appeared. The set of records is exactly the set that arrived. A valid chain ending at seven, and a longer valid chain ending at eight with the last entry withheld, have the same local shape: a final record with no successor. Tip truncation is silent because nothing after the tip is part of the object being verified.
That asymmetry would be a curiosity if the tip were a random record. It isn't. The record most likely to be suppressed is almost always the newest one, because the suppression decision happens after the payload is known. The publisher reads entry eight, dislikes what it says, and withholds it. Entry eight is the tip by construction. The very condition that creates the temptation is the same condition that removes the successor which would have exposed it.
None of this is a bug in the chain. It binds each published record to the one before it, it makes edits to earlier material visible once later material exists, and it hands the verifier a clean answer about the prefix in hand. What it has no internal way to do is distinguish "this is the end" from "this is where delivery stopped."
The shape is bigger than logs
This usually gets filed under logging, but the mechanism shows up wherever the publisher of a record is also the party the record judges.
An evaluation run publishes results after each sweep. One sweep improves the score, the next improves it again, a later one gets worse. If publication stops there, the visible sequence still has no broken hash edge and no contradiction inside the artifact. The bad sweep was the newest record at the moment the publish decision was made.
A scanner report attached to a release has the same shape. If the release artifact carries a signed report, the signature proves who signed those bytes and what they covered. It proves nothing about a later scan with worse findings that was quietly left out, and the last scan before the ship decision is exactly the one worth leaving out, because it is the only one that could still change the decision.
Incident timelines behave the same way. Each event can link to prior evidence and the whole thing can stop precisely where the story becomes less flattering. Earlier edits leave scars. A missing final segment leaves none, since the end of the record is just the end of the record.
Voluntary benchmark submissions make it obvious. A submission can be signed, reproducible inside a stated harness, and bound to a commit, and still say nothing about the abandoned runs that scored worse. Publication bias is a tip-truncation attack with a respectable name and a large literature behind it. The phrase sounds gentler because it usually gets discussed as a statistical artifact, but structurally it is the same property: whoever sees the result before publication holds the write path.
No moral claim is needed here. If the artifact is produced after the result is known, and publication is still optional at that moment, then integrity over published records has its missing edge exactly where the pressure concentrates.
Two repairs fail mechanically
The first common repair is to publish to two independent places. That does help with one failure. It detects divergence: if record seven says one thing in one location and something else in the other, at least one copy is false or the feed split. Mirroring hardens records that exist somewhere and can be compared.
It says nothing about a record absent from both. If the same party feeds both publication points, absence from both costs the publisher exactly what absence from one costs. Entry eight goes nowhere, and a verifier comparing the two locations later sees perfect agreement. Both end at seven. Both verify. The mirrors have strengthened a shared prefix without producing any evidence that a withheld suffix ever existed.
Independence of storage is not independence of the write decision. The two get blurred because two publication points feel like two witnesses. Against divergence they are witnesses. Against nonpublication they are two inboxes fed from one source.
The second common repair is to add more cryptography: more hashes, stronger keys, a signed transcript over the whole sequence. All of that binds content to content and content to a key. A verifier can then say, with the usual caveats about key control, that a specific signer approved those exact bytes. What it can't say is that other bytes should already have been produced.
Every claim of the form "entry eight should be here by now" comes from outside the artifact. It comes from a schedule, a protocol rule, a release gate, some expectation about when the next record ought to exist. A seven-entry chain cannot derive that expectation for itself. It contains predecessor links and payloads, and nothing about an obligation it never took on.
A signature over silence is still silence.
Deadlines create defaults and move the problem
The repair that actually changes the shape is to establish time before content. The current record commits, in advance, that the next record exists by a stated point, and that commitment sits inside the current record, signed alongside the payload and the predecessor hash.
Entry seven can now say: entry eight exists by deadline D. A verifier holding entry seven doesn't need entry eight to know the obligation exists. When the deadline passes and entry eight is absent, the silence has become an event, visible to one verifier holding nothing but the artifact already in hand. No second service, no cooperating archive, no coordination among readers. The trigger was planted before the content of entry eight was known.
The cost is the useful part. The deadline has to be chosen before anyone knows what entry eight will say. If it can be restated afterward, the scheme collapses back into optional publication. A deadline that lives in an unsigned side channel gives the verifier a claim about a schedule rather than a committed one, and if entry seven says nothing about when entry eight is due, then entry seven can never accuse anyone of withholding it. The forward commitment is what converts the last record from "latest known" into "latest known, with a pending obligation." That obligation does the job the missing successor would have done.
Then there's the harder half, which is independence. A witness you can compel is not a witness in the sense that matters. When the publisher picks the notary, signs the request, pays the invoice, and controls the channel, the attestation can still be useful: it proves a request was made and a response came back, and it binds bytes to an external receipt. It does not establish the property you actually want from an outside party, which is that the outside record would have existed in the same form without being steered into existence. From outside, "another party attested it" and "another party attested it because the publisher asked" look identical.
What carries more weight is accidental ordering against records written for unrelated reasons. Consider a code change under review. A third-party review record gets produced for the reviewer's own purposes, naming findings and binding them to a commit hash. The change record binds itself to that same hash. Both records pick up ordering metadata from a platform whose clock neither side controls. The ordering claim is then checkable by anyone holding the artifacts: the commit existed before the finding, the finding existed before the later claim, and the hashes named on each side match.
What you gain there is authorship and ordering. What you don't gain is consent. The reviewer did not join anyone's audit design by writing a useful record, and soliciting cooperation would destroy the property that made the record worth citing, because at that point the outside event stops being unrelated and becomes another channel the publisher chose to open. That is an awkward result for clean design. The strongest independent bounds tend to come from records that were already going to be written anyway, on schedules and incentives nobody in the scheme controls.
The forward deadline only fixes the local invisibility of tip truncation. It turns a missing successor into a default against a promise that was already signed. But that default is public only to a verifier who was watching the promise mature.
A deadline with no subscribers is not an event. It is a note in a file nobody opens.
So the schedule pushes the problem into distribution, and distribution has the same shape all over again. The party who publishes the deadline is the party who decides who hears about it.
Top comments (0)