risk-nexus/docs/rulings/2026-08-19-third-grading.md

id	type	title	status	owner	date	workplan
RISK-RULING-2026-08-19-C	ruling	The inbox round: two grades corrected, one note promoted	recorded	risk-nexus	2026-08-19	RISK-WP-0001-T06

The inbox round — 2026-08-19

The register graded seven findings today and then read its inbox. Six messages were waiting, four of them unread since 2026-08-17. Three gradings changed.

This ruling records the corrections and the process defect that caused them, in that order, because the corrections matter more and the defect is this repo's own.

RISK-F-0001 — corrected critical → high, and closed fixed

Two messages from flex-auth, both already in the inbox at grading time.

2026-08-18, the NetworkPolicy answer. The exposure question the finding left open — and which this register wrote up as "the first question at review" — had already been answered. Both production Deployments ship a NetworkPolicy narrower than default-deny: one namespaceSelector plus one podSelector on port 8080, egress empty, in force since before the period the A0 describes. The reachable set was the single paired workload, not the cluster. L3 → L2, critical → high.

flex-auth also volunteered a correction to their own earlier phrasing to ops-warden, and asked that three caveats be recorded rather than taken from them: label selectors are position and not identity, the policy cannot bind the asserted resource.system, and they could not verify the live cluster because kubectl returned Unauthorized. A reporter who says "I can tell you what is specified, not what is admitted" is doing this register's job for it.

2026-08-19 12:35, the fix. Both Deployments enforce ADR-0004 TokenReview; live unbound-request probes return 401 rather than a decision; tenancy.current.A is 2; FLEX-WP-0015 is finished. Closed fixed on a probe against the running system, which is the standard docs/method/review.md requires. Disclosure flips to public; handover to policy-nexus is outstanding.

The trigger-1 escalation is withdrawn without being sent, roughly four hours after it was raised.

RISK-F-0002 — constraint lifted, escalation withdrawn

The trigger-6 escalation existed to make the operator hold an ordering: do not enable policy.enabled while the oracle is forgeable. The oracle stopped being forgeable the same day. Enabling the gate is now ops-warden's availability question and no longer an attestation hazard.

ops-warden judged this did not need the operator and, in the outcome, they were right. The register's disagreement was never about the hazard; it was about whether "written down in both repos" keeps a thing held. It did not — the window closed because flex-auth shipped, not because anyone re-read the note. Both positions survive intact and the escalation is withdrawn.

The finding stays open at medium. The gate is still off.

RISK-N-0002 promoted to RISK-F-0008 — erasure versus audit

Ruled a note this morning on the reasoning that no obligation exists yet. That was decided without reading audit-core's message of 2026-08-18, which routes the question here explicitly, by both available routes, and asks for an owner rather than an opinion.

The note failed the second floor test. Recording it does change a decision: if the exemption does not hold, the remedy is encrypt-then-hash at accept time, which is not retrofittable onto events already accepted. A decision that can only be taken early is exactly the kind a register exists to surface early.

RISK-F-0008 is the first finding this repo owns itself, which follows from INTENT.md moving regulatory intake here on 2026-08-17. It escalates on trigger 2. What this repo owns is the record — what the source says and what is therefore established. Not the legal advice, and not audit-core's redesign.

Two things accepted from reporters

The record format — rapp-postgres asked this register to accept or reject the shape RISK-F-0001 arrived in. Accepted, and extended rather than replaced: the reporter's fields are unchanged, this repo's grading fields are added below them, and the split is now written down in findings/README.md. Their instinct to keep it minimal until a second finding existed was right; it survived five more.

The escalation vocabulary — ops-warden offered the design of their warden plan classifier: a typed act plus the reasons that produced the verdict. Adopted into docs/method/escalation.md. Their point that a condition without an act tells the operator something is wrong without telling them what they are being asked to do is the gap the draft had.

RISK-N-0003 records the remaining open observation from that round — everything found by reading, nothing by monitoring — as a note, because no repo owns it and there is no defect to route.

The process defect, recorded plainly

The NetworkPolicy answer arrived 2026-08-18. The fix notice arrived 2026-08-19 at 12:35. This register's first grading ran at 21:14 the same day and used neither. It graded a fixed defect as live, at a severity one band too high, on an exposure question it wrote up as unanswered while the answer sat unread.

Nothing about the method caused this and no instrument was wrong. The register simply did not look. That is the failure INTENT.md names — a finding that disappears into whichever document happened to be open — arriving as an answer rather than a finding.

Two changes, both live:

• Reading the inbox is question zero of every review and step zero of every grading (docs/method/review.md).
• make check reports escalations awaiting the operator, so a batch that has gone stale is visible before it is sent.

The register was lucky today: the correction and the fix arrived within hours of the mistake, so nothing was acted on. Luck is not a control.