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 contemporaneous record with a preserved change history is easier to verify than one reconstructed later. HousingSurvey Pro prevents product users from editing or deleting a finalised survey and uses chained hashes to expose partial or inconsistent changes.

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. Altering or removing a sealed record without consistently rebuilding the later chain changes its hash and is caught by the nightly verifier or independent verification of an exported evidence bundle. A project owner with direct database access is technically capable of rewriting underlying records and their dependent hashes; a previously exported bundle or independent monitoring provides the external comparison point in that scenario. The honest claim is tamper-evident within a documented trust model, not "impossible to touch".

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.