How verification works

Every document the workflow produces — the draft PDF, the signed PDF (with an appended Certificate of Electronic Signature), and the final notarized PDF — is run through the SHA-256cryptographic hash function the moment it's created. The 64-character hexadecimal output is stored alongside the file in our database.

SHA-256 is a one-way function. Two different files essentially never produce the same hash; even flipping a single bit in a PDF rewrites the hash entirely. That property is what makes a hash a fingerprint for the bytes.

When you paste a hash and we report a match, three claims follow:

1. Existence. A file with that exact byte-for-byte content was registered by this workflow at the time we record.
2. Integrity. The file you computed the hash from is bit-identical to the registered file. Any modification — even one whitespace character — would have produced a different hash.
3. Audit linkage. The match resolves to a matter and (when applicable) an e-sign envelope, which carry an append-only log of every event from intake to notarization. We expose a count of those events in the result, but never the payloads.

What a match does notprove on its own: who the parties were, what the document said, whether it's legally enforceable for any particular use. Those questions require looking at the document itself plus the audit trail in context.

The signing flow records an append-only sequence of audit events: token issuance, link opens, ESIGN/UETA consent capture (with timestamp + IP + user agent), KBA-lite identity check (DOB + last-4 SSN), per-page view tracking, the signature itself, and envelope completion. The notary step adds a notarization event with the notary's commission information. The signed file carries a Certificate of Electronic Signature page that prints the document hash, the audit table, and a reference to this verifier.

The audit trail is the attribution evidence that Tex. Bus. & Com. Code § 322.009 calls for: determined from context means assembling a chain of signals tying the signature to the signer.

• § 322.005 — UETA only applies when the parties have agreed to use electronic records. The consent screen presented to every signer captures that agreement before any signing UI is shown.
• § 322.007— An electronic signature is not denied legal effect because it's electronic. This is the headline rule.
• § 322.011— Notarization may be performed electronically when the notary's information is attached or logically associated with the signature or record.The notary block stamped onto the final PDF satisfies the “logically associated” requirement.
• § 322.012 & § 322.013 — Records must be retained and are admissible. The hash + the immutable audit trail provide the integrity story.

This is demo.shorterday.com — a sales/engineering demo, not a production deployment. The notarization step is performed by the attorney user acting as a stand-in notary. A real production install would integrate a Texas-commissioned online notary public per Tex. Gov't Code Ch. 406, Subch. C (§ 406.101–.110), with the notary appearing live by audio-video for the signer. Verification results from the demo deployment surface that fact in a banner on every match.

The hashing, the audit trail, the e-sign capture, and the Texas UETA compliance machinery are genuinely sufficient through the e-sign step. The demo-simulation label applies only to the notary step.

Most operating systems ship with a SHA-256 utility:

• macOS / Linux: shasum -a 256 path/to/document.pdf
• Windows (PowerShell): Get-FileHash path\to\document.pdf -Algorithm SHA256

Compare the output to the value printed on the certificate page, or paste it into /verify to round-trip through the database.