Most explanations of document sealing describe the cryptography. This one describes the five minutes, because the cryptography is not the part anybody struggles with.
What you need before you start
The file. That is genuinely all.
Not a finished version, not a registered company, not a lawyer's opinion on whether the work qualifies for protection. Copyright already arose when you created the work. What you are doing here is producing evidence about it, and evidence about a draft is as valid as evidence about a final cut.
One thing worth deciding first: which file. A record proves the exact version you seal. If the piece is still moving, seal the version you would want to point at later, which is usually what went to the client rather than what sat in the working folder.
Step 1. Upload
You upload the file. A cryptographic hash is computed from it, a fixed-length value derived from the bytes themselves.
Two properties matter. The hash identifies that exact version, so change one pixel or one character and it no longer matches. And it works in one direction only: the hash does not let anyone reconstruct the file. That second property is why sealing something confidential is not a disclosure of it.
Step 2. Choose the declaration
This is where the label decision becomes a record. AI generated, AI modified, AI assisted, or human authored, chosen accurately rather than comfortably.
The declaration is bound to the hash rather than stored beside it. That is the difference between a statement about a file and a statement attached to a file. Six months later nobody has to reconcile a spreadsheet of claims against a folder of assets, because each claim already travels with the thing it describes.
Step 3. Seal
A Qualified Trust Service Provider issues a qualified electronic timestamp over the hash and the declaration.
This is the step that moves the date outside your control, and it is the whole reason the process exists. Under eIDAS, a qualified electronic timestamp carries a legal presumption as to the date and time it indicates and the integrity of the data it is bound to. A date in your own system is a date you can be asked to justify. This one is not.
Step 4. The certificate
You get back a certificate recording the hash, the declaration and the timestamp, with a link that resolves to a public verification page.
Keep the certificate with the project files. Keep the original file too, unchanged, because the hash proves that specific bytes existed and it can only be checked against them.
Step 5. Somebody else verifies it
This is the only step that matters and it is the one people skip.
Send the verification link to somebody outside your organisation. They open it, check the file against the record, and see the declaration and the timestamp. No account, no software, no contacting you.
That last part is the point of the whole exercise. Every internal record you already have fails at exactly this step, because it requires the other party to trust the party making the claim. Do this once, with a colleague standing in for a sceptical client, and the difference between a label and a record stops being abstract.
Doing this for a library rather than one file
Sealing one file takes minutes. Sealing four years of back catalogue is a different question, and the honest answer is that you probably should not.
Work forward instead. Put sealing at the point of publication or delivery, so it costs a few minutes on the day, and reach backwards only for the material that carries real exposure: work currently in dispute, deliverables for clients likely to ask, anything being licensed or sold. The rest can stay as it is.
The instinct to seal everything is usually the same instinct that produces no records at all, because it turns a small habit into a project and the project never starts. A team that seals every client deliverable from today is in a far better position in a year than one still planning a full-catalogue migration.
If you want the reasoning behind the declaration step rather than the mechanics, our Article 50 page covers what the obligation asks for. To see what a recipient sees, verify a sealed document, or read how the flow works in more detail.
