## Problem `audit_trail.id` is one serial shared by every chain. `AuditTrailVerifier` says so itself, in `shouldMintCheckpoint()`: *"`audit_trail.id` is one sequence shared by every chain … on any site running two chains the live rows of one are separated by the rows of the other."* So the first row of a chain is id 1 for exactly one chain on the site, and some larger id for every other one. The module ships four chains (`default`, plus one each from `audit_trail_entity`, `audit_trail_file` and `audit_trail_user_auth`), so a site running more than one of them has chains whose genesis is not id 1. `AcknowledgmentRepository` writes an acknowledgment's `anchor_before` and reads it back under two different rules. Writing, in `readChainAnchors()`: the live predecessor's hash, else the `anchor_after` of a live-purged segment ending at `from_id - 1`, else the empty string. ```php $anchor_before = $this->chainRepository->getRowHash($chain_id, $from_id - 1); if ($anchor_before === NULL) { $anchor_before = $this->findPurgedSegmentEndingAt($chain_id, $from_id - 1) ?? ''; } ``` Reading, in `hasValidAnchors()`: the empty string is accepted only when `$from_id === 1`, and anything else with no live predecessor and no purged segment is refused. ```php if ($from_id === 1) { return $anchor_before === ''; } $current_before = $this->chainRepository->getRowHash($chain_id, $from_id - 1); if ($current_before === NULL) { $predecessor = $this->findPurgedSegmentEndingAt($chain_id, $from_id - 1); return $predecessor !== NULL && $predecessor === $anchor_before; } ``` `from_id - 1` on a chain whose genesis is id 3 names row 2, which belongs to another chain, so `getRowHash()` answers NULL and no segment ends there. The write stores `''` and the read refuses it. `findAcknowledgmentCovering()` is the only thing the walk asks about a broken row, and it consults `hasValidAnchors()`. So on every chain but the one that owns row id 1: - recording an acknowledgment over the chain's first row succeeds, and is attested on the chain like any other; - the walk goes on reporting the range as broken, and `acknowledgments` in the verdict is empty; - the acknowledgments listing shows the row as **Chain anchors moved**, which is not what happened. The permission text calls acknowledgments the thing that *"make[s] a broken range read as verified"*, and `docs/verification.md` documents recording one as how an operator explains a break. On a multi-chain site that action silently does nothing for the one row where the chain starts. ## Reproduction Kernel probe, two chains, `alpha` taking ids 1-2 so that `beta`'s genesis is id 3. Tamper each chain's first row, acknowledge exactly that row, re-verify. ``` beta (genesis id 3) ack recorded: #5, anchor_before='' anchors_match=false after ack: ok=false acknowledgments=0 Chain "beta" broken at id 3: public hash mismatch (payload or hash column tampered). alpha (genesis id 1) after ack: ok=true acknowledgments=1 Chain "alpha" verified: 3 entries intact. Acknowledged unverifiable ranges: 1 range covering rows 1-1. ``` ## What retention does to it The refusal is not stable over time, which is what makes it hard to notice. Once the acknowledged range is purged, `hasValidAnchors()` stops reading the live table and compares against the segment's signed `anchor_before`, which the archiver minted from that same first row's `previous_hash` and which is `''`. So the waiver starts holding. Same fixture, `finance` starting at id 3, reading `anchors_match` either side of the purge: ``` before purge: webdav['', true] finance['', false] after purge: webdav['', true] finance['', true] ``` The explanation does not work while the rows it explains are still there, and starts working once retention has destroyed them. For a module whose entire premise is that evidence degrades with time, that is the wrong way round. ## Fix Genesis is a fact about the chain, not about the shared sequence, and the two sides of the question need it answered from different evidence. `hasValidAnchors()` decides whether an operator's waiver holds, so it asks the row. `audit_trail.previous_hash` carries the hash the chain held before it and is empty exactly at genesis, whatever id the row has. That is a positive answer, and it is false on a chain whose earlier segments have been lost from the index, which is what keeps a waiver from being honored on exactly the chains whose records are already damaged. It is asked last. The live predecessor and the segment that took it answer every ordinary acknowledgment before it is reached, and a recorded anchor holding a real hash decides the case for free, so nothing on the common path costs more than it did. `readChainAnchors()` needs no change. Its existing fallback already writes the empty anchor in exactly the genesis case: a range that starts a chain has no live predecessor and no segment ending where one would be. Recording an acknowledgment is not a claim that it holds, so the write side has nothing to decide. `Chain\ChainRepository::hasRowsBefore()` answers the same question for the verifier, by searching for what came before: any segment covering something below the id, then any live row below it. The segment is asked first because a purge deletes the rows, so on a chain retention has been through the live table has nothing left below a range to find. A FALSE there is a search that found nothing, which is not the same statement as "this id starts the chain": a chain that has lost a segment looks exactly like a chain that never had one. Reading the miss as genesis is an inference the caller makes, and only a caller that can afford to be wrong about it may. `scanRangeForBreak()` can, and has no alternative, because what the row says about its own predecessor is the thing the walk is there to test and using it would set the expectation from the value being checked. Wrong, that inference costs a break reported on a chain that has lost a segment, which is what such a chain is. `AcknowledgmentRepository` cannot afford it and does not call it. ## Test coverage Four tests in `AuditTrailVerifierTest` fail against the unfixed code and pass with the change: - `testAcknowledgingTheFirstRowOfAnyChainHolds`: the acknowledgment is honored and the verdict names it. - `testTheFirstRowAcknowledgmentReadsAsAnchored`: the listing stops reporting an untouched chain as moved. - `testTheFirstRowAcknowledgmentSurvivesThePurge`: it holds while the rows are live and goes on holding once retention takes them, so the answer no longer depends on how much evidence is left. - `testRetentionSeesTheBrokenLinkOnAnyChainsFirstRow`: `findUnexplainedBreakInRange()` sees a first row pointing where it never pointed, so retention marks the segment instead of bridging the gap silently. Scoped to the single-row range, which is what a segment covers whenever the chain's first bucket holds one row: a wider range hides the defect rather than removing it, because the row after the edited one fails its own link check and the scan reports that one. Two pin the direction the acknowledgment side must not take, on a chain that has lost a segment from the index: - `testAnAcknowledgmentBelowTheLostSegmentDoesNotHold`: nothing signed says what came before the range, so the waiver is recorded and does not hold. - `testAnAcknowledgmentOverTheLostSegmentIsRefused`: `findNeighborBracket()` reads the bracketing anchors off the segments that survived, so a range whose predecessors are unaccounted for is refused by name rather than given a manufactured empty hash. `ChainRepositoryTest::testHasRowsBeforeIsScopedToTheChainAndSurvivesRetention` pins the new reader's contract in the class whose premise is chain scoping, including the reading nothing else covers: the answer at a chain's own first id does not change when that range is purged, because which id starts a chain is not a fact that expires. `ChainArchiverTest` carries the cost. Its existing budget is measured on the first segment a chain ever has, where `from_id` is 1 and the question is free, which is the one shape the stage is never in again. `testTheSecondSegmentsPurgeStaysWithinItsBudget` measures the shape it actually runs in: one indexed existence probe more than before, paid once per range and only where no live row sits below it, pinned so the next addition is deliberate too. --- AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the fix and its tests. I reviewed both, and each test was confirmed to fail against the unfixed code and to pass with the change.)