## Problem The chain links its rows: every row's `hash` covers the previous row's, so altering one breaks the next. Segments do not link to each other. Each is attested only by its own `segment_created` and `segment_archived` events, and retention purges those like any other row. After that, an archived segment rests on its three HMACs. Those are the operator's word, and unreadable to anyone without the signing secret. On a long-lived install that is the ordinary state of most of the archive. ## Proposed change Do to segments what the chain already does to rows. Each archived segment produces a digest over its own fixed facts (chain, range, anchors, `file_sha256`, row count), and the digests link: `S_k = H(k, S_k-1, D_k)`. The head is stored on the segment as `spine`, with its position as `spine_height`, and written into the permanent bucket of the event that recorded it: `segment_archived` for an ordinary segment, `segment_compacted` for the row compaction leaves behind. The row's public hash covers that bucket. A replay reads both kinds, and the compaction event is the newer of the two, so on a chain old enough to have compacted it outlives the archive events it replaced and is what still corroborates that stretch. Three things follow: - A new archive re-attests the older ones, so a living archive event stands behind segments whose own events are gone. - One value covers everything below it: checking forty segments no longer needs forty surviving events. - A local edit becomes a global rewrite. Altering segment 5 changes every head above it, so every later segment row and every later archive event has to change too, and those are chain rows whose HMACs a reader without the secret cannot produce. There is no separate digest over an archived range's rows. `anchor_after` already is one: a row's hash covers its `previous_hash`, so the hash of the row at `to_id` transitively covers every row back to `anchor_before`. ## Compaction A consolidated row records the height and head of the highest segment it absorbed, and `compacted_segment_count` says how many original segments it stands for, which is also the stretch of `spine_height` it occupies. That count is transitive: a run being folded can contain a consolidated row from an earlier round, and it counts for the whole span it already stood for rather than as one row. A replay adopts the recorded head rather than deriving it: the rows it would derive from were deleted by the transaction that wrote it. What holds the adopted head to account is the segment archived next, whose own head was folded onto it. ## Scope - `spine_height`, `spine` and `compacted_segment_count` on `audit_trail_segment` - `Segment\SegmentSpine` and `Segment\SpineReplay` - the `spine` verdict key, reported at every `VerificationDepth` because nothing in it reads a secret - a purged range bridged on the spine where signatures cannot be read, named in `unauthenticated_attestations` rather than crossed silently - tests in both directions, and docs in `architecture.md`, `verification.md`, `threat-model.md` and `commands.md` ## Out of scope Proving anything about purged rows. They are destroyed and nothing recovers them. If archive files are WORM-exported, those files prove the rows and the whole chain can be rebuilt from them without this; if they are not, the rows are gone and what remains to attest is the account of them. Against an attacker holding the signing secret this is cost and detection surface, not a barrier. 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.)