Decision Procedure Boundary Mapping

Map whether a yes/no question can be decided by a finite total procedure before promising automation, certainty, or universal adjudication.

Overview

Decision-Procedure Boundary Mapping asks whether a yes/no question can honestly be answered by a finite, terminating, correct procedure. It is the practical counterpart of decidability and computability: before promising automation, universal adjudication, or procedural certainty, define the input class, predicate, termination guarantee, correctness warrant, feasibility bound, and fallback states.

The archetype is useful whenever a question sounds decidable but may actually be underspecified, open-ended, infeasible, semi-decidable, or dependent on human judgment. It prevents systems from disguising timeout, unknown, unsupported, or out-of-scope cases as ordinary yes/no answers.

Core pattern

1. Define the class of questions, not only one case.
2. Define the input encoding and the yes/no predicate.
3. Check whether a procedure can halt with a correct answer for every in-scope input.
4. Separate theoretical decidability from practical feasibility.
5. Specify a total procedure where warranted.
6. Declare fallback modes where total decision is unavailable or inappropriate.

Key components

The question-class scope defines what is being promised. The input encoding contract defines what the procedure can read. The decision predicate defines what true and false mean. The termination guarantee prevents infinite search or hidden loops. The correctness warrant prevents a merely terminating script from being mistaken for a valid decision procedure. Complexity and feasibility bounds prevent “decidable in principle” from becoming “usable in production.” Fallback policies preserve unknown, timeout, unsupported, and review states.

Common mechanisms

A decidability triage worksheet works during design. A decision-procedure specification works when the procedure will be implemented or contracted. A termination and totality proof review works in formal or high-assurance contexts. A reduction boundary map compares a question to known decidable or undecidable classes. A fallback mode register governs bounded search, approximation, manual review, and deferral.

Parameter dimensions

Important parameters include size of the input class, precision of the predicate, formal versus contractual warrant, termination proof strength, complexity bounds, acceptable error, reversibility of wrong decisions, decision stakes, and fallback latency.

Invariants to preserve

Do not conflate termination with correctness. Do not conflate timeout with no. Do not let out-of-scope become false. Do not hide human judgment behind the appearance of computation. Do not promise a total decision procedure without both a termination and correctness warrant.

Target outcomes

Good use produces honest automation boundaries, clearer API and contract semantics, safer handling of edge cases, fewer hidden loops and arbitrary defaults, better distinction between exact decision and approximation, and more auditable routing between procedure, fallback, and review.

Neighbor distinctions

This is not only termination-condition design. A stop rule may end a process, but decidability requires stopping with the correct yes/no answer for every in-scope input.

This is not only bounded approximation. Approximation is a fallback when exact total decision is infeasible or unnecessary.

This is not complete enumeration, although finite enumeration can implement a decidable boundary.

This is not a generic algorithm-design pattern. The key question is whether the promised class of decisions admits a total correct procedure at all.

Examples

• A static analyzer states the restricted language subset and property class it can decide, then routes unsupported constructs to review.
• An eligibility policy defines accepted evidence packages and preserves appeal for nonstandard cases.
• An API returns unknown, timeout, and unsupported separately from false.
• A moderation system automatically decides clear cases and routes context-dependent cases to human reviewers.
• An optimizer marks exact search as decidable but infeasible and switches to bounded approximation with stated limits.

Non-examples

• A review process merely has a deadline.
• A finite inventory is counted completely.
• A model returns a probability score and is explicitly treated as approximate.
• A committee intentionally makes contextual value judgments.
• A script terminates but lacks a specified predicate or correctness warrant.

Failure modes

The common failures are false totality promises, predicate drift, timeout recoded as a negative answer, ambiguous input encoding, confusing theoretical decidability with practical feasibility, and laundering normative judgment as computation.

Review note

This draft is justified because decidability_computability has zero reported coverage and existing neighbors cover termination, approximation, enumeration, and regress closure rather than the boundary between total decision procedures and fallback modes.

Common Mechanisms

• Decidability Triage Worksheet
• Decision Procedure Specification
• Fallback Mode Register
• Reduction Boundary Map
• Termination and Totality Proof Review

Compression statement

Decision-Procedure Boundary Mapping applies when someone wants a reliable answer to every instance of a yes/no question class. The intervention separates the problem statement from the procedure promise: define the question class, input encoding, predicate, termination guarantee, correctness warrant, and feasibility bound. If a total decision procedure exists and is practical, specify it. If the question is underspecified, open-ended, undecidable, computationally infeasible, or only semi-decidable, redraw the boundary and declare an explicit fallback such as bounded search, approximation, human review, contract narrowing, monitoring, or defer-for-research.

Canonical formula: For question class Q over inputs I, decide only if there exists procedure P such that for every i in I, P(i) halts and returns the correct truth value for predicate q(i); otherwise narrow I/q or route to a declared fallback mode.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (9)

• Algorithm: Step-by-step problem-solving procedure.
• Computability: The in-principle boundary between problems an effective procedure can solve and those none can.
• Consistency: A set of commitments cannot jointly derive a contradiction.
• Contract: A multi-party bundle of obligations, breach criteria, and remedies under an accepted enforcement regime.
• Decidability Computability: A class of yes/no questions admits a finite procedure that always terminates with the correct answer.
• Formal System: Symbols, formation rules, axioms, and inference rules closed under mechanical derivation.
• Predicate: A testable yes-or-no property of an object, returning a truth value.
• Termination Condition: An explicit, checkable predicate that decides whether an iterative or recursive process stops or continues.
• Underspecification: A selection process treats evidence as if it picked out a single answer when many distinct answers fit it equally well, so a hidden closure silently chooses one representative and the behavior that distinguishes them is left uncontrolled.

Also references 18 related abstractions

• Anna Karenina Principle: Success requires every one of a set of necessary conditions to hold at once while failure follows from the absence of any single one, so successes look alike, failures look idiosyncratic, and the system is gated by its weakest unsatisfied condition.
• Axiom: A claim a system declines to derive — a load-bearing starting point accepted without proof so that the rest of the structure can be built on top of it.
• Bounded Rationality: Limited decision capacity.
• Boundedness: Values remain within limits.
• Closure: Ensures operations remain within a set.
• Complete Enumeration: A programmatic commitment to map every unit of a defined population, where completeness itself is the load-bearing property that unlocks inferences sampling cannot.
• Completeness: No gaps in structure.
• Complexity (Time/Space): Resource scaling with input size.
• Constraint: Limits possibilities to guide outcomes.
• Decision: Committing to one alternative from a set under uncertainty and trade-off, collapsing open deliberation into a chosen path and foreclosing the others.

▸ Show 8 more

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Finite-Domain Decision Table · subtype · recognized

Makes a question decidable by bounding the input class to a finite table of cases and outcomes.

• Distinct from parent: The parent also covers infinite, formal, infeasible, and fallback cases.
• Use when: The input domain is finite or can be made finite by contract; Exhaustive enumeration is practical.
• Typical domains: compliance, contract design, workflow governance
• Common mechanisms: decision procedure specification

Semi-Decision with Timeout Fallback · risk or failure variant · recognized

Uses a procedure that may find positive witnesses while routing nontermination, timeout, or unknown cases to a declared fallback.

• Distinct from parent: The parent includes total decision procedures; this variant is explicitly non-total.
• Use when: A positive answer can be witnessed but a total no answer is unavailable or infeasible; Timeouts must not be recoded as no.
• Typical domains: formal methods, AI governance, search workflows
• Common mechanisms: fallback mode register, decidability triage worksheet

Contractual Decidability Narrowing · governance variant · recognized

Makes an otherwise open judgment decidable by narrowing inputs, evidence, definitions, and authority in a contract or policy.

• Distinct from parent: The parent includes mathematical and computational cases beyond contracts.
• Use when: Parties need a finite operational rule rather than an open-ended standard; The narrowed convention is disclosed and appealable.
• Typical domains: policy design, contract design, compliance
• Common mechanisms: decision procedure specification, fallback mode register

Infeasible-but-Decidable Routing · scale variant · recognized

Separates theoretical decidability from practical infeasibility and routes the case to bounded approximation, resource escalation, or deferral.

• Distinct from parent: The parent classifies all boundary states; this variant names one boundary state.
• Use when: A correct terminating procedure exists in principle; Operational time, space, cost, or deadline constraints make it unusable.
• Typical domains: operations research, optimization, verification
• Common mechanisms: fallback mode register, reduction boundary map

Near names: Halting-Problem Awareness, Decidability Triage, Decision Procedure Framing.