How the proof works

This page explains the checks behind the verification page, for people who want to know exactly what is promised.

What is promised

If anyone changes a document's contents, or any recorded step in its history, after the fact, the verification page shows Tamper detected and names the first step that no longer matches.

What is not promised

• That the signer is who they claim to be. In this test build the check is simulated.
• Legal validity. Signatures come from a simulated certifying authority.
• Protection against someone with full write access to the database who recomputes every fingerprint. The chain makes quiet edits detectable by anyone holding an earlier fingerprint, such as a printed QR code or a screenshot. It does not make them impossible for an administrator.

The sealed contents

When a document is created, its content fingerprint is a SHA-256 hash of its fields (with keys sorted, so the same fields always give the same bytes), its title and its sender. It is stored with the document and repeated in the first audit event.

The chain

Every action on a document adds one event: created, sent, signed, declined, revoked, verified. Each event's fingerprint is:

SHA-256( previous fingerprint | action | actor | detail | time )

The first event has an empty previous fingerprint. Events are only ever added, never changed or removed. Free-text reasons are left out of the fingerprint, so they can stay private.

The verification page recomputes the whole chain on every load. It checks that each event links to the one before, that each stored fingerprint matches its recomputed value, and that the first event contains the document's current content fingerprint.

The test signing service

Bloom Test CA is a signing service built for testing. It behaves like a real provider, and is replaceable by one:

1. A challenge. Each signature needs a single-use check tied to one person and one document: a 6-digit code (5 minutes, 3 tries) or a face scan. Codes are stored only as a keyed hash.
2. A short-lived certificate. It has a serial number and lasts 30 minutes.
3. A signature. The service signs, with an Ed25519 key, a fingerprint of the document's content, the signer, their role and the time.
4. A re-check. The verification page re-verifies every signature on each load. If the document, signer, role, time or certificate was altered afterwards, it shows the signature as invalid and says why. The raw signature stays on the server.

A live product would replace the test service with a licensed signing provider. Nothing else in the chain would change.

What the public page can see

A narrow view of each record: status, title, issuer, signers' names, roles, methods and times, the fingerprints and certificate details. Never field values, emails, phone numbers, user ids or free-text reasons.