Five owner replies worked through: one fix closed, two grades corrected, one control retired

RISK-F-0006 fixed and public — railiance-platform's restore evidence was
read, not taken: 56s restore, all 13 coulomb_social row counts matching,
plus the BestEffort QoS this register had graded on, plus a failed first
WAL attempt recorded alongside the successful one.

RISK-F-0004 high -> medium. tenant-engine corrected in both directions:
payloads are returned (worse than graded) but there is no HTTP event-read
route, so the live network-reachable read this register wrote down does
not exist. L3 was a reachability claim inherited from a summary and never
tested.

RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is
off by decision. ADR-0006 retires it in favour of zone-scoped
enforcement. Ruled: the framing is superseded, the risk is not. A control
retired before its replacement exists is still an absent control. The
successor's blocker is 26 of 27 lanes having no identifiable workload,
which is RISK-N-0004 with a number on it.

RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against
themselves; the token was never expired; and the deployed policy differs
from the file, which moves 'a file is not a safe proxy for the server'
from suspicion to evidence and amends verification.md — including the
admission that fix_tracker.py reads records, and a record can be stale.

RISK-V-0001 reconciled: ops-warden reaches the pin from the node through
a tunnel, so a podSelector ingress rule does not constrain it. The
observation was right and the inference was not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/method/verification.md

@@ -66,6 +66,31 @@ worse one. If OpenBao claims need verifying, the right answer is for the owner
 to run the read and report it, which is what `ops-warden` did — the obstacle
 there was an expired token, not the arrangement.
 
+## A file is not a safe proxy for the server
+
+Established 2026-08-21, by evidence rather than by caution. `ops-warden` ran
+the live OpenBao read that `RISK-F-0009` had been graded without, and **the
+deployed policy differs from the committed file.** No lane maps to the drifted
+path, so nothing was exposed — but the general claim is now proven rather than
+suspected.
+
+Consequences this register accepts:
+
+- **Every grade made off a checkout is a grade on a document**, and says so on
+  its face. `RISK-F-0009` does.
+- A verification that reads a file is a **weaker artifact** than one that reads
+  a server, and the record must not blur them. `RISK-V-0001` reads a server;
+  the OpenBao comparison in `RISK-F-0009` reads a file.
+- Where only the owner can reach the server, the owner's probe is the evidence
+  and the register says whose it is. That is not a lesser standard — it is the
+  correct one, given `verification.md`'s own limits.
+
+The corollary is uncomfortable and worth stating: **drift between file and
+server is invisible to anyone reading files**, which is most of this estate's
+tooling, including `fix_tracker.py`. What that tool reads is what a repo
+*recorded*, and a record can be as stale as any other claim — as four
+self-reported stale blockers in twelve hours demonstrated on 2026-08-21.
+
 ## Recording a verification
 
 One file per verification in `docs/verifications/`, `RISK-V-NNNN`, stating the