What the record is for

A final-year project is finished, submitted, and then a year later somebody claims it as theirs. A supervisor confirms a project on paper, and the paper is lost. An institution has no durable record of what its students produced, when, and in what state.

The tool in this space is a permanent ledger: a hash of the work, a timestamp, and an address. The record says this content existed at this time, and it has not been altered since. That is genuinely useful, and it is genuinely less than people assume.

The three claims, and which ones are false

When someone says a blockchain proves authorship, it is worth separating three different claims, because the ledger supports one of them and does not support the other two.

"This content existed at this time." This one is true, and it is what the system actually provides. A hash of the document is written down at a point in time. Anyone can check the hash against the document later, and the ledger says whether it matches. The document was registered before whatever the dispute is about.

"This content is mine." This one is not supported by the ledger. Registering a hash proves you had the document at that time. It does not prove you wrote it - you may have registered somebody else's work, or a document you copied. The ledger records a timestamp, and a timestamp is evidence about time, not about authorship.

"This content is legally mine." Also not supported. A ledger is not a registry, and a record in one does not transfer ownership of intellectual property in any jurisdiction. The legal position is unchanged by the existence of a hash on a chain.

The failure mode is universal: a system that proves B is marketed as proving A and C, and the gap between the marketing and the mechanism is where the disappointment lives.

Designing the interface around the truth

This is where most of the work went, and it is an interface problem, not a cryptography problem.

The claim text is precise. Not "this work is yours" but "this document was registered on this date, and the record has not changed since". The wording is not hedging; it is the actual guarantee, and it is specific enough to be useful.

The author is an assertion, not a finding. The registration says who submitted it. The interface presents that as the person who registered this, which is a fact about the transaction rather than a conclusion about authorship.

The document is shown, with its hash, and the verification is public. Anyone can run the check. A proof that only the registrant can see is a claim; a proof anyone can re-run is a fact.

The chain of custody is visible. If a document is registered, then updated, then updated again, the history shows the sequence. Each version has its own hash and its own moment. This is the part that makes the record useful in a dispute: not a verdict, but a timeline.

Ownership is stated as a legal matter, separately. If the system wants to say something about rights, it says it in a way that is honest about being a claim in a jurisdiction, with the date and the parties - not as a property of a hash.

What a hash chain actually adds

There is a real, non-trivial thing here, and it is worth being precise about it.

When each version of a document contains the hash of the previous version, the sequence is linked. To change version three, you have to change versions four onwards too, because each one commits to the previous. A published history cannot be quietly rewritten without breaking the chain in a way that is visible to anyone checking.

What that gives you:

• Tamper-evidence. Not tamper-proofing - the chain could be rewritten from the first entry, at enormous cost, and on a small chain that cost may not be prohibitive. But the rewrite is detectable, and the detection is available to anybody, not only to the party who benefits from the change.
• A third party's timestamp. The network's record of the order in which entries arrived is harder for one participant to fake than a timestamp written by the party with the most to gain.
• Durability. The record does not depend on one company's willingness to keep a database.

What that does not give you is a judgement about who is right. The ledger tells you what happened and when. It does not know what happened - that is still the job of people, and of evidence.

The parts that are easy to get wrong

A timestamp with no anchor is a claim. A record that only exists in the registering party's database proves nothing to anyone else. The whole value comes from the entry being somewhere the registrant does not control.

Wording is the feature. The difference between a product that is precise and one that overclaims is a few sentences in the interface, and it is the difference between a tool people trust with a real dispute and one they avoid.

Privacy has to be designed, not defaulted. Registering a document's hash should not publish its contents, its author's details, or the institution's internal review. Public timestamp, private content, and an access model that says who can see what.

The record is not a grade. It cannot say the work is good, that it passed, or that it is finished. Institutions that want that have to record that separately - which is fine, and is usually where the interesting work is.

The rule I would keep

Be precise about what you can prove, and say it in the interface, not just in the documentation.

A provenance system that says "this proves authorship" will be found out, and the moment it is found out the whole product is worth nothing. The same system that says "this proves the document existed on this date and has not changed since" is doing something smaller, something that is actually true, and something that is genuinely useful.

The system described in Provenance is built on that rule: the interface says what the record proves, and the interface is designed so that what it says is exactly what the mechanism supports.