Every document your product generates can carry proof it's real.
Your competitors' can't.

Where this bites, by vertical

Not your vertical? There are 589 documented use cases across 40 categories — one of them is your roadmap item.

The implementation, honestly scoped

1. At document render time: append a verify:yourcustomer.com/c footer line (or a delegated subdomain you operate for them), normalize the document text, SHA-256 it.
2. Publish the hash: a static file at /c/{hash} returning {"status":"verified"}. Static hosting is enough; a CDN makes it free at scale.
3. Wire revocation: when a record changes in your system, update the status file. That's the whole lifecycle.

Scope: a sprint, not a quarter. Normalization rules, reference implementations (JS, iOS, Android, browser extension), and cross-platform hash fixtures are Apache-2.0 on GitHub. The protocol is text → normalize → SHA-256 → GET — there is intentionally nothing clever to integrate against.

The business case

• Differentiation that demos in 30 seconds. "Documents from our platform can be verified by anyone, instantly. Documents from theirs can't." Sales teams know what to do with that.
• Retention. Once a customer's auditors, banks, and counterparties start verifying documents against your endpoints, switching away has a visible cost.
• A premium tier that costs you almost nothing. Hash hosting is static files; the margin on a "verified documents" plan is essentially 100%.
• Co-branding on every document. Each verification response can carry issuer metadata — your customers' documents quietly advertise your platform to every verifier.

The second product: retrospective backfill

Most valuable documents already exist. Your customers hold systems of record — student records, licence registers, HR databases, receipt archives — full of documents people keep phoning them to verify. Turning legacy records into verification endpoints is a product in itself: bulk hash generation, canonical text templates, status management, delegated-domain setup, audit logs. The deeper sketch of that business is written up in Retrospective Verification SaaS.

One half of the market sells availability ("we host fast verification endpoints by the million"). The other half sells adoption ("we turn your legacy records into verifiable claims"). Both are open.

"If it's an open standard, what do we own?"

The rails are free and not patent-locked — deliberately, because that's why the standard can win. What's defensible is everything around the rails: integration into systems of record, revocation workflow, compliance and audit posture, uptime, and being the vendor institutions trust. Email is an open standard too; nobody thinks that made email products a bad business. The closest precedent is Let's Encrypt: free certificates commoditized the bottom of the CA market, and the durable money moved to certificate management — the same up-stack shape sketched in our write-up of that episode.

And the platform risk runs the other way: when phone cameras and browsers ship verification UX natively — the way Live Text went from third-party apps to the native camera — the question is whose endpoints exist for them to query. The vendors who wired up issuers early will own those relationships.

Be a founding integration

The first ten SaaS integrations get free advisory support from the standard's author — review of normalization templates for your document types, fixture generation, and endpoint design, by email, up to a sensible advice limit — in exchange for being nameable. Sustained implementation work is beyond the free scope and can be referred to commercial integration partners. Founding integrations are listed permanently on the founding adopters page.