Unknown-State Routing Rule¶
Indeterminate routing rule — instantiates Predicate Criterion Formalization
Separates 'cannot decide' from 'false' and routes each indeterminate case to the right resolution path rather than silently failing it.
An Unknown-State Routing Rule is the machinery that catches the cases a predicate cannot honestly decide and sorts them — separating unknown, not applicable, and needs review from a plain false — then sends each to the resolution path it deserves. Its defining insistence is that "cannot decide" is not "no": missing, stale, conflicting, or out-of-domain evidence must not silently collapse into a failed test. It fixes who bears the burden of resolving an indeterminate case and to what standard, and it provides the escalation or appeal path by which an unresolved case reaches a human, a retest, or a fallback — rather than being scored as false and forgotten.
Example¶
A clinical lab runs a screening assay whose predicate is "positive / negative." A patient's sample comes back in the assay's equivocal band — an optical density between the negative and positive cutoffs — where the test genuinely cannot decide. A naive system would round the equivocal reading down to "negative" and send the patient home; the unknown-state routing rule refuses that collapse. It classifies the result as INDETERMINATE, distinct from negative, and routes it: the burden to resolve falls on a defined follow-up (a repeat draw and a confirmatory assay), the standard for closing the case is stated, and an escalation path sends persistently equivocal results to a clinical pathologist rather than looping retests forever.
A separate "not applicable" branch handles samples that were hemolyzed or fell outside the assay's validated domain — those aren't unknown, they are untestable, and route to re-collection. Setup to outcome: the dangerous shortcut of treating "we couldn't tell" as "nothing's wrong" is replaced by a defined path for each kind of not-decidable case.
How it works¶
- Separate the not-true states. Distinguish false, unknown, not-applicable, and needs-review as different outcomes, because their consequences and remedies differ.
- Assign burden and standard to each. State who must act to resolve an indeterminate case and what closes it, so it neither sits forever nor collapses to false.
- Route each to its path. Unknown → gather more evidence or retest; not-applicable → redirect out of domain; needs-review → human escalation.
- Provide a terminus. A case that resists resolution reaches a defined authority or fallback rather than cycling indefinitely.
Tuning parameters¶
- State granularity — how many not-true states you distinguish (just unknown, versus unknown / NA / review / stale). More states route more precisely but add handling complexity.
- Default routing posture — whether unresolved cases default toward caution (review) or throughput (provisional pass). This sets the safety-versus-latency trade.
- Burden placement — who must supply the missing evidence (subject, system, reviewer) and the deadline before escalation.
- Escalation depth — how many resolution attempts before a case reaches a human or fallback; deeper saves reviewer load but delays resolution.
- Re-entry rule — whether a resolved indeterminate case re-enters the normal predicate or is decided by the reviewer.
When it helps, and when it misleads¶
Its strength is that it prevents the most common and dangerous predicate error — treating absence of evidence as evidence of the negative[n1] — and makes uncertainty an explicit, routed state with an owner rather than a silent rounding.
Its failure mode is routing that never terminates: cases bounce between "needs more evidence" and review with no closing rule, so the unknown pile grows without bound. The opposite misuse is a permissive default that lets indeterminate cases pass provisionally and then never get resolved. The discipline that guards against both is to give every indeterminate state a burden holder, a closing standard, and a terminal escalation, so "unknown" is a station on the way to a resolution, not a parking lot.
How it implements the components¶
indeterminate_case_policy— it is the explicit policy that keeps false, unknown, not-applicable, and review-needed as separate outcomes and defines what each means.confidence_and_burden_rule— it assigns who must resolve an indeterminate case and the standard that closes it, so uncertainty has an owner rather than a silent default.appeal_or_override_path— it supplies the escalation or appeal terminus a stuck case reaches, so no unknown loops forever.
It does NOT render the primary true/false verdict or say what evidence establishes the property — the deciding truth_evaluation_logic at a control point is Boolean Guard Clause and the per-item evidence_basis_rule is Eligibility Criteria Checklist; this rule takes over only where those cannot honestly decide.
Related¶
- Instantiates: Predicate Criterion Formalization — the routing rule is the indeterminate-handling instance, governing what happens when the predicate cannot decide.
- Sibling mechanisms: Boolean Guard Clause · SQL WHERE Clause or Query Filter · Truth Table · Decision Table · Eligibility Criteria Checklist · Policy Definition of Terms · Predicate Version Registry · Test Case Matrix · Counterexample Register
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Unknown State Routing Rule is defined in the frozen evidence as: Separates 'cannot decide' from 'false' and routes each indeterminate case to the right resolution path rather than silently failing it. Its operative deployed or enacted form is therefore Control, Automation & Runtime.
Nearest alternative: Rule, Policy & Commitment — Rule, Policy & Commitment can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: PostgreSQL Documentation: Comparison Functions and Operators documents that three-valued logic routes NULL or unknown comparisons separately from true and false. This is direct, mechanism-specific evidence for computer science as the best-evidenced historical home of the operation—Separates 'cannot decide' from 'false' and routes each indeterminate case to the right resolution path rather than silently failing it.—rather than evidence merely that the operation is useful there. The retained alternates record genuine adjacent lineages; later portability is represented separately by domain_reach=universal.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: separates 'cannot decide' from 'false' and routes each indeterminate case to the right resolution path rather than silently failing it.
- Operations Research — Operations Research supplies a historically relevant adjacent lineage or formative practice for the operation—Separates 'cannot decide' from 'false' and routes each indeterminate case to the right resolution path rather than silently failing it.—but the adjudicated evidence more directly locates the defining lineage in computer science.
- Organizational & Management Science — Organizational management's workflow, review, staffing, and coordination tradition contributes a separate formative lineage to the mechanism's unknown state routing rule logic.
Review resolution: The blind reviewers disagree on primary lineage (operations_research versus computer_science). The defining operation is: Separates 'cannot decide' from 'false' and routes each indeterminate case to the right resolution path rather than silently failing it. The researched PostgreSQL Documentation: Comparison Functions and Operators establishes that three-valued logic routes NULL or unknown comparisons separately from true and false. That source therefore supports computer science as the historical origin. operations research remains in the uncapped alternates where it contributes a formative practice, but application or governance is not itself proof of origin. origin_mode=single_lineage records lineage construction; domain_reach=universal separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The unknown-state routing rule is where a predicate stops pretending it is total. A guard clause treats "cannot evaluate" as a single fail-closed stop; this rule instead asks why it can't evaluate — missing, stale, out-of-domain, or conflicting evidence — and routes each differently. It is the natural home for the case that other mechanisms in this family only knew how to drop.
[n1] The maxim "absence of evidence is not evidence of absence" captures this mechanism's whole reason for being: a predicate that returns false when it simply lacked the evidence to evaluate has confused not shown true with shown false. Keeping the unknown state separate — and routed — is what prevents that confusion from silently deciding real cases. ↩