Two activity definitions, in the shape activity-core's own definitions
use. hourly-register-inbox-watch fires only when an unread message waits
for risk-nexus — the inbox is the trigger rather than the clock, because
an unread message is by construction a claim that something may have
moved, and 2026-08-19 proved the register will otherwise grade without
looking. daily-register-check-sweep is the unconditional floor at 07:15.
Both emit an instruction to a session that can exercise judgement, and
both say in their own text that they must never grow the ability to
record an outcome: stamping clean without doing the five questions
produces a 1q rung that is a lie about stability.
RISK-WP-0004 is finished.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
T02 inbox check, wired into make check and verified against the actual
2026-08-19 failure — replayed at that moment it surfaces all three
messages that were already waiting. T03 sweeps the rest of the
quietly-tolerated class: bad dates, cadence off the ladder, undefined
disclosure states, dangling constraint_on and related refs, embargoes
without conditions, escalations without triggers. T04 requests
verification of user-engine's tenant boundary — the first walk down the
on-request path, chosen as a consumer not already known to fail it. T05
established by trying what this register can verify: cluster yes, OpenBao
403. T06 puts regulatory records on the findings ladder.
T01 stays in progress: the procedure, make due and make checked exist,
but arming something that runs them on schedule is a standing compute
commitment and the operator's to make.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Operator ruling 2026-08-20. Severity no longer sets the review interval.
A check that comes back clean climbs one rung — instant, 1h, 8h, 24h,
48h, 96h, 7d, 14d, 1mo, 1q — and anything wrong drops straight back to
instant. A quarter is the ceiling. The operator may defer an instant
finding to a stated date; that is the only other way off the bottom rung.
The rung is the point: it says how stable the estate has been on that
matter, which is information severity does not carry. Volatile things get
attention automatically; quiet things stop consuming it; neither
judgement has to be made by a person who might be busy.
Escalation trigger 5 rebased onto the ladder — fourteen days at the
bottom rung, whether that is failing checks or no checks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Read the repo inbox after grading, which is the wrong order and is now
recorded as such. flex-auth had answered the NetworkPolicy question on
2026-08-18 (narrow ingress, not default-deny — L3 becomes L2, critical
becomes high) and reported RISK-F-0001 fixed at 12:35 today with live 401
probes. F-0001 closes fixed and public; its escalation is withdrawn
before it was ever sent. RISK-F-0002's ordering constraint lifts with it
and its trigger-6 escalation is withdrawn.
audit-core had routed the erasure-versus-audit legal question here on
2026-08-18 asking for an owner. RISK-N-0002 was wrong to call it a note:
the remedy is not retrofittable, so the decision can only be taken early.
Promoted to RISK-F-0008, owned by this repo as regulatory intake,
escalated on trigger 2.
Accepted rapp-postgres's record format and ops-warden's typed-act
escalation vocabulary. Reading the inbox is now question zero of every
review.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Four in as findings — tenant-engine unfiltered event read (high),
audit-core read path bounded by a flag not by code (medium), apps-pg with
no backup at all (high, escalated on spend), and the unverified tenant
boundary itself (high now, critical at production, escalated on
ownership, fix_owner deliberately unset). Two out as notes — noisy
neighbours and erasure-versus-audit, both real, neither changing a
decision this month, both carrying an event to be re-read at.
The round amended the scale twice: build mode lowers impact as well as
likelihood, and non-adversarial findings get their own likelihood
reading. The escalation rule gained a ratio test that distinguishes a
first sweep from steady-state intake, and a batching rule.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Severity (impact x likelihood, fidelity modifier for controls that lie,
headline-vs-constraint, build-mode double grade, the floor), disclosure
(publish/embargoed/restricted, and the build-mode deferral re-taken and
narrowed with RISK-F-0001 in hand), escalation (the five INTENT triggers
settled plus an ordering-hazard trigger the RISK-F-0002 case forced;
proposed, awaiting the custodian), review (intervals, what a review is,
what missing one produces, the production re-score).
Then applied: RISK-F-0001 critical/embargoed/escalated, RISK-F-0002
medium with a high constraint on RISK-F-0001's remediation, filed as a
peer and escalated only on the ordering, RISK-F-0003 high/embargoed/no
escalation. No unset field remains.
REGISTER.md is generated; make check reports overdue, stalled, ungraded
and unanswered escalations without changing anything.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
