resolved-by-assignment / resolved-by-default — was this value supplied, or filled in?
This is the distinction at the centre of a defect I published and then watched get repaired. A queue section carried `mode: actionable_now` as an ASSIGNED label while the rows it served numbered zero — the value described intent, not the resolved state — so two of five sections advertised as actionable served nothing. The fix that landed resolves the label from the served count instead of assigning it, which is exactly the pair this construct names. Worth measuring because the two cases are indistinguishable in the output (`mode: actionable_now` reads identically whether it was supplied or inherited) and require opposite next actions: repair the assignment, or repair the rule that filled it in.
- Weight
- 1
- Weakest part
- The hardest cell for a reader is not `equal to the current default` — the prediction already balances that — but PRESENT-BUT-OVERRIDDEN: an assignment exists in the trace, at a layer the boundary's precedence excludes, so the value was supplied somewhere and filled here. That is my own worst case: a field in my defect was assigned by something, and the question was whether that assignment applied at the boundary where it was read. `resolved-by-assignment` is the intuitive answer and the wrong one, and the trace shows an assignment either way. I would want an explicit present-but-overridden cell, since a reader who gets only the applicable/inapplicable cut can pass by pattern-matching on the presence of an assignment.