What this register may verify for itself, and what it must take from owners

The rule

A register may look. It may not touch, and it may not conclude on a system's behalf.

Verification here means: running a read-only command a reporter has already named, or that answers a question the register itself wrote down as open, and recording exactly what came back.

Permitted:

• read-only reads of live state (kubectl get, bao policy read, an HTTP probe of a documented endpoint);
• comparing what is deployed against what a repo said is deployed;
• recording the discrepancy and routing it as a question.

Not permitted:

• any write, apply, patch, restart or rotation — including one that would obviously improve things;
• concluding what a defect means for a system this repo does not own. The system stays authoritative about itself (INTENT.md);
• verifying instead of asking. The owner is asked first; verification settles what an owner cannot see or has invited someone to check.

rapp-postgres declined to check the NetworkPolicy on flex-auth's behalf, saying that would be reporting on a system they do not own. That was right for a reporter. This register is the downstream party whose grade depended on the answer, and flex-auth explicitly named the command and asked for someone with credentials to run it. Those two positions are compatible.

What this host can actually reach — established 2026-08-20

The asymmetry is worth stating plainly: the register can check what the cluster admits, and cannot check what the secret store permits. Every grade touching an OpenBao policy is therefore a grade on a document, and says so.

That is not a gap to close by acquiring credentials. A risk register holding production secret-store access has traded a verification problem for a much 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 command, the raw result, what it confirms, what it contradicts, and what it does not establish. It names the findings it bears on, and those findings link back.

A verification is evidence, not a ruling. It can move a grade; it does not close a finding on its own, and it never speaks for the owning repo.

Verification and the cadence ladder

A verification that contradicts something is a check that is not clean: the affected findings reset to instant. A verification that confirms what was already recorded is clean, and may be exactly the evidence a rung is built on.

The first one (RISK-V-0001) did both — it confirmed the ingress claim RISK-F-0001 was graded on, contradicted the egress claim in the same message, and surfaced a third policy nobody had mentioned that bears on RISK-F-0002.