RISK-WP-0004-T05: establish what this register can verify, by trying it

Cluster reads work from this host; OpenBao returns 403, the same wall
ops-warden hit. So the register can check what the cluster admits and
cannot check what the secret store permits, and every grade touching an
OpenBao policy is a grade on a document. That asymmetry is recorded
rather than closed: a risk register holding production secret-store
access would have traded a verification problem for a worse one.

RISK-V-0001 is the first verification. It confirms RISK-F-0001's ingress
claim against the live cluster — the first grade here standing on
evidence this repo gathered — contradicts the 'egress: []' claim, which
live shows as 443/6443 to anywhere, and surfaces a third policy created
the day of the fix whose Ingress policyType carries no rules, which bears
on whether enabling ops-warden's gate would fail closed.

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

docs/method/verification.md

@@ -0,0 +1,84 @@
+---
+id: RISK-METHOD-VERIFICATION
+type: method
+title: "What this register may verify for itself, and what it must take from owners"
+status: adopted
+owner: risk-nexus
+adopted: "2026-08-20"
+workplan: RISK-WP-0004-T05
+review_interval: 180d
+---
+
+# Verification
+
+`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.
+
+## 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`.