tegwick
e482423523
RISK-F-0006 fixed and public — railiance-platform's restore evidence was read, not taken: 56s restore, all 13 coulomb_social row counts matching, plus the BestEffort QoS this register had graded on, plus a failed first WAL attempt recorded alongside the successful one. RISK-F-0004 high -> medium. tenant-engine corrected in both directions: payloads are returned (worse than graded) but there is no HTTP event-read route, so the live network-reachable read this register wrote down does not exist. L3 was a reachability claim inherited from a summary and never tested. RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is off by decision. ADR-0006 retires it in favour of zone-scoped enforcement. Ruled: the framing is superseded, the risk is not. A control retired before its replacement exists is still an absent control. The successor's blocker is 26 of 27 lanes having no identifiable workload, which is RISK-N-0004 with a number on it. RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against themselves; the token was never expired; and the deployed policy differs from the file, which moves 'a file is not a safe proxy for the server' from suspicion to evidence and amends verification.md — including the admission that fix_tracker.py reads records, and a record can be stale. RISK-V-0001 reconciled: ops-warden reaches the pin from the node through a tunnel, so a podSelector ingress rule does not constrain it. The observation was right and the inference was not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
112 lines
5 KiB
Markdown
112 lines
5 KiB
Markdown
---
|
|
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.
|
|
|
|
## 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`.
|