`AuditTrailVerifier::verifyChainPublic()` was the auditor-mode walk, and `docs/verification.md` promised of the layer it checks: *"no secret is required, anyone with read access to the row can reproduce the check."* It resolved the operator secret anyway, through the transient-column check, and without one it called a healthy chain broken. ### The defect `hasValidLifecycleSignature()` returned the same `FALSE` for two different things: - the signature does not re-derive, which is a fact about the row: someone wrote it without the key; - the secret that signed it cannot be resolved, which is a fact about the machine: the key was rotated out, deleted, or was never there. With no secret, every attestation read as forged. Transient-purge is the first retention stage, so this is the ordinary state of every long-lived install, and the one reader the method existed for was the one reader that got the wrong verdict. Probe, three rows and one transient-purged segment, secrets then deleted: ``` WITH secret: ok=true Chain "webdav" public hash chain verified: 4 entries intact. WITHOUT secret: ok=false Chain "webdav" broken at id 1: context_transient is NULL but the signed write-time hash is non-empty and no covering audit_trail_segment row attests a transient-purge... ``` ### Three levels, not two Telling those two apart is the fix, and it gives three meaningful behaviours rather than a boolean. `VerificationDepth` says how much signature verification a walk performs: | | secret cannot be resolved | signature does not re-derive | | --- | --- | --- | | `Strict` | break | break | | `Tolerant` | accepted, named in the verdict | break | | `None` | not asked | not asked | `None` is not a statement about what the caller holds. A site holding every key has three reasons to ask for it: it skips an HMAC per row and per segment, which on a chain of millions is the difference between a walk and an outage; its verdict cannot vary with which keys happen to resolve, so two parties comparing copies are comparing the same check; and it is exactly what a reader without the keys gets, so an operator can see what an auditor will see before handing a copy over. Tolerance applies to both signature kinds. Tolerating a missing key on a segment's lifecycle signature while still breaking on a missing key for the row HMAC was a silent fourth behaviour, from one keyring, in one walk. Whatever a walk accepts without checking is listed in the verdict's `unauthenticated_attestations`, and `authenticated_ok` is NULL on anything but `Strict`, so a weaker guarantee cannot be mistaken for a stronger one by reading `ok` alone. ### Removing the second walk The module carried **two complete chain walks**: `verifyChain()` delegating to `walkChain()`, and `verifyChainPublic()` with its own 117-line copy of the row loop. That is where the duplication came from — a second walk needs its own row check, which needs its own transient check, which needed its own segment finder. There is one walk now, taking a depth. Removed outright, pre-1.0: - `verifyChainPublic()` - `verifyRowPublic()` - `verifyTransientColumnPublic()` `verifyChainPublic()` had no production caller in any case: not the drush commands, the controllers, the cron verify hook, or any of the five submodules. Its only consumers were its own tests and the docs. ### Scope note This grew past its original title while being reviewed. The title now names what the change is rather than only the symptom that started it. --- AI-Generated: Yes (Claude Code performed this audit, drafted these findings and wrote the code and tests on the merge request. The probe was run against unpatched 1.x and each fix toggled off to confirm its test fails without it.)