01
Exact bytes. Explicit rules.
The signature covers the stored payload bytes. Each event includes a sequence number, previous hash and its own hash. Verifiers check the original bytes rather than a reserialised JSON representation.
- Explicitly validate the format version and algorithm.
- Reject duplicate JSON keys and unsafe number encodings.
- Check resource limits, ordering and the final chain hash.
02
Keep three results separate.
integrityValid describes the cryptographic check. signerTrusted reflects comparison with a separately known key fingerprint. fileStatus describes the file binding and any requested comparison. A valid self-signature does not establish an institutional identity.
03
localObservation defines the scope.
humanproof/1 accepts signed local observations. sealedObservation adds capture context without claiming an enforced restricted environment. Local time values are recorder claims. Revocation, external time evidence and organisational policies fall outside browser verification.
04
Connect the record to your process.
Use the record as separate evidence alongside the document, and keep the verification result and policy version together in the receiving system. For API, SDK and institutional integrations, we work through format transfer, error states, trust anchors and operational responsibilities for your use case.
05
PDF as a container for the record.
The native PDF evidence document contains humanproof-certificate.json. The browser accepts the designated, uniquely indexed attachment, checks its SHA-256, then applies the record contract. Do not describe that result as verification of visible PDF content or the PDF/CMS signature. Local text or JSON verification reports are unsigned outputs of a verification run.
