Section 3.8: Failure modes of each architecture

A Careful Control Loop

This section develops the technical contract for failure modes of each architecture into a usable mental model. First we define the object of study, then we connect it to the agent loop, then we test it with a compact implementation.

The key question in Failure modes of each architecture is practical: what must the agent know, what can it observe, what action is available, and what evidence shows that the action worked under the stated conditions?

Theory

For Failure modes of each architecture, the practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact.

Failure analysis is architecture-specific because each architecture hides uncertainty in a different place. A modular stack exposes many interfaces but can lose performance through handoff errors. An end-to-end policy removes handoffs but hides internal causes. A hierarchy improves long-horizon structure but creates precondition and termination failures. A dual-system design adds a router, which can become the most important component in the system.

The practical goal is not to produce a dramatic failure label. It is to produce the smallest intervention that flips the outcome while leaving the rest of the run unchanged. That intervention identifies the architectural boundary where the fix belongs.

Worked Example

The section argues that a good failure analysis finds the smallest intervention that flips the outcome. The example makes that operational: a rollout depends on four stage outputs (pose, plan, skill boundary, routing), exactly one is corrupted, and a search over single oracle substitutions recovers which one. This is the three-pass diagnostic compressed into a few lines.

# A rollout succeeds only if every stage output is correct.
ORACLE = {"pose": "good", "plan": "good", "skill": "good", "route": "S2"}

def rollout(stages):
    return all(stages[k] == ORACLE[k] for k in ORACLE)

# The failing episode: one corrupted stage (the planner chose a bad plan).
broken = {"pose": "good", "plan": "BAD", "skill": "good", "route": "S2"}
print("baseline success:", rollout(broken))

# Pass 2: try each single oracle substitution; report the minimal fix.
for k in ORACLE:
    patched = dict(broken, **{k: ORACLE[k]})
    if rollout(patched):
        print(f"minimal fix: substitute oracle '{k}' -> success")

# Pass 3: a real cause should flip a PANEL, not one hand-picked case.
panel = [dict(broken), dict(broken, pose="BAD"), dict(broken, route="S1")]
flips = sum(rollout(dict(ep, plan="good")) for ep in panel)
print(f"'plan' oracle flips {flips}/{len(panel)} panel cases")

Expected output: the baseline fails, the search identifies plan as the single substitution that restores success, and the panel check shows the plan oracle flips only the episodes whose sole defect was the plan. The discipline is the takeaway: a cause that flips one cherry-picked case is a clue, while a cause that flips a panel is evidence. The table above tells you which oracle to try first for each architecture, and this search tells you whether the guess was right.

Practical Recipe

1. Write the observation, action, and success metric before choosing a model.
2. Build a baseline that is simple enough to debug by inspection.
3. Add the library implementation only after the baseline behavior is understood.
4. Record failures as structured cases: perception error, state error, planning error, control error, or evaluation error.
5. Run at least one perturbation test before trusting the result.

Failure modes of each architecture becomes useful when it is tied to a closed-loop contract for how perception, estimation, planning, learning, and control are arranged into a system. The contract names the observation stream, the action representation, the timing budget, the safety boundary, and the result artifact. That is the bridge between a readable concept and a system a skeptical builder can test.

For Failure modes of each architecture, separate the conceptual claim, the systems claim, and the evidence claim. A good explanation, a clean API, and one successful rollout are different kinds of evidence, and the section should keep them distinct.

For Failure modes of each architecture, a robust implementation starts with one inspectable baseline whose artifact records observations, actions, units, timestamps, seeds, termination reasons, and the perturbation applied. The maintained-tool version is useful only if it preserves that schema and lets the comparison remain construct-matched.

1. Write a one-paragraph task contract with observation, action, success, failure, and safety fields.
2. Start with the smallest simulator, dataset, or wrapper that exposes the task contract faithfully.
3. Run one deterministic smoke test and one perturbation test before scaling.
4. Save one artifact containing configuration, seed, metrics, traces, and failure labels.
5. Compare methods only when the same script evaluates the same panel, split, seed set, and metric.

When Failure modes of each architecture fails, avoid labeling the whole method as weak. First assign the failure to perception, state estimation, planning, control, timing, data coverage, or evaluation. Then rerun one controlled perturbation that isolates the suspected cause. This pattern turns a disappointing rollout into a reusable diagnostic asset.

Use a three-pass diagnostic. First, classify the architecture, because the likely hidden variable depends on the design. Second, replay the episode with one oracle substitution, such as corrected pose, corrected plan, corrected skill boundary, or forced System 2 routing. Third, rerun the same intervention across a small panel of failures. A cause that flips one hand-picked case is a clue; a cause that flips a panel is evidence.

pip install numpy pandas

# Complete compact evidence trace for the section lab.
# Extend these records with values produced by your actual environment or simulator.
import pandas as pd

records = [
    {"run": "baseline", "seed": 0, "success": 0.72, "failure_label": "none"},
    {"run": "library_shortcut", "seed": 0, "success": 0.78, "failure_label": "none"},
    {"run": "baseline_perturbed", "seed": 0, "success": 0.54, "failure_label": "latency"},
]
print(pd.DataFrame(records))