What "sealed" and "tamper-evident" mean

“Sealed” and “tamper-evident” are precise technical claims, not marketing language — this article explains exactly what each one means, and what it doesn’t.

What it is

Finalising a survey locks it server-side and computes its record hash: a SHA-256 of the record’s own canonical form concatenated with the previous record’s hash for the same property (UPRN). That chaining is what makes the claim tamper-evident rather than an absolute guarantee — nothing prevents someone from attempting to alter a stored field, but doing so changes the record’s canonical form, which changes its hash, which no longer matches what the next record in the chain expects. The break is detectable; the attempt itself isn’t prevented. A nightly sweep independently recomputes every finalized survey’s hash chain in full; if it ever finds a mismatch, that specific record is quarantined — a display flag only, never an alteration of the evidence itself — and an integrity alert lands in your audit log and notification centre.

How to do it

1. Open any sealed record in Evidence and check its hash and chain-sequence panel — this shows the record’s own hash, the previous record’s hash it was chained against, and its position in that property’s chain.
2. To independently confirm a specific record hasn’t been altered, export its evidence bundle, which re-verifies the chain at the moment of export and includes the result in chain.json — see Evidence bundles.
3. Watch Settings → Audit log for an “EVIDENCE INTEGRITY” alert — a clean nightly run is itself recorded, so the absence of an alert is provable rather than simply an absence of evidence.

How it integrates

Every consumer of a finalized record — the evidence register, the report PDF, the nightly EDI export, the REST API, webhooks — reads from the same sealed, hash-chained record; none of them recomputes or reinterprets the integrity claim independently. A record that fails the nightly sweep is quarantined, not deleted or hidden. The claim this supports is specific: any alteration, by any means, breaks the chain and is detected on the next nightly sweep at the latest — not that alteration is impossible, only that it never goes unnoticed.

Common problems

• I saw an “EVIDENCE INTEGRITY” alert in the audit log. Treat this as a genuine incident, not a display glitch — the record named in the alert is quarantined pending investigation.
• Someone describes the evidence as impossible to alter. That overstates it — the accurate description is tamper-evident: an alteration is detectable, not prevented outright.
• I need to prove a specific record’s integrity to a third party. Export its evidence bundle — the chain re-verification result travels with it in chain.json, independent of anything you say about it.