Domain heuristics should be induced from the domain’s real problem base, not generic entries reworded

What it is

Domain entries should come from interface-related failures that recur across incident reports, audit findings, tickets, field observation, and expert debriefs. Simply rewording "feedback" or "consistency" into the industry's own vocabulary produces no new checking power. Inductive heuristic building requires abstracting a triggering condition, an interface cue, and a judgment criterion from concrete cases. This card follows directly from "generic heuristics miss domain-specific failure modes": that card explained why extra entries are needed; this one explains where they should come from — real cases, not a wording exercise.

Why it happens

Rewording "offer informative feedback" into "offer informative patient-status feedback" looks like a new domain entry, but it is only a noun swap, and an evaluator using it will catch nothing a generic entry could not already catch. This kind of rewording fails because it introduces no new structural information: what a generic entry is genuinely missing is knowledge specific to how the domain actually operates — which data must be visible simultaneously in this field, which sequence is locked in by regulation, which automated step obscures accountability, which combination of states produces a dangerous ambiguity — and none of that knowledge can be conjured by prefixing a generic term. A real problem base works precisely because it exposes this structure directly: induction starts by clustering similar historical cases, then comparing exactly which interface detail separated a path that was ultimately avoided from a path that ultimately led to an incident, and writing that specific difference up as an entry — which naturally carries a testable trigger condition and interface cue, rather than a professional-sounding platitude.

Where it stops holding

A problem base has its own bias: problems that get actively reported are not necessarily the most important ones, and certain long-unrecorded failure modes are absent from the problem base for the very reason that they were never recorded — a checklist built solely from historical tickets and incident reports will naturally over-index on problems that are frequently complained about but low-impact, and stay blind to problems that are high-impact but rare and not yet documented. This requires domain experts to actively supply potential risks and near-misses (situations that almost caused an incident but were caught in time) to correct that bias. The induction process also should not copy every detail of a specific case wholesale: if an entry is stuffed with all the background of one particular incident, it will only match that one incident and fail to recognize variants of the same underlying problem. An entry needs to retain a generalizable judgment condition, with the specific case demoted to a supporting positive or negative example rather than serving as the entry's own definition.

Applying it

• When collecting the problem base, do not rely solely on formally reported incidents; actively include near-misses, concerns frontline experts raise informally, and the workaround habits users develop to route around a known flaw — these often surface the real risk earlier than a formal ticket does.
• Cluster cases by triggering object, interface location, the key cue that was missing at the time, and the actual consequence, and induce one candidate entry per cluster rather than writing a separate entry for every individual case.
• Attach to each candidate entry a real positive example (a scenario that should have been caught but was not), a negative example (a scenario that looks similar on the surface but does not actually belong to this problem), the applicable role, and the evidence source, so the entry carries a verifiable boundary from the start.
• How to check: have a frontline expert who did not write the entry use it to retroactively check the original case set, confirming it catches both the original case the entry was based on and reasonable variants of that case — an entry that only catches the original case was drawn too narrowly and needs re-induction.

Related

• Same group: B3.20.1 Generic heuristics miss domain-specific failure modes and require additional entries · B3.20.3 A qualified entry must let two evaluators independently reach the same conclusion · B3.20.4 Domain heuristics need retrospective testing against known problems; untested entries should not ship
• Nearby: Y3 Error Prevention and Recovery · Q4 Research Methods and Evaluation
• Search terms: incident analysis · domain heuristics · grounded checklist · near miss