Correcting a sealed record

A sealed record is never edited in place — every correction path either creates a new version or leaves the original exactly as it was, with the change itself recorded alongside it.

What it is

Four distinct actions cover every correction scenario: Revise creates a fresh draft copied from a sealed record, which becomes a new sealed version once re-finalised — the original stays sealed and hash-chained, superseded but never altered. Request deletion applies only to an unfinished draft, not a sealed record, and — unless you have manager-level evidence access — records a request for someone with that access to approve or decline, rather than deleting it outright. Withdraw marks a sealed record as withdrawn with a required reason; the record itself, its hash and its position in the chain are completely untouched, so it remains on file and independently hash-verifiable even after withdrawal. Decline a deletion request removes the request without deleting anything, leaving the draft exactly as it was.

Before you start

Revising a sealed report or acting on a draft-deletion request needs evidence permission at Edit level or above; withdrawing a sealed record needs evidence permission at Module-admin level, a higher bar than the other three. Revision is only available at all if your organisation’s revision policy allows it — a Locked policy forbids revisions outright.

How to do it

1. To revise a sealed record, open it in Evidence and choose Revise — this opens a new draft with a required reason, pre-filled from the sealed version but stripped of every seal, chain and sign-off field, ready to be edited and re-finalised as the next version.
2. To request deletion of your own unfinished draft, open it and choose Request deletion with a reason — someone with manager-level evidence access sees this land as a notification to approve or decline.
3. To approve or decline a pending deletion request, open the draft from the notification and choose the corresponding action.
4. To withdraw a sealed record entirely, open it and choose Withdraw, entering a required reason — this is a one-way action; a withdrawn record cannot be un-withdrawn.

How it integrates

A revision’s three lineage fields — lineageId (stable across every version), versionNo (incrementing) and supersedes (the version it replaces) — appear identically on the sealed record, the REST API, the nightly EDI export and the webhook payload, so every consumer of your data can key stored reports the same way and always treat the highest versionNo as current. Withdrawing a sealed record fans the signal out the same way finalising one does: your landlord organisation and, where different, the contractor who performed the work, both hear about it — a withdrawn record is never quietly hidden from a system that already ingested it. Every one of these actions is written to your audit log with the reason attached.

Common problems

• Revise is greyed out. Your organisation’s capture policy is set to Locked — an admin can change this in Settings → Capture policy.
• I need to delete a sealed record outright. There is no delete path for a finalized record — withdraw it instead, with a reason; the record stays on file and hash-verifiable, marked as withdrawn.
• A surveyor’s deletion request is sitting unresolved. Someone with manager-level evidence access needs to approve or decline it from their notifications — it doesn’t resolve itself.