How Do You Know the Fix Actually Worked?
Fixed and not fixed is a false pair.
A quiet path can be quiet because it is healthy or because nobody walked down it, and pretending those are the same is how a regression comes back as a surprise.
Short answer
Merge is not the answer; runtime is. A task that came from a real incident should keep a state after it ships: watching production, quiet but not confirmed, verified fixed, or issue returned. Quiet deserves its own state, because a low-traffic path can be silent either because it is fixed or because nobody hit it.
What this covers
- The states are not verified yet, watching production, quiet but not confirmed, verified fixed, issue returned, and archived after healthy coverage.
- Quiet is deliberately its own state because a low-traffic path can be quiet either because it is fixed or because nobody hit it, and collapsing those two into fixed is always an optimistic guess.
- Verified fixed therefore means traffic went through the affected path without the issue returning, not that the room went silent.
- Issue returned reopens the ORIGINAL card with the evidence attached, so the second attempt starts from what the first one tried instead of arriving as a disconnected new report.
- Signals is runtime context rather than analytics: there are no users, sessions or funnels in the model, and it is opt-in per workspace with each instrumentation point approved individually.
Comparison
| State | What it means | What it does not mean |
|---|---|---|
| Watching production | The fix shipped and the events are being watched | That it worked |
| Quiet, not confirmed | Nothing came back, but not much went through either | Fixed |
| Verified fixed | Traffic passed through the path without the issue returning | That it can never regress |
| Issue returned | It came back, on the original card, with both occurrences attached | That a new investigation starts from zero |
Merging is a claim
A pull request that closes an incident says the problem is solved. It is a reasonable claim and it is still a claim, made by the person least able to be objective about it, at the moment they most want to be finished.
The thing that can actually answer is the runtime that reported the problem in the first place. It saw the failure; it is in a position to say whether it stopped seeing it.
Six states, because two are not enough
A card that came from Signals carries a runtime state that keeps moving after the work is merged. Not verified yet. Watching production, which is where a card sits while the answer is still being earned. Quiet but not confirmed. Verified fixed. Issue returned. Archived after healthy coverage.
The one that justifies the whole design is quiet. A low-traffic path can be quiet because the fix worked or because nobody walked down it that week, and those are not the same sentence. Most tools have two answers, fixed and not fixed, which forces a guess whenever traffic is thin, and the guess is always optimistic because nothing arriving looks exactly like success.
Separating them is what keeps verified worth something. When a card says verified fixed, it means traffic went through the affected path, not that the room went quiet.
Issue returned is the state that pays for the rest
Nobody wants to see it, and it is the reason the loop exists. A fix that regresses two weeks later normally arrives as a fresh report, disconnected from the work that was supposed to have solved it, and the team relearns the problem from the beginning.
Here the original card reopens. The first attempt, the context it ran with, and the runtime evidence from both occurrences sit in one place, so the second attempt starts from what the first one tried rather than from an empty page.
On the board it is a small chip beside the Signals badge with the time it last changed. It is a status, not a notification: nothing interrupts you to say a card is still being watched.
This is context, not analytics
It is worth being precise about what Signals is, because the shape looks familiar. There are no users, sessions or funnels in the model. It does not measure engagement and it is not a product analytics tool that happens to log errors.
It links runtime events back to the code, the rules and the tasks they touch, so that the next agent working in that area knows what the product actually did there. It is opt-in per workspace and propose-first: a read-only scan suggests instrumentation points and only the ones you approve are wired in.
The [runtime verification documentation](/docs/signals/runtime-verification) covers the six states, and [how the loop works](/docs/signals/how-it-works) covers the path from event to task.