risk-check status proves the detector ran, never that the blocking fire happened #205

New issue

Closed

opened 2026-08-16 17:22:23 +00:00 by john · 0 comments

john commented

2026-08-16 17:22:23 +00:00

Owner

The gap

risk-check status proves a resolved commit range was READ and RECORDED. It does
not prove the consequence happened.

workflows/execute.md tells a cooperative coordinator exactly what to do: on a
non-empty matches or inconclusive: true, write the diff, fire risk_surface,
and treat it as blocking. But status returns ok:true on the strength of the
detector record alone. There is no requirement of a reviewer bracket, a settled
findings file, an adjudication outcome, or an explicit user override for a range
that matched.

So a coordinator can run the detector, skip the blocking fire, and still receive
a clean completion status. The prose is the only thing holding the sequence
together, and Cadence's own stated failure model is a fallible coordinator, not a
cooperative one.

Why this is the same species as the checks Cadence already builds

The tree repeatedly replaces "the prose says to" with "the seam refuses":
self-verify check 19 refuses an inline caller-derived-text site, the census test
reddens on a pasted-back containment predicate, risk-check status itself exists
because "a check whose answer never reached the record is a check the next reader
cannot see."

This finding is that same argument applied one step further out. A fire whose
answer never reached the record is a fire the next reader cannot see either, and
status is the natural place to notice.

The fix shape

status refuses - as it already does for an unrecorded check - when the record
shows a MATCHED or INCONCLUSIVE range with no corresponding outcome event for
that trigger under the same correlation id. The trace already carries
adjudication and rearm outcome events keyed by corr, so the join exists; what
is missing is status requiring it.

Open question worth settling in the same pass: an explicit user override is a
legitimate terminal state and currently leaves no outcome event of its own. It
would need one, or status would refuse a range the user deliberately cleared.

Same family as #197 (the re-arm cap has no new-information valve) - both are
about the blocking path's terminal states being under-recorded.

Source: external strict re-review, 2026-08-16 (FLOW-01, Medium). Not
independently verified here beyond reading the workflow prose and the status
contract.

## The gap `risk-check status` proves a resolved commit range was READ and RECORDED. It does not prove the consequence happened. `workflows/execute.md` tells a cooperative coordinator exactly what to do: on a non-empty `matches` or `inconclusive: true`, write the diff, fire `risk_surface`, and treat it as blocking. But `status` returns `ok:true` on the strength of the detector record alone. There is no requirement of a reviewer bracket, a settled findings file, an adjudication outcome, or an explicit user override for a range that matched. So a coordinator can run the detector, skip the blocking fire, and still receive a clean completion status. The prose is the only thing holding the sequence together, and Cadence's own stated failure model is a fallible coordinator, not a cooperative one. ## Why this is the same species as the checks Cadence already builds The tree repeatedly replaces "the prose says to" with "the seam refuses": `self-verify` check 19 refuses an inline caller-derived-text site, the census test reddens on a pasted-back containment predicate, `risk-check status` itself exists because "a check whose answer never reached the record is a check the next reader cannot see." This finding is that same argument applied one step further out. A fire whose answer never reached the record is a fire the next reader cannot see either, and `status` is the natural place to notice. ## The fix shape `status` refuses - as it already does for an unrecorded check - when the record shows a MATCHED or INCONCLUSIVE range with no corresponding outcome event for that trigger under the same correlation id. The trace already carries `adjudication` and `rearm` outcome events keyed by corr, so the join exists; what is missing is `status` requiring it. Open question worth settling in the same pass: an explicit user override is a legitimate terminal state and currently leaves no outcome event of its own. It would need one, or `status` would refuse a range the user deliberately cleared. ## Related Same family as #197 (the re-arm cap has no new-information valve) - both are about the blocking path's terminal states being under-recorded. Source: external strict re-review, 2026-08-16 (FLOW-01, Medium). Not independently verified here beyond reading the workflow prose and the status contract.