#3620358 makes a lost segment *recordable* and *detectable*: creation is written to the chain, every segment event carries the identity envelope, the anchors are walked, and coverage no longer seals a hole over. This is the other half — *recovering* from one — and it is not on that branch. There are exactly three states a lost segment can be in, and each needs a different route. ### 1. The chain still holds its events — rebuild from them `AcknowledgmentRepository` has three methods `audit_trail_segment` has no equivalent of: - `replayAcknowledgmentEvents()` — read the chain's events, build what the table should hold - `compareIndexToChain()` — diff that against what it does hold, returning `agrees` plus the differences - `reindexChain()` — rewrite the table from the chain, under the chain-write lock, leaving alone any entry the chain can no longer speak for Until #3620358 this was impossible for segments: a `segment_archived` event carried five of the nine fields `computeIdentityHmac()` signs, so a rebuilt row could not reseal its own `hmac`. Now that the events carry `created`, `secret_id`, `from_created` and `to_created`, the same three can be written. Follow the acknowledgment rule for what a rebuild must not touch: an entry whose recording event has aged out stays exactly as it is, because deleting it would be the rebuild destroying what it cannot replace. ### 2. The archive file survives — import it `SegmentRestorer::importFromFile()` already rebuilds a segment row from the NDJSON footer, verifying the identity HMAC first. This works today and needs nothing; it is listed so the recovery routes are documented as a set, and because it is the reason an import must not refuse an overlapping range out of hand. ### 3. Neither survives -- the anchors come from the neighbours When a segment's chain events have aged out *and* its archive file has been file-purged, nothing can rebuild the segment itself. Its *anchors* are a different matter, and they are what an acknowledgment needs. Segments carry the chain hashes that bracket them, and neighbouring segments meet exactly: the earlier one's `anchor_after` IS the later one's `anchor_before`. Both are sealed in identity HMACs that are never re-signed. So for a gap between two surviving segments: - `anchor_before` is the preceding segment's `anchor_after`; - `anchor_after` is the following segment's `anchor_before`. Neither is an operator's assertion: both are signed, and `readSignedPurgedSegment()` already verifies the envelope before trusting a neighbour's anchor. **The module already does the first half.** `AcknowledgmentRepository::findPurgedSegmentEndingAt()` takes the preceding segment's `anchor_after` as the `anchor_before` of an acknowledgment starting one past it, for the case where the acknowledgment's own range is present but its predecessor is gone. What is missing is the mirror of it, and the path that uses both when the segment covering the range is itself the thing that vanished. So this needs an implementation, not a decision, and no acknowledgment has to record that its anchors are unknown. What remains genuinely unrecoverable is narrow: a missing segment with no surviving neighbour on one side. At the head that is not a problem either, because `anchor_before` is the empty string by definition when `from_id == 1`. It is the tail, with no following segment and the rows themselves gone, where there is nothing signed left to bracket against -- and that case is already the deleted-tail finding the checkpoint raises. ### 4. Nothing calls the detector `AuditTrailRequirementsHooks` runs `compareIndexToChain()` for acknowledgments and raises a warning on `/admin/reports/status`; `AuditTrailCommands` has matching compare and reindex commands. Segments have neither surface, so `SegmentIndex::findAnchorBreaks()` from #3620358 is written and never called. Whatever this issue builds needs the same two surfaces, or a missing segment stays detectable in principle and unreported in practice. ### Scope 1. `replaySegmentEvents()`, `compareIndexToChain()`, `reindexChain()` on `SegmentIndex` 2. status-report check and drush commands for both, plus `findAnchorBreaks()` 3. the acknowledgment route for a segment neither the chain nor an archive can rebuild, taking both anchors from the surviving neighbours Depends on #3620358 (!97), which lands the events these read. --- AI-Generated: Yes (Claude Code analysed this and drafted the issue; the anchor and coverage behaviour described was confirmed with throwaway kernel probes against unpatched 1.x.)