Fallback Mode Register¶
Document — instantiates Decision-Procedure Boundary Mapping
A living ledger of every case the procedure cannot cleanly decide, paired with the named fallback it is routed to — bounded search, heuristic, semi-decision, approximation, human review, or scope renegotiation.
The register is the governed record of what happens at the boundary — every class of case that falls outside the clean decision procedure, paired with the explicit fallback mode it is sent to and the reason. Where the triage worksheet declares that a fallback is needed, the register operates it: it names each fallback route, keeps timeout, unknown, unsupported, and out-of-scope as distinct entries rather than letting them collapse into no, and keeps the boundary auditable over time as new open cases appear. Its defining property is that no case ever leaves the system by an unnamed default.
Example¶
A hospital deploys software that reads chest X-rays and returns normal or refer. Everyone focuses on those two answers; the fallback mode register is about everything that is neither. It lists the routes explicitly: images below a quality threshold go to unusable, retake — never silently normal; confidence in the ambiguous mid-band goes to low-confidence, radiologist review; anatomy outside the trained distribution (pediatric films, post-surgical hardware) goes to out-of-scope, radiologist; a model timeout under load goes to timeout, queue for review — never defaulted to normal. Each entry names its trigger, its destination, and its owner. When a new failure class appears — say, a novel implant that confuses the model — it becomes a new register line with its own route, instead of a silent misread. The register is what keeps "the software did not decide this" from ever quietly becoming "the software said it was fine."
How it works¶
It is a maintained ledger, one row per boundary case-class.
- Enumerate the fallback modes in use — bounded search, heuristic, semi-decision, approximation, human review, scope renegotiation.
- For each boundary case-class, record its trigger condition, assigned mode, owner, and the distinct output label it produces.
- Keep the labels distinct —
timeout≠unknown≠unsupported≠out-of-scope≠false. - Grow and prune the register as new open cases surface and as a better procedure absorbs old ones.
- Report boundary volume so the split between decided and deferred is visible rather than hidden.
Tuning parameters¶
- Mode palette — how many distinct fallback modes are offered versus one catch-all "review." More modes route more precisely but cost governance overhead.
- Boundary sensitivity — how readily a case is pushed to fallback versus forced to a yes/no. Conservative routing is safer but floods the review queue.
- Default posture — what an unclassified case does before it earns its own register line (deny, defer, escalate). It sets the fail-safe stance.
- Owner assignment — whether each route has a named human or team accountable for it, or falls to an anonymous shared queue.
- Review cadence — how often the register is revisited to promote recurring fallbacks into the decision procedure or to split an overloaded route.
When it helps, and when it misleads¶
Its strength is that it makes the boundary honest and operable — the difference between a system that admits "I cannot decide this, here is who does" and one that emits a confident wrong answer. It is also where fail-safe defaults[n1] actually live: an unhandled case lands on a safe, explicit state instead of a convenient guess. The failure mode is the register as a junk drawer — a single "everything else → review" line that hides genuinely different problems and grows unchecked until the review queue is the real system. The classic misuse is the invariant this whole archetype warns against: letting a timeout be recorded, and then treated downstream, as a no — a silent recoding that turns "could not decide" into a false decision. The guarding discipline: keep each fallback mode and each output label distinct and named, put an owner on every route, and periodically ask which recurring fallbacks have become common enough to deserve promotion into the decision procedure proper.
How it implements the components¶
fallback_resolution_policy— it is the operational policy: each boundary case-class mapped to a named fallback mode, with a trigger and an owner.undecidability_or_open_case_marker— it records and holds distinct the open, undecidable, out-of-scope, and timeout cases as first-class entries, never collapsing them intofalse.
It neither frames the original scope and predicate (the Decidability Triage Worksheet) nor specifies or verifies the clean procedure itself (the Decision-Procedure Specification and Termination & Totality Proof Review); it governs only what happens to the cases those leave behind.
Related¶
- Instantiates: Decision-Procedure Boundary Mapping — the register is the mechanism that keeps the un-decided cases governed rather than hidden.
- Consumes: Decidability Triage Worksheet and Reduction Boundary Map — the branches the worksheet routes to fallback and the cases the map marks undecidable or infeasible are exactly what the register records and governs.
- Sibling mechanisms: Decidability Triage Worksheet · Decision-Procedure Specification · Termination & Totality Proof Review · Reduction Boundary Map
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Fallback Mode Register operates as a durable record, ledger, register, or trace whose value depends on preserving actual state or history because it a living ledger of every case the procedure cannot cleanly decide, paired with the named fallback it is routed to — bounded search, heuristic, semi-decision, approximation, human review, or scope renegotiation.
Independent corroboration: The frozen evidence defines Fallback Mode Register as 'A living ledger of every case the procedure cannot cleanly decide, paired with the named fallback it is routed to — bounded search, heuristic, semi-decision, approximation, human review, or scope renegotiation', so its operative form is Record, Log & Register.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Cataloguing undecidable or intractable cases with exact, approximate, bounded, or human fallbacks arises from computability-aware software design.
Related originating lineages:
- Mathematics — Decision problems, semi-decision procedures, and approximation boundaries materially shape the fallback taxonomy.
- Philosophy — Logic and philosophy of mathematics materially supply distinctions among decision, semi-decision, and undecidability.
Review resolution: Both reviewers agree that computer_science is primary. I retain philosophy, mathematics only as formative origin lineages; cross_disciplinary_synthesis is appropriate because the final form materially combines the agreed primary with the retained formative lineages. Reach is multi_domain because the structure transfers across several fields but is not a near-universal human pattern, an applicability judgment kept separate from provenance. Encyclopedia synthesis is true because the exact generalized artifact is an encyclopedia-authored combination or refinement. No unresolved historical ambiguity remains after reconciling the secondary fields.
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¶
A healthy register shrinks over time, or at least churns: the point of reviewing it is to notice which fallback routes have grown common enough to justify extending the decision procedure to cover them. Treated that way, the register is a running to-do list for the procedure, not a permanent parking lot — a growing "everything else" line is a symptom, not a steady state.
[n1] Fail-safe defaults — one of Saltzer and Schroeder's classic protection-design principles: base decisions on explicit permission and default to a safe, denying, or explicitly-flagged state when in doubt, rather than to an implicit "allow." In a decision procedure it means an unresolved case must land on a declared fallback (unknown, review, retake), never on a silent yes or no. ↩