4. From Classification to Choice — A Design Heuristic, Not a Mapping Table

4.1. Why Not a Table

The obvious temptation, after three sections building conceptual apparatus, is to close it all into a table: analytical tasks → bounded operational autonomy; intuitive tasks → human-in-the-loop; quasirational tasks → human-on-the-loop. This section deliberately resists that temptation, and not out of aesthetic scruple — it is exactly the error Section 1.2 already identified in the Fitts list and the MABA-MABA logic derived from it: a static allocation of functions, decided once from an isolated task property, that stops working as soon as context changes. Dekker and Woods (2002) did not criticize the Fitts list for being poorly filled in; they criticized it for presupposing that the question "who is better at this?" has a fixed answer.

The task's classification narrows the space of defensible architectures; it does not choose one alone. Article 3 provides a structural profile of the task; Article 4 uses it as input for design; Article 5 audits actual execution. None of the three replaces the others. What the three preceding sections offer, instead of a fixed mapping, is a set of conditions and diagnostic questions that, applied to a concrete operational scenario — not to a task type in the abstract — narrow that space. It is this heuristic that this section formalizes.

4.2. The Heuristic: Five Decision Gates, Not a Mechanical Sequence

"Gates" describes the logic better than "sequence": an architecture needs to pass through all of them, but none is final — an answer obtained at a later gate can reopen a decision already made at an earlier one. The table below summarizes each gate's function before the prose development:

Prior condition — are the criterion and the operational domain auditable? Before distributing any authority, one needs to know what outcome the architecture intends to preserve, prevent, or optimize, and under what conditions that relationship can be observed. If the action alters the very outcome used to evaluate it, or if the criterion is unobservable, contested, or strongly endogenous — the weak and strong forms already distinguished in Section 3 of Article 5 — the architectural choice cannot be treated as validated by historical performance alone. The scenario requires additional causal design, conservative limits, and reinforced auditing before any of the following questions makes sense.

Question 1 — Is the temporal inequality even satisfiable? Section 2.3's condition must be verified for the concrete scenario:

$$t_{\text{until irreversibility}} > t_{\text{detection}} + t_{\text{comprehension}} + t_{\text{decision}} + t_{\text{intervention}}$$

If this inequality does not hold, human-on-the-loop with real-time veto is not a genuine option, regardless of how desirable it may appear in the abstract — there may be an override interface, notification, or after-the-fact review, but not real operational human control. In these cases, the choice is between bounded operational autonomy, with conservative automatic action, and architectures applied to an earlier stage of the process, where the window is still sufficient.

Question 2 — What is the task's, or sub-task's, classification on the continuum? Here Article 3's classification enters — but not as an answer, as a starting point, and at the correct level of granularity. A globally quasirational task can contain very different sub-tasks: detecting a physical limit being exceeded, risk estimation, cause diagnosis, action selection, interlock activation, maintenance scheduling, the economic decision to stop production. Some of these sub-tasks may justify bounded operational autonomy; others may require human-in-the-loop; others, decision support. The task's overall quasirationality makes it hard to defend a uniform architecture for the whole process — but it does not automatically exclude extreme architectures for narrow, recoverable, physically protected sub-actions. Its correct consequence is not the rejection of any "extreme" architecture, but the need to decompose the task by regime, sub-function, and action before distributing authority — precisely the discipline Article 3's Section 3.5 already requires ("by task and failure mode, not by industrial asset in the abstract"). An uncertain or contested classification, in turn, should narrow the authority envelope — limiting actions to recoverable options, triggering a safe state, requiring additional validation, or escalating to human decision when time allows. Conservative does not necessarily mean "more human"; it means less delegation of irreversible action under uncertainty, and in some short-time-window scenarios the more conservative option is precisely a limited automatic action, not a human approval there is no time to exercise substantively.

Question 3 — What is the recoverability profile of the candidate actions? The five senses distinguished in Section 2.5 — command, physical, temporal, economic, safety — must be assessed for the specific action (reducing load, stopping a line, triggering an interlock, deferring maintenance), not for the task in general. The same class of failure can produce actions with radically different recoverability profiles depending on the exact scenario, as Section 3.6 already illustrated.

Question 4 — Do the paradox's four conditions apply to this scenario? Reliable routine automation, rare human intervention, residual human responsibility, and exceptions that are critical, opaque, or time-demanding. If the four coexist, any architecture that preserves residual human responsibility without frequent intervention requires especially rigorous justification and active competence-preservation mechanisms — but the conditions may coexist with greater or lesser intensity, and what matters is not merely their binary presence, but the product of the probability of decoupling and the severity of the consequence should it occur, already discussed in Section 3.5.

Question 5 — Are the five effective-control factors sustainable over time? Section 1.4 defined effective human control as jointly dependent on information, time, competence, authority, and workload. A design may satisfy the five factors on the day of validation and still degrade — through staff rotation, through an increase in the number of systems under the same operator's supervision, through competence erosion via Section 3.3's mechanism, through drift that alters the task's practical classification, or through a process change that reduces the assumed recoverability. This is not the last question of a linear chain — it is the gate that reopens any of the previous ones, which makes the heuristic a process of continuous verification, not a single decision made at the moment of design.

4.3. What This Heuristic Is Not

Two caveats, both inherited from the discipline already established throughout the rest of the trilogy. First, this heuristic is not empirically validated — it is a design proposal, built from theoretical precedents and a well-grounded paradox, but not tested in a controlled environment. Section 1.3 already noted that the levels-of-automation tradition itself, from which this article inherits vocabulary, has an unresolved empirical controversy about the generalization of its central findings; this heuristic inherits that same uncertainty, it does not resolve it. Second, the gates do not produce an automatic answer — they produce a space of defensible architectures, narrower than the original space of four, but rarely reduced to a single option. The final choice within that space still requires engineering judgment, cost, and risk tolerance that this article does not intend to replace.

4.4. Illustration: Argus, Revisited

Applying the heuristic to the thermal-anomaly-detection scenario already described in Section 3.6 (detection with sufficient lead time, technically safe load reduction, limited false-positive cost): the criterion and domain are reasonably well defined, with no apparent strong endogeneity (prior condition); the temporal inequality holds with margin (Question 1); the task classifies close to the analytical pole with reasonable confidence (Question 2); recoverability is high in almost every sense (Question 3); the paradox's conditions may apply, but the operational consequence of decoupling is mitigated by the recoverability profile assumed for this specific scenario (Question 4); and the five control factors appear sustainable with routine vigilance (Question 5). The resulting space includes human-on-the-loop with moderate competence-preservation mechanisms, and possibly bounded operational autonomy for the load-reduction sub-case specifically, keeping human-on-the-loop only for the full-stop decision.

In the vibration and bearing-failure scenario, with significant production coordination and a high cost of late intervention: the temporal inequality may still hold, but with less margin; the classification is quasirational, not purely analytical, and possibly heterogeneous by sub-task — signal detection may be more analytical than the decision to stop production (Question 2); recoverability is low in at least two senses, economic and safety (Question 3); the paradox's conditions apply with high consequence, given the recoverability profile (Question 4); and the five factors require active mechanisms, not merely routine vigilance (Question 5). The resulting space excludes bounded operational autonomy for the broad stop decision without additional safeguards, and admits human-on-the-loop only conditioned on active competence-preservation mechanisms, periodic detection exercises, and a formal audit adapted to rare and selected human interventions. Article 5 provides the conceptual starting architecture for that audit, but its extension to human-on-the-loop remains an explicitly open problem, already flagged in Section 2.3.

---

This heuristic closes Article 4's arc: from the inherited tradition and its controversy (Section 1), through the four formally defined architectures (Section 2) and the paradox explaining why none is universally correct (Section 3), to a design instrument that crosses these pieces without collapsing into the static table Section 1.2 already warned against. What remains open — whether the chosen architecture, once implemented, actually maintains correspondence with the environment this heuristic presupposes — is the question Article 5 allows one to audit conditionally, through the Environment → AI → Human → Action → Environment chain, under explicit specification of the criterion, the decision units, and the system's boundaries.