---
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: 6m
disclosure: public
revision: "adopted-1"
last_reviewed: "2026-08-20"
---

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