The question
Should a case an operator has already picked up (IN_PROGRESS) still be targeted by automated outreach, and still be the case attached to an MCP compliance answer?
This is a product decision, not a bug. It is filed so the inconsistency is tracked rather than left in a journal entry.
Why it comes up now
#551 widened the open-case readers to ACTIVE_CASE_STATUSES (OPEN + IN_PROGRESS), because the work list, its CSV export and the MCP list tools disagreed with each other: a case moved to IN_PROGRESS stayed on screen and vanished from the CSV taken off that screen.
Two readers were deliberately left on OPEN only, because neither is the work list and widening them would change behaviour nobody asked for:
backend-ts/src/case/outreach-campaign.ts — campaign targetingbackend-ts/src/mcp/tools.ts — the open case attached to a get_compliance_status answer
Recorded in docs/DATA_MODEL_CONTRACTS.md §4.
The two readings
Leave as-is (OPEN only). Someone has already started work on the case — a scheduled appointment is the usual reason it is IN_PROGRESS. Sending an automated letter on top of that is duplicate contact, and the patient hears from the practice twice about the same gap.
Widen to ACTIVE. ACTIVE_CASE_STATUSES is the contract's own definition of an active case, and every other surface now uses it. A case sitting IN_PROGRESS for six weeks because an appointment was booked and missed receives nothing at all under the current behaviour.
A third option: widen, but exclude cases with a future appointment — which is a real distinction the appointment store can already answer, and more work than either of the above.
Deciding it
Whichever way it goes, the outcome belongs in DATA_MODEL_CONTRACTS §4 next to the note that records the current split, so the next person to widen a status set knows these two were considered rather than missed.
Context: #551, docs/JOURNAL.md 2026-09-12.
The question
Should a case an operator has already picked up (
IN_PROGRESS) still be targeted by automated outreach, and still be the case attached to an MCP compliance answer?This is a product decision, not a bug. It is filed so the inconsistency is tracked rather than left in a journal entry.
Why it comes up now
#551 widened the open-case readers to
ACTIVE_CASE_STATUSES(OPEN+IN_PROGRESS), because the work list, its CSV export and the MCP list tools disagreed with each other: a case moved toIN_PROGRESSstayed on screen and vanished from the CSV taken off that screen.Two readers were deliberately left on
OPENonly, because neither is the work list and widening them would change behaviour nobody asked for:backend-ts/src/case/outreach-campaign.ts— campaign targetingbackend-ts/src/mcp/tools.ts— the open case attached to aget_compliance_statusanswerRecorded in
docs/DATA_MODEL_CONTRACTS.md§4.The two readings
Leave as-is (OPEN only). Someone has already started work on the case — a scheduled appointment is the usual reason it is
IN_PROGRESS. Sending an automated letter on top of that is duplicate contact, and the patient hears from the practice twice about the same gap.Widen to ACTIVE.
ACTIVE_CASE_STATUSESis the contract's own definition of an active case, and every other surface now uses it. A case sittingIN_PROGRESSfor six weeks because an appointment was booked and missed receives nothing at all under the current behaviour.A third option: widen, but exclude cases with a future appointment — which is a real distinction the appointment store can already answer, and more work than either of the above.
Deciding it
Whichever way it goes, the outcome belongs in
DATA_MODEL_CONTRACTS§4 next to the note that records the current split, so the next person to widen a status set knows these two were considered rather than missed.Context: #551,
docs/JOURNAL.md2026-09-12.