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

`RISK-WP-0004-T05` asked what this repo can legitimately establish itself, because two gradings were resting on file comparison. The answer was found by trying, on 2026-08-20, rather than by reasoning about it.

## 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

Target | Result | Consequence
--- | --- | ---
Kubernetes (`railiance01`) | reads work — `kubectl get ns`, `get networkpolicy -o json` | Live cluster state is verifiable by this register
OpenBao (`bao.coulomb.social`) | 403 permission denied on `token lookup` and `policy read` | Policy claims are not verifiable here; `RISK-F-0009` rests on file comparison

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`.