## Problem `audit_trail_acknowledgment` is treated as the record of an acknowledgment. It should be an index of what the chain already says, kept so the verifier's range lookup is fast. Today it is the other way round, and the consequences are load-bearing: - **Nothing reads the acknowledgment chain events back.** Every reference to `acknowledgment_recorded` outside `AcknowledgmentAction` is a write site or a docblock. `acknowledgment_updated` and `acknowledgment_deleted` are the same. They are written and never consulted. - **The verifier trusts the table.** `findAcknowledgmentCovering()` re-derives the *table row's* own HMAC under its `secret_id` and checks the *table row's* anchors. That verdict is what turns a BROKEN range into a verified one. So the authoritative record is the one a single `DELETE` removes without trace, and the tamper-evident one is never looked at. `DELETE FROM audit_trail_acknowledgment` silently revokes every acknowledgment on the site: each covered range goes back to reading BROKEN, the chain still says they were recorded, and nothing compares the two. The failure is at least in the safe direction — a false alarm rather than a false pass — but the module cannot tell an operator what happened, and the same shape arises innocently from a restore of a partial backup. It also means the table cannot be rebuilt. There is no path from the chain back to the index, so a lost or damaged table is lost. ## Proposed resolution Make the chain the record and the table a derived index the chain can rebuild. **Close the gap that blocks a faithful rebuild.** `acknowledgment_recorded` carries the range, the reason and both anchors, but not `created`, which is part of the acknowledgment's identity and is rendered on the acknowledgments page. `acknowledgment_deleted` already carries `recorded.created`; the recorded event needs it too. With that, replaying a chain's `acknowledgment_*` events in id order reconstructs the table exactly. **Check the chain, not the copy.** `findAcknowledgmentCovering()` compares its candidate against that replay before trusting it. This is strictly more than the row's HMAC asked: anyone holding the signing secret could re-sign a row they had just edited, and nobody can add a linked chain event without breaking the chain. The row's own signature is then redundant rather than merely unused, so the `hmac` and `secret_id` columns go, along with the "Signature invalid" state on the acknowledgments page. The anchor check stays: it answers a different question, whether the chain has moved under the range since the acknowledgment was recorded. **Let the chain allocate the identity.** An acknowledgment's id becomes the `audit_trail.id` of the `acknowledgment_recorded` event that *is* it, so a derived index stops minting an identity for the thing it indexes and an id can never be reused or invented. A signed column cannot carry the id of the row it is being signed into, so the event's `resource` names the acknowledged **range** instead — which is what the row is about, and what a resource is for. `acknowledgment_id` stays on the updated and deleted events, which are *about* an acknowledgment rather than being one. **Stop the archive carrying a copy.** The NDJSON `ack` envelopes snapshotted the index into the file. That is the same shape one layer down: a copy the restore cannot vouch for, of something the chain already records. Archives carry rows and the footer. `ack_count` goes with them — the field, the `audit_trail_segment` column, and its place in `computeArchiveContentHmac()`'s signed tuple. **Stop the live-purge evicting the explanation.** The purge dropped the index entries covering the range it took, on the grounds that the archive held a snapshot. With no snapshot that eviction destroys the only live record of why a range reads broken. Entries stay; while the rows are gone the anchors refuse them, and they cover again if the rows are restored. An acknowledgment does eventually outlive its own recording event, which retention archives and purges like any other row. That is neither damage nor rebuildable: the comparison must not call it an entry nobody recorded, a rebuild must not delete what it cannot replace, and the walk must not refuse an explanation that outlived its evidence. What licenses keeping it is the attested purge — the id falls inside a range a signed `segment_live_purged` event says was taken, and that range's archive still carries the event. **Surface and repair.** `drush audit_trail:reindex-acknowledgments` rebuilds an index from the chain, per chain or across all, with `--dry-run` to report and exit 1 without touching anything. The status report names any chain whose index and events disagree: the tamper detection this table has never had, and the signal a restore from a partial backup produces too. No update hook: the alphas are pre-release and reinstalling is the supported way to move between them. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)