pattern playground

Problem-curated view

Added

The actor keeps returning to the same data with one question: what needs my attention, and why? The domain can answer some of it in advance — there is consensus about what counts as a problem (e.g. a rule/policy violation) — yet a general view leaves the actor to re-derive those judgements by inference on every visit. A problem-curated view organises what is shown around the detected problems instead of the data types: a checklist of candidate problems, each backed by an explicit rule. It is case of a purpose-keyed view taken to its limit.

Anatomy

The checklist is the interface. Each entry is a detected problem; the list doubles as index, navigation, status display, and audit trail. Selecting a problem filters the collection to the relevant slice, magnified and annotated with why it was flagged — the provenance is explicit, so the view can always say why it looks the way it does, and the reason moves with the actor from noticing into investigating.

Detection rules over the collection as a checklist. Selecting a flag prunes the view to its slice with the reason attached; the full catalogue stays one action away, and every flag carries a not-useful control.

Commitments

  • Annotate the judgement moment. Flags belong where judgement is already being exercised — the review, the rounds, the scheduled check — and stay out of exploration, where they pre-empt the very judgement they are meant to support. The lesson is empirical: the same detection rules failed as ambient dashboards and succeeded attached to code review. Showing flags only when guidance is solicited is one honest implementation; the rule is the moment, not the request.
  • Keep the escape hatch structural. The general exploratory view stays reachable alongside the curated one — required, not optional. Rules never capture the whole judgement: even where they are possible, the ground truth behind them is partly heuristic, so there is always a remainder they don’t encode. The escape hatch is where the remainder gets noticed — and where the next rule is usually discovered.
  • Watch the framing. The same checklist reads as scaffolding when it teaches what to look for, and as fossilised process when it caps what anyone looks for.

Resources & references

Consequences

  • what needs attention arrives as a rule-backed checklist — index, navigation, status display and audit trail at once — and every flag can say why it fired
  • the rule set is a standing maintenance duty — to its reader a false positive is any flag they did not want to see, so flags need a feedback channel and a noise budget, or the curve is alarm fatigue, then suppression: the checklist still renders after trust has left it
  • whatever the rules don't encode sails past; the general exploratory view remains the place to notice it

Related patterns

Instantiates

  • Purpose-keyed view — problem-curated view takes the design-time keying to its limit: the advance decision about what matters made explicit as detection rules, spanning the watch and the chase

Serves

  • Assistance — perceiving — problem-curated view's detection rules do the noticing and carry their reasons; judgement and action stay with the actor, which is where next-best-action systems would pick up

Enacts

  • Adaptability — the view, not the content, responds — the framing shifts with what the detection rules find, before the actor selects anything