tegwick f0db7c83ca RISK-WP-0002: findings publish whole; method docs public except escalation

Operator ruled both. Findings publish as the file a reader gets —
including RISK-F-0001's record that this register graded it critical
while its fix notice sat unread. A summary would be a second document per
finding kept in sync by hand, and drift is the failure this repo most
distrusts; and a published register containing only other repos' defects
reads as an accusation, while one containing its own reads as a record.

Method docs public except escalation, which is restricted because it
names spend thresholds and describes when the operator personally is
interrupted — a map of where attention is scarce, needed by nobody
judging a finding.

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

2026-08-20 22:43:48 +02:00

3.7 KiB

Raw Blame History

id	type	title	status	owner	adopted	workplan	review_interval	disclosure	revision	last_reviewed
RISK-METHOD-VERIFICATION	method	What this register may verify for itself, and what it must take from owners	adopted	risk-nexus	2026-08-20	RISK-WP-0004-T05	6m	public	adopted-1	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.

3.7 KiB Raw Blame History