Writing
What verification does not prove.
Every provenance tool eventually shows someone a green tick. The interesting question is what that tick is entitled to mean — and the honest answer is narrower than the interface usually suggests.
Here is what a successful verification in Tessera establishes: this file has not changed by a single byte since a particular signature was made over it. That is a strong, useful, mathematically clean statement. It is also the entire statement. Three things people reasonably assume come with it do not, and we report all three on every result rather than letting the tick absorb them.
1 · It does not prove who signed
A signature verifies against a public key. That tells you the holder of the corresponding private key produced it. It does not tell you who that holder is, because nothing in the mathematics binds a key to an identity — that binding is a social and institutional fact, and it has to come from somewhere else.
The somewhere else is a trust list: a maintained register of which keys belong to which organisations, with a process for entry, revocation and dispute. Tessera does not have one yet. So every verification result we return reports the signer as unverified, and says so in words rather than in a tooltip.
This matters more than it sounds. A tool that shows a green tick for signature valid and lets the reader infer from whom is a tool that will eventually put a tick next to a well-made forgery signed by a key nobody checked. The forger does not need to break the cryptography. They need only generate their own key and sign their own fake, which costs nothing. Collapsing “valid” into “authentic” is not a cosmetic simplification; it is the failure mode.
2 · It does not prove when
Our manifests carry a signing time. That time is whatever the signer wrote. A signer can put any date they like into a manifest and it will still verify, because the timestamp is inside the signed data rather than attested by anyone independent.
This is why we mark the signing time as self-asserted on every result. It is a claim by the signer, not evidence of when anything happened.
Fixing it requires a timestamp authority, or an anchor published somewhere neither party controls, so that a record's existence at a point in time can be demonstrated to someone who was not there. We have not published one. Until we do, anything we said about proving when would be a design, not a capability — and describing designs as capabilities is how this category loses its credibility.
It is worth noticing how directly this interacts with the legal position. A defence resting on all reasonable steps is largely a claim about when a control existed. A self-asserted date is the weakest possible evidence for exactly the thing that matters most. We would rather say that plainly than let a customer discover it in front of a regulator.
3 · It does not, by itself, prove nothing was removed
Edits are recorded as a hash-linked chain: each entry references the one before it, so altering or deleting an entry in the middle breaks the link and is detectable.
Cutting entries off the end is a different shape of problem. An append-only structure cannot, on its own, demonstrate that nothing was truncated — the remaining portion is internally consistent whether or not anything followed it. The general answer to that is an external anchor, which is the same missing piece as the timestamp problem above.
In our case truncation is nonetheless caught, because a surviving chain tip has to bind the bytes of the file as it stands now, and a truncated chain generally will not. There is one narrow arrangement where it could, and the implementation is built so that arrangement is never produced in normal operation and is rejected if it is ever encountered. The reason to care: without that handling, an Article 50 AI-generated disclosure could be stripped from a file and the file would still verify clean — which would make the tool actively misleading rather than merely incomplete.
Why publish this
Two reasons, and only one of them is principle.
The principled one: in this category the product is the trustworthiness of the answer. A verification tool that overstates what it establishes has destroyed the only thing it sells, and it usually will not find out until the overstatement is load-bearing in someone else's decision.
The practical one: these gaps are discoverable. Anyone competent evaluating a provenance tool will ask about trust lists and timestamps within the first hour, because they are the obvious questions. Being the vendor who raised them first is a better position than being the vendor who was caught not mentioning them, and it makes the claims we do make easier to believe.
What we will stand behind
Sign a file. Change one byte of it. Verification fails, with a reason naming what went wrong. That works today, it is covered by the test suite, and it does not require you to trust us — the check is an Ed25519 signature over a content hash, which anyone can perform with a standard library and the public key. Everything else on this page is a boundary around that one sentence.