Evidence, not assurances.
Every sketchbook keeps a complete, signed history. Sealing takes the moment that mattered — the page everyone agreed on — and turns it into a record you can hand to someone who has no account, no keys, and no particular reason to believe you.
A history convinces the people already inside
Revision history is excellent at settling “what did we change last Tuesday” among colleagues. It is much weaker in the situation you actually keep records for: a claim, an audit, a dispute — where the reader is outside your organization and their job is to assume the record was arranged after the fact.
A screenshot proves nothing. A PDF export proves nothing. A database export proves nothing either, because you control the database. What survives that reader is a record they can check themselves, made with keys they can distinguish, and dated by someone with no stake in the outcome. That is what a seal is.
Four things happen when you seal a page
Pin the exact state
The seal captures the precise content you approved — every stroke, on the pages in scope — rather than a pointer to “the current version”, which keeps moving. Choose a single page or the whole book.
Sign it on your device
Your key never leaves your machine. Before it is used, the app shows you exactly what you are about to sign and asks for explicit consent — signing is never silent.
Have an outsider date it
The signature is sent to an independent RFC 3161 timestamping authority, which returns a signed token. The date does not rest on your clock, your colleague's, or ours.
Record it, permanently
The seal is written to append-only storage and appears as a milestone on the revision timeline, re-verified every time anyone looks at it.
None of this requires a connection at the moment you draw. A seal made offline is timestamped as soon as the device can reach an authority, and the record says so rather than pretending otherwise.
As many signers as the decision needs
“Approval and counter-signature” names two intents, not two people. There is no limit of two, and the two mechanisms answer different questions.
Co-signature
One statement, many signatures. Everyone signs byte-identical content, each with their own key and their own timestamp — and the verifier reports on each separately, so “three of four approvals verify” never collapses into “the seal is invalid”. Use it when the parties are asserting the same thing on equal footing.
Because storage is append-only, two people can co-sign at the same time on different devices, offline, with no coordination — and both signatures survive the merge.
Counter-signature
A new statement that commits to an earlier one. Use it when the second approval is about the first — “I have seen what the contractor approved, and I accept it” — when the signer needs their own note, or when enough time has passed that the work may have moved on.
Co-signature gives you an unordered set of equals. Counter-signature gives you an ordered chain. Both export together, so the full picture of who agreed to what is in one file.
You decide how much the file reveals
Stronger evidence means showing more. The export dialog makes that trade explicit instead of deciding for you — four levels, each proving more than the last, each revealing more than the last. Nothing outside the sealed pages is ever included, and no decryption keys leave your device.
The picture
The statement, every signature, the timestamp tokens, and an image of the sealed pages. Proves who sealed what and when — but the image itself rests on the signer's word.
Reveals: Only the approved pages, as a flat image.
The chain
Adds the metadata of every change behind those pages. The recipient verifies the full edit history and attributes each change to a key — while learning nothing about what any change contained.
Reveals: Who changed something and in what order. Not what they drew.
The content
Adds the page data itself, so the recipient re-renders the drawing on their own machine and stops taking the image on trust.
Reveals: The final content of the sealed pages.
The full history
Adds the raw change log. The recipient replays the drawing from nothing, watches it arrive at the sealed state, and ties every change to its signed record.
Reveals: Everything, including strokes you erased — an edit log keeps them forever. The app warns you before you pick this.
The recipient needs a browser. That's the whole list.
The ZIP carries its own verifier — a single file that runs entirely on their machine. No account with us, no software to buy, no key from you, and no network connection, which also means nothing about their inspection is reported back to anybody.
It does not return a green tick. It reports every claim separately — whether the content is unaltered, whether each signature is valid, what the timestamp establishes — and it states plainly which claims the file's disclosure level does not let it check. A tool that only ever says “valid” is not evidence; it is decoration. The same applies years later: the format is documented and the verification code is open, so a bundle can be checked long after the app that made it has moved on.
What a seal proves — and what it doesn't
Being specific here is not a disclaimer. Evidence that overstates itself is worth less than evidence that says exactly where it stops, because the first thing an opponent does is look for the gap between the claim and the maths.
It does prove
- These people signed this exact statement.
Ed25519 signatures over canonical, domain-separated bytes. - They did so no later than a specific moment.
An RFC 3161 token from an independent authority — an eIDAS-qualified one where you need that. - The statement covers this exact drawing state.
Cryptographic hashes of the page's change history. - These changes were made by these keys, in this order.
Each stored change carries its own signature, and its identifier embeds its content hash. - The image shown is what the data actually produces.
At level 3 and above, by re-rendering it. Below that the verifier says it could not check.
It does not prove
- That a key belongs to a named human.
By default the parties establish that between themselves, the way they would with any other credential, and the bundle carries a directory excerpt to help. Qualified certificates close this gap — see below. - That the drawing did not exist earlier.
A timestamp is an upper bound, at every level of assurance. It proves something existed by a given moment, never that it did not exist before it.
Qualified timestamps, when the process demands them
The timestamping authority is a setting, not a fixed part of the product. That matters, because how much a timestamp is worth in a regulated process depends entirely on who issued it.
Included
Seals are timestamped by an independent public RFC 3161 authority at no cost. The token is genuine third-party evidence of time and is what most disputes turn on — it is simply not qualified in the eIDAS sense, and the verifier says so rather than blurring it.
Qualified, as an add-on
Point the same mechanism at an eIDAS-qualified trust service provider and every seal is stamped by a qualified authority instead. A qualified timestamp carries a legal presumption of the accuracy of its date and time, so the burden of disproving it moves to the other side.
This works identically on our hosting and on your own server. Because the qualified service is itself a paid subscription, it is priced as an add-on — talk to us about your jurisdiction and volume.
Going further — a qualified electronic signature — is a different step, and an honest one to be clear about: it needs a qualified certificate issued to each named signer after identity verification, with the signing key held in a certified device. That is also what would settle the one thing cryptography alone cannot, namely which human owns a key. It is on the roadmap for customers whose process requires it; ask us where it stands.
You cannot bolt this onto an ordinary app
Most drawing tools store the current state of a document and overwrite it as you work. There is nothing to seal but a snapshot, and nothing to prove but the snapshot's own say-so.
- Storage is append-only. Changes are added, never overwritten — so a past state is still there to be sealed, and still there to be checked years later.
- Every change is already signed. Authorship and order are properties of the data itself, not entries in a log that someone with database access could rewrite.
- It is end-to-end encrypted. Servers hold ciphertext, which is why the evidence file can be complete without ever handing anyone your keys — and why sealing works the same on your own server as on ours.
- It is local-first. Sealing happens on the device, so it works on a roof, in a basement, or on a plane, and syncs when you land.
That is MindooDB, the database underneath TeamSketchbook and every other Haven app. Sealing is not a feature we added on top of it — it is what the store was already doing, made visible and portable.
When a drawing has to hold up
Architects & engineers
Record which plan revision the client released for construction, with the date confirmed by a third party rather than an email thread.
Insurance & loss adjusting
Seal a damage sketch on site, offline. The seal is made when you draw it, not when you get back to signal.
IP & prior art
Establish that a design existed in an exact form by a specific date — the classic use for an independent timestamp.
Agencies & client sign-off
Turn “yes, that version” into a record neither side can quietly revise afterwards, without buying an e-signature seat for every reviewer.
Education & assessment
Fix a submission at the deadline, so later edits are visible as later edits rather than arguments.
Sealing is part of the app, not an add-on: no per-signature charge, no per-envelope charge, and no seat for the person who only ever verifies. See pricing.
Seal the version everyone agreed on.
Free to use offline or self-hosted. Open Haven, install TeamSketchbook, and try it on a page today.