Where the six states fail

Every honest description of a mechanism should include the part where it stops working. This is that page for task states. None of what follows is a reason to abandon the model: a shared list with an owner against each line still beats six people remembering different versions of the same conversation. But a household that knows the five gaps below will spot them in a week. A household that does not will assume the board is telling the whole story.

Five places the model breaks

1. Completed records the action, not the result

   Somebody rings the county office, is told an application has been sent out, and marks the task finished. That is accurate: the call was made. The parent still has nobody coming to the house. A task state tracks motion, and motion is not the same as the problem being solved. The repair is in how the task is written, not in the state: anything whose completion the household cannot observe should be rewritten until they can. Call the agency becomes get a start date in writing.

2. Not for us absorbs defeat as well as choice

   The neutral wording is deliberate and we would choose it again. It has a price. A task declined because it genuinely was not worth the family's time and a task declined because it was too hard to face look identical afterwards, and nobody ever finds out which happened. If three declined items all turn on the same difficult phone call to the same person, the pattern is real and the record cannot see it. We chose respect over diagnosis, which means saying out loud that the record means less than it appears to.

3. Waiting flattens two very different things

   An eligibility determination sitting with an agency and a brother who has not rung back are both blocked. One resolves on an administrative clock that nobody in the family controls. The other resolves the moment a specific person decides to act. Treated as one state, the first gets chased pointlessly and the second gets excused indefinitely, which is exactly the wrong way round. Naming the blocker helps only if it also names whether the blocker has a human owner.

4. A plan ends. Some obligations repeat

   Supplies to reorder, a prescription to refill, an annual redetermination to file again next year. Marked finished in March and quietly untrue by April, with the plan closed and nobody watching. A plan with an end date cannot hold a recurring obligation honestly, and a tool that pretends otherwise fails on the day it matters. This is the boundary where follow-through stops and ongoing coordination starts, and it is a boundary rather than a bug.

5. The board is only as true as the last person who touched it

   Silence looks the same whether everything is fine, everything has stalled, or the family moved the whole conversation to a group chat three weeks ago. A state model has no way to tell those apart, and the most common failure of any care coordination tool is not a wrong state. It is a page nobody opened. This is why a state shown without the date a person last confirmed it is a claim with no date attached.

What actually helps

Write the observable outcome into the task rather than the effort. Name the blocker and say whether a person or a queue is holding it. Put a last confirmed date next to any state that has not moved. And accept that a repeating need does not belong on a finite plan, so it has to be handed somewhere before the plan closes rather than after.

None of that makes the six states describe everything. It makes the gaps visible to the family instead of visible only to whoever built the thing, and that is the version worth publishing.

Last reviewed 14 August 2026