The signed PDF problem
A PDF that was signed yesterday can be edited today — an amount changed, a clause swapped, a date moved — and the result looks exactly like the original. Same layout, same fonts, same signature image sitting on the line. The tools to do it are complimentary, and the edit takes minutes.
This matters anywhere a document carries weight after the moment it is signed: a wire authorization, a contract, a testamentary signing, a delivery record. The question is simple and hard to answer with ordinary tools: is this the same document that was sealed, or a copy that was quietly altered?
Opening the file and reading it cannot answer that. The document itself has to carry the evidence.
What a real integrity check needs
A serious check has three parts, and most "verification" offers only one of them:
- A cryptographic fingerprint. A hash such as SHA-256 reduces the document's content to a fixed fingerprint. Change one character and the fingerprint changes completely. This is the strongest layer — but on its own it is a string of hex characters no human can sanity-check at a glance.
- A human-verifiable count. The character count of the document's human-readable content can be checked by a person, with ordinary tools, without trusting any platform. It is weaker than the fingerprint but independently meaningful: two different checks failing in different ways tell you more than one check failing twice.
- A graded verdict, not a binary stamp. Real evidence is not always all-or-nothing. A supporting check can mismatch while the core evidence holds. A verification system should say how much failed — not flash a green check or a red X and leave you guessing.
And one more requirement sits underneath all three: the check must work offline. If verification depends on a vendor's server staying up, an account staying active, or a subscription staying paid, then the proof expires with the business relationship. A document sealed today may need to be verified in twenty years.
DocLock: the model
DocLock is Protocol One's document-integrity standard — the "What" layer of a stack that records who approved, what was approved, and when, with an Alfa Code label for the record. DocLock is not document storage and it is not a signature service. It is a lock relationship: at the moment of sealing, it binds the document's fingerprint and counts into a record that travels with the document and can be rechecked by anyone holding it.
DocLock's evidence model:
- Core: SHA-256, the final cryptographic authority, plus the character count of the human-readable content itself — not file metadata — as the primary human-verifiable authority.
- Supporting: pixel count of the final rendered form (the primary check for photographs and artwork) and a QR Trust Capsule that carries the key integrity values in portable form.
The verdict engine grades what it finds:
- Verified — every check matches.
- Warning — one supporting check mismatches.
- Integrity Alert — one core layer fails, or multiple supporting checks fail.
- Broken Seal — the cryptographic check fails, or multiple core layers fail.
Later edits are never silent replacements: an edited document becomes a new, separately verifiable version, and the original seal still says what it says.
The current implementation, DocLock 1.5, passed 183 of 183 verification checks in testing. Its time evidence is attested through two independent RFC 3161 timestamp authorities (FreeTSA and DigiCert, agreeing within ±1 second), and verification runs offline — the sealed record is self-contained. Time is reported on its own axis, separate from the integrity verdict, so an attestation question never inflates or deflates what the document evidence shows.
Try it yourself
You do not have to take any of this on faith — that is rather the point. Protocol One publishes a Sample Proof Pack: a fictional wire authorization, sealed with DocLock 1.5, alongside a copy altered by exactly one character — an amount changed from 48,500 to 48,900. Download both, run the check, and watch the original return Verified while the altered copy returns Broken Seal. The store's homepage runs the same one-character tamper test live.
The full machine-readable description of the stack behind this is on Protocol One's AI Index Page.
Honest limits
DocLock proves a document is unchanged. It does not prove that what the document says is true, that the signer had authority, or that a signature was voluntary. No integrity tool can prove those things, and any tool that claims to is overselling.
The sample proof pack demonstrates What and When — document and attested time. It does not include a bound Tri-Signature event, so it makes no claim about Who. In the full stack, a Tri-Signature event (three handwritten signatures completed within a ten-second burst — Intent, Identity, Confirmation) is bound into the seal at signing; a patent application for Tri-Signature is in progress.
The standard, not just the tool
Protocol One publishes its standards so that verification never requires trusting Protocol One. Anyone holding a sealed document can check it — no account, no permission, no platform. That is the fourth law of Identity Physics, the framework underneath the stack: verification needs no permission.
Sealed toolkits, the sample proof pack, and the published standards are at protocolone.store.
Protocol One LLC — Standards Office, 3707 E Southern Ave, Suite 1023, Mesa, AZ 85206. {^}