Evidence Integrity & Tamper Model

Audience: security reviewers, ombudsman/regulatory readers, procurement. This is the platform's defining differentiator: survey evidence is tamper- evident and append-only, so a report can be trusted as a contemporaneous record. The operational response detail lives in a documented internal incident procedure; this page explains the model.

Why it matters

Damp-and-mould evidence in social housing may be scrutinised by the Housing Ombudsman, regulators, or a court. A record that could have been quietly edited after the fact has little evidential weight. HousingSurvey Pro is built so that a finalised survey cannot be silently altered, and any attempt is detectable.

The precise claim, stated honestly: no client app, API, webhook, or other product surface has any path to edit or delete a sealed record — that is enforced in server-side security rules and covered by an automated test suite. Beyond that, database-owner-level access (the Firebase/GCP console, or a direct Admin SDK call) is a separate trust boundary that database security rules do not — and cannot — restrict; a cloud project owner can act directly on the underlying data store. HousingSurvey Pro does not claim otherwise. What the hash chain guarantees is that any such change, from any actor, by any means, is detectable: altering or removing a sealed record changes its hash, which breaks the chain for every later record on that property, and is caught by the nightly chain verifier and by independent verification of an exported evidence bundle. The honest claim is tamper-evident, not "impossible to touch" — and that is what gives the record its evidential weight: not that access is physically prevented at every layer, but that tampering cannot be hidden.

How it works

Sealing

When a surveyor finalises a survey, it is sealed:

The record's content is reduced to a canonical JSON form — keys sorted, volatile/display-only fields excluded — so the same content always produces the same bytes.
That canonical form is hashed with SHA-256. The hash incorporates the previous record's hash (prevRecordHash) and a monotonic chainSeq, linking records into a chain per data owner.
Finalisation fields (the hashes, chain sequence, sealed timestamp) are set server-side — a client cannot forge them.

Chaining

Because each record's hash depends on the one before it, the sealed records form a chain. Altering any earlier record changes its hash, which breaks every link after it — so tampering cannot be hidden by editing a single record.

Client/server twin

The canonicaliser exists as a byte-identical twin on the client and the server. A record sealed on a surveyor's device verifies to the same hash on the backend. This parity is guarded in CI by a dedicated test and a field-level canonicaliser check, so the two implementations cannot silently diverge.

Photo provenance

Photos are SHA-256-hashed at the moment of capture and carry provenance metadata — the EXIF capture timestamp is preferred over the device clock, and the camera make/model is recorded. The hash anchors the image to the record.

Detection & response

A chain verifier recomputes the chain and compares hashes.
A broken or mismatched link quarantines the affected record — its display metadata is flagged, but the underlying bytes are never modified (the quarantine flag itself is excluded from the hash so it cannot alter what it marks) — and raises an audit event and an organisation notification.
The guiding principle is disclosure over concealment: a tamper signal is surfaced and recorded, not silently corrected. The full triage classes, comms templates, and ombudsman-safe wording are in the incident runbook.

What this gives a customer

Defensible records for ombudsman/regulatory scrutiny.
Report versioning without loss: an authorised edit creates a new sealed version chained to the original; the original remains intact and retrievable, so the full history is preserved and auditable (see report versioning).
Independent verifiability: because the algorithm is deterministic and documented, a third party can, in principle, recompute and check a chain.

Limits (stated honestly)

Integrity proves a record has not changed since sealing — it does not, by itself, prove the truth of a surveyor's judgement; that rests with the qualified assessor, as the reports state.
The model protects finalised evidence; drafts remain editable until sealed, by design.

Status: sealing, chaining, twin-parity, photo hashing, verifier/quarantine and sealed report versioning are implemented today. A revision creates a new sealed version; the original remains retrievable and exportable.