resolved and reassignment are prompt-only invariants with no validator, so a string "false" resolves an incident #88

New Issue

2026-08-30T02:44:06-04:00

logan commented

2026-08-30 02:44:06 -04:00

Found by the standing static correlation pass, unattended run 2026-08-30. Static reading only. Searched open and closed — not a duplicate of the closed #18, which is about incidents never recording resolved_at; this is about the extracted resolved flag being unvalidated on the way in.

What happens

intelligence.py:275-276 coerces both fields with a bare bool(). There is no allow-list guard of the kind _VALID_INCIDENT_TYPES already provides for incident type. Because a non-empty string is truthy in Python, a model returning the JSON string "false" — rather than the boolean false — is read as True. These values come straight from an LLM, so the type is a prompt convention, not a guarantee.

Consequences

resolved truthy at routers/upload.py:342-348 writes status: resolved onto whatever incident the scene linked into. On a scene that linked into a long pre-existing incident chain it has no real claim to, that closes someone else's incident — and it then cascades through maybe_resolve_parent.

reassignment truthy blanks units at routers/upload.py:324 and changes which fit path the call takes.

This is the same hazard class DEFERRED.md already records for the severity ladder, now on two newer fields that never got the same treatment.

Fix direction

Validate before coercion: accept only a real bool, or an exact-match string from a small allow-list, and treat anything else as absent rather than as True. Failing closed is clearly correct for both fields — a missed resolution costs a stale open incident, while a false one silently closes a live one.

Not verified

No live data this run. It is unmeasured whether the model in use has ever actually emitted a non-boolean for either field. The defect is that nothing would catch it if it did, and nothing would show it had happened.

Refs #80, DEFERRED.md (severity ladder).

Found by the standing static correlation pass, unattended run 2026-08-30. Static reading only. Searched open and closed — not a duplicate of the closed #18, which is about incidents never recording `resolved_at`; this is about the extracted `resolved` flag being unvalidated on the way in. ## What happens `intelligence.py:275-276` coerces both fields with a bare `bool()`. There is no allow-list guard of the kind `_VALID_INCIDENT_TYPES` already provides for incident type. Because a non-empty string is truthy in Python, a model returning the JSON **string** `"false"` — rather than the boolean `false` — is read as **True**. These values come straight from an LLM, so the type is a prompt convention, not a guarantee. ## Consequences **`resolved` truthy** at `routers/upload.py:342-348` writes `status: resolved` onto whatever incident the scene **linked into**. On a scene that linked into a long pre-existing incident chain it has no real claim to, that closes someone else's incident — and it then cascades through `maybe_resolve_parent`. **`reassignment` truthy** blanks units at `routers/upload.py:324` and changes which fit path the call takes. This is the same hazard class `DEFERRED.md` already records for the severity ladder, now on two newer fields that never got the same treatment. ## Fix direction Validate before coercion: accept only a real `bool`, or an exact-match string from a small allow-list, and treat anything else as absent rather than as True. Failing closed is clearly correct for both fields — a missed resolution costs a stale open incident, while a false one silently closes a live one. ## Not verified No live data this run. It is unmeasured whether the model in use has ever actually emitted a non-boolean for either field. The defect is that nothing would catch it if it did, and nothing would show it had happened. Refs #80, DEFERRED.md (severity ladder).

logan commented

2026-08-31 02:45:53 -04:00

Additional finding at 29c2fb1, static correlation pass, unattended run 2026-08-31. Folding into this issue rather than forking it, since it is the same invariant failing.

The bool()-coercion problem this issue describes has a consequence worse than a bad flag value: the resolved write is not gated on how the scene linked.

upload.py:227-233 and :342-348 act on resolved regardless of the correlation path that produced the link. A scene that attached to an incident via the fast/thin recency path - on recency alone, with no location match and no content match - can still carry resolved=true and close that incident.

So a thin, weakly-attached scene can resolve an incident it was never really part of. The incident stops accepting calls and drops out of the active set while the real event is still running on the air.

Suggested scope, in order:

Validate resolved and reassignment as actual booleans at the extraction boundary rather than trusting the prompt (this issue's original scope).
Gate the resolved action on the link path - do not honour a resolve that arrived via a fast/thin attach. A resolve should require a link the correlator was actually confident about.

Note that both upload.py and intelligence.py are entirely untested. The existing drb-c2-core suite covers only the gate, dedup and identity paths of incident_correlator.py, so any fix here needs its test written from scratch, and that is most of the work.

**Additional finding at `29c2fb1`, static correlation pass, unattended run 2026-08-31.** Folding into this issue rather than forking it, since it is the same invariant failing. The `bool()`-coercion problem this issue describes has a consequence worse than a bad flag value: **the `resolved` write is not gated on *how* the scene linked.** `upload.py:227-233` and `:342-348` act on `resolved` regardless of the correlation path that produced the link. A scene that attached to an incident via the **`fast/thin` recency path** - on recency alone, with no location match and no content match - can still carry `resolved=true` and close that incident. So a thin, weakly-attached scene can resolve an incident it was never really part of. The incident stops accepting calls and drops out of the active set while the real event is still running on the air. **Suggested scope, in order:** 1. Validate `resolved` and `reassignment` as actual booleans at the extraction boundary rather than trusting the prompt (this issue's original scope). 2. **Gate the `resolved` action on the link path** - do not honour a resolve that arrived via a `fast/thin` attach. A resolve should require a link the correlator was actually confident about. Note that both `upload.py` and `intelligence.py` are **entirely untested**. The existing `drb-c2-core` suite covers only the gate, dedup and identity paths of `incident_correlator.py`, so any fix here needs its test written from scratch, and that is most of the work.

logan referenced this issue

2026-09-20 14:33:01 -04:00

Incidents never actually clear — units_cleared almost never populates, 90-min idle sweep does the resolving instead #155

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: logan/server-26#88

resolved and reassignment are prompt-only invariants with no validator, so a string "false" resolves an incident #88

What happens

Consequences

Fix direction

Not verified

`resolved` and `reassignment` are prompt-only invariants with no validator, so a string "false" resolves an incident #88