Decidability Triage Worksheet¶
Checklist — instantiates Decision-Procedure Boundary Mapping
Walks a team, at design time, through the questions that reveal whether a yes/no problem can be a real decision procedure — and where it can't, routes it to a declared fallback.
The worksheet is the front door. It is a short, ordered set of prompts a team fills in before anyone writes code, forcing the vague promise "the system will just decide this" into an honest first classification. Its distinctive move is that it does not resolve the hard questions — it sorts them. It decides which parts of a problem are cleanly decidable and can proceed to a full specification, and which parts are undecidable, underspecified, or genuinely value-laden and must be routed to a fallback instead. It is a triage instrument: fast, deliberately coarse, and about routing rather than proving.
Example¶
A trust-and-safety team is handed a mandate to "automate hate-speech decisions." Before touching a classifier they sit down with the triage worksheet. Prompt one — name the question class: not "is this bad" but "for a given post of text or image, does it violate policy clause 4.2?" Prompt two — pin the predicate: what exactly makes 4.2 true? They find "contains a targeted slur from a closed list" is crisp and testable, while "uses dehumanizing framing" depends on context, speaker history, and reclaimed usage. Prompt three — could a finite procedure decide it for every post?: the slur-list branch, yes; the framing branch, no — it needs human judgment. The worksheet's output is a split. The list-match branch is marked decidable and handed forward to a specification; the framing branch is marked out-of-scope-for-automation and routed to a reviewer queue with an explicit fallback rather than a silent default. Half a day with the worksheet prevents a year of a classifier confidently mislabeling reclaimed speech.
How it works¶
The worksheet is a sequence of prompts, each carrying a routing consequence — a triage, not a design document:
- Name the class, not the case — separate the recurring question class from the one instance that prompted it.
- Sharpen the predicate until it is testable — and treat the point where sharpening stalls as itself a finding, not a nuisance.
- Ask, per branch, whether a finite procedure could halt with the right answer — a coarse yes/no/uncertain, not a proof.
- Split the problem — decidable branches hand off to a specification; open, underspecified, or value-laden branches get an explicit fallback declared on the spot.
- Record the routing so the boundary is auditable later rather than folklore.
Tuning parameters¶
- Prompt depth — a six-question smell test versus a page per component. More depth catches more, but costs design time; match it to stakes and reversibility.
- Branch granularity — treat the question as one lump or split it into sub-predicates. Finer splitting rescues a decidable core from a messy whole, at the cost of more handoffs.
- Decidability bar — how confident you require before calling a branch "decidable, proceed." A strict bar sends more work to specification and proof; a loose bar risks over-promising.
- Fallback default — what an unrouted or ambiguous case does by default (deny, defer, escalate). It sets the safety posture before any procedure exists.
- Re-triage cadence — one-shot at design versus a re-run whenever scope creeps.
When it helps, and when it misleads¶
Its strength is that it is cheap insurance: in an afternoon it surfaces the questions that otherwise surface in production as looping, mislabeled, or timed-out cases, and it names the fallback before a default gets chosen by accident. Its central failure is checkbox theater — filling the boxes without genuinely testing decidability, so a value-laden question gets waved through because someone wrote a predicate-shaped sentence next to it. The classic misuse is treating the finished worksheet as a certificate rather than a triage: a team that has "done the worksheet" then over-trusts the result and ships automation over a question that is really only semi-decidable or flatly open. The touchstone the worksheet exists to catch is the halting problem[1] — the standing reminder that some yes/no questions admit no total procedure at all, no matter how the box is filled. The guarding discipline: a branch counts as "decidable" only if someone can state the procedure and its warrant, not merely assert it; everything else is routed, not resolved.
How it implements the components¶
question_class_scope— its first and load-bearing prompt: name the class of questions and separate it from the one-off case that triggered the work.decision_predicate— sharpens "what does yes/no mean here" to the point of testability; the place where sharpening stalls is itself a routing signal.fallback_resolution_policy— for every branch that is not cleanly decidable, it declares an explicit fallback route instead of leaving a silent default.
It does not pin the input encoding contract, nor the termination and correctness warrants — those belong to the Decision-Procedure Specification and the Termination & Totality Proof Review; nor does it locate the problem among known complexity classes, which is the Reduction Boundary Map's job.
Related¶
- Instantiates: Decision-Procedure Boundary Mapping — the worksheet is the design-time entry point that decides which branches the rest of the archetype's machinery even applies to.
- Sibling mechanisms: Decision-Procedure Specification · Termination & Totality Proof Review · Reduction Boundary Map · Fallback Mode Register
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Decidability Triage Worksheet operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it walks a team, at design time, through the questions that reveal whether a yes/no problem can be a real decision procedure — and where it can't, routes it to a declared fallback.
Independent corroboration: The frozen evidence defines Decidability Triage Worksheet as 'Walks a team, at design time, through the questions that reveal whether a yes/no problem can be a real decision procedure — and where it can't, routes it to a declared fallback', so its operative form is Decision, Gate & Allocation.
Nearest alternative: Representation, Specification & Plan — The worksheet routes a design problem into a decision-procedure class or fallback, rather than merely displaying prompts.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Computability theory cohered formal distinctions among decidable, undecidable, and restricted decision problems, including proof that no total procedure exists for general cases such as halting.
Related originating lineages:
- Mathematics — Mathematical logic supplied decision-problem formalization and impossibility proofs.
- Philosophy — Logic and epistemology supplied separation of factual decidability from underspecification and value-laden judgment.
Review resolution: Computability theory cohered formal distinctions among decidable, undecidable, and restricted decision problems, including proof that no total procedure exists for general cases such as halting.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] The halting problem — Turing's 1936 result that no single algorithm can decide, for every possible program and input, whether that program eventually halts. It is the archetypal undecidable question: not merely hard, but admitting no total decision procedure. The worksheet's job is to notice when a branch is really of this kind before anyone promises to automate it. withdrawn registry ↩