Heuristic Boundary Checklist¶
Checklist — instantiates Heuristic vs. Algorithm Tradeoff and Selection
Confirms whether a shortcut is valid in the current domain, population, feedback regime, and risk level.
A Heuristic Boundary Checklist is a pre-use gate applied to one specific shortcut. Before you let a rule of thumb decide a case, you run down a short list of conditions that define the envelope in which that shortcut was learned and validated — same domain and case type, same population, a feedback regime that would catch it drifting, and a risk level low enough that a shortcut is acceptable at all. If any condition fails, the shortcut is out of bounds and must not be used on this case. The one idea that makes it this mechanism is that it takes the heuristic as given and never chooses among methods: it doesn't ask "which method fits this decision?" — it asks "is this shortcut still standing on the ground it was validated on?" It is a validity check, not a selector.
Example¶
A consumer lender has a fast-track rule its credit officers trust: applicants with two-plus years at their current employer and a clean 24-month repayment history get an instant approve, no full underwriting. The lender expands into a new region and begins serving gig-economy applicants. Before applying the rule to this new population, an officer runs the boundary checklist. Domain: the rule was fit on salaried, stable-tenure borrowers — gig income is structurally different — fail. Population: thin credit files, unfamiliar region — fail. Feedback regime: do repayment signals come back fast enough to catch the rule going wrong here? only partially. Risk level: loan sizes in the new market are larger. Two clear failures, so the shortcut is declared out of bounds for gig applicants, and those cases route to full underwriting instead. The rule stays fast where it earned the right to be fast, and is switched off where it did not.
How it works¶
The checklist works by (1) naming the specific heuristic and, crucially, recording the conditions under which it was originally validated; (2) turning those conditions into a small set of pass/fail rows about the current case; (3) checking each row against the case at hand; and (4) treating any failed row as a stop — the shortcut is inadmissible and the case escalates to a more rigorous method. Its distinctive feature is that it is heuristic-keyed and binary per row: the output is not a score or a lane, but a yes/no on whether one shortcut may be trusted right now.
Tuning parameters¶
- Boundary condition count — how many envelope conditions to check; too few lets overreach through, too many makes the gate slow and encourages rubber-stamping.
- Failure strictness — whether any single failed row blocks the shortcut or only a majority does; strict any-fail protects against overreach but escalates more cases.
- Validation staleness limit — how old the original validation may be before the "was this recently confirmed?" row itself fails; short limits force re-mapping, long limits trust aging evidence.
- Waiver authority — who, if anyone, may override a failed row and use the shortcut anyway; loose waivers reopen the overreach the checklist exists to close.
When it helps, and when it misleads¶
Its strength is enforcing ecological rationality[n1] — the principle that a heuristic is only as good as its fit to the environment it operates in — so a shortcut that is genuinely excellent in its home domain is stopped at the border of a domain where it would quietly fail.
Its characteristic failure is that the boundary conditions themselves go stale: the envelope was mapped once, the world moved, and the checklist now certifies a shortcut against an out-of-date picture of where it works. A classic misuse is treating a pass as proof the shortcut is the best method here, when all a pass establishes is that the shortcut is admissible — not optimal. The guarding discipline is to date every validated condition and re-map the envelope periodically, and to keep the checklist's verdict framed as "safe to use," never "proven best."
How it implements the components¶
heuristic_validity_boundary— the checklist is the validity boundary made operational: its rows are the envelope conditions, and a failed row marks the case as outside them.error_consequence_profile— the risk-level row weighs whether a shortcut is acceptable at all given what a wrong answer would cost on this case.calibration_feedback_loop— the feedback-regime row asks whether the environment even provides a corrective signal that would keep the shortcut honest; without one, the shortcut can't be trusted to stay valid.
It does NOT classify the decision to pick a method class — that is the Decision Method Triage Matrix, which implements method_option_set and decision_context_profile. The matrix selects among methods; this checklist takes one heuristic as given and only asks whether it still holds.
Related¶
- Instantiates: Heuristic vs. Algorithm Tradeoff and Selection — the checklist enforces the archetype's "bounded heuristic use" invariant on a per-shortcut basis.
- Consumes: Model or Rule Card — the card documents the constraints and validated conditions the checklist tests against.
- Sibling mechanisms: Decision Method Triage Matrix · Stakes–Latency–Error Scorecard · Algorithmic Escalation Protocol · Shadow-Mode Method Comparison · Override and Exception Log · Retrospective Error Calibration Review · Model or Rule Card
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Heuristic Boundary Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it confirms whether a shortcut is valid in the current domain, population, feedback regime, and risk level
Independent corroboration: The frozen evidence defines Heuristic Boundary Checklist as 'Confirms whether a shortcut is valid in the current domain, population, feedback regime, and risk level', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Psychology
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: The mechanism operationalizes the ecological-rationality tradition in judgment and decision psychology: a heuristic's validity depends on environmental structure.
Related originating lineages:
- Behavioral Economics — Applied decision research developed prominent tests of when shortcuts produce systematic economic error or useful frugality.
- Cognitive Science — Bounded computational strategies and environment-matched cognition materially shape the heuristic-versus-algorithm framing.
Review resolution: Both reviewers independently assign psychology as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The final form materially composes methods or concepts from more than one formative domain. Its operational pattern is portable across essentially any subject domain. The encyclopedia entry makes that composition explicit.
Attribution caveat: The checklist itself is a new operationalization of a cross-field research program rather than a historically named instrument.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] Ecological rationality — the view that a heuristic's quality is not intrinsic but relative to the structure of the environment it is used in; a shortcut matched to its ecology can outperform a complex model, and the same shortcut moved to a mismatched environment can fail badly. The boundary checklist is the discipline that keeps a heuristic inside the ecology it was matched to. ↩