Problem
Attestations will sometimes be wrong — a gateway misreports a model version, a
policy reference points at the wrong document, a duplicate slips through. An
immutable log with no correction path forces a bad choice between a permanently
wrong record and a mutable log that is worthless as evidence.
What to do
Implement supersession rather than mutation:
supersede(original_id, replacement: Attestation, reason_hash) writes a new
record that references the original. The original is never altered.
- Only the original submitter, or an admin acting under a documented process,
may supersede.
- Reads return the current record by default, with the full chain available via
an explicit history call.
- Emit an event so indexers can update derived state.
- Guard against supersession loops and cap chain depth.
Decide, and write down, whether superseding a record that has already been
metered and settled is permitted at all — it probably should not be, without a
dispute.
Acceptance criteria
Notes
This is the difference between "immutable" and "useful". Auditors expect
corrections to exist; they expect the original to still be visible.
Problem
Attestations will sometimes be wrong — a gateway misreports a model version, a
policy reference points at the wrong document, a duplicate slips through. An
immutable log with no correction path forces a bad choice between a permanently
wrong record and a mutable log that is worthless as evidence.
What to do
Implement supersession rather than mutation:
supersede(original_id, replacement: Attestation, reason_hash)writes a newrecord that references the original. The original is never altered.
may supersede.
an explicit history call.
Decide, and write down, whether superseding a record that has already been
metered and settled is permitted at all — it probably should not be, without a
dispute.
Acceptance criteria
Notes
This is the difference between "immutable" and "useful". Auditors expect
corrections to exist; they expect the original to still be visible.