Phase 10: Simplification Audit

Every harness component encodes an assumption about model limitations. As models improve, remove components and add complexity at the frontier.

The Removal Test

Before adding any component, ask what breaks if you remove it instead. If you cannot name exactly what breaks, you do not need it yet.

Complexity Justification Matrix

Every new component must pass all four criteria:

1. Demonstrated failure: reproducible failure case without it
2. Model insufficiency: orchestration problem, not reasoning problem
3. Proportionality: complexity cost proportional to failure severity and frequency
4. Temporality: component will likely still be needed in 6 months

Ablation protocol

• Remove harness components one at a time
• Re-evaluate performance after each removal
• Never remove multiple components simultaneously
• Triggers: new model release, quarterly review, component not root cause in 30+ days

The most durable pattern

Generator-Evaluator separation survives across model generations. Sprint decomposition was removed when Opus 4.6 arrived. Context management is infrastructure, not reasoning scaffolding — the Bitter Lesson does not apply to it.

The 2AM Debuggability Test

• Can one person hold the entire architecture in their head?
• Are failure modes explicit (logs) or emergent (component interactions)?
• Can you explain why each component exists without historical context?

If any answer is "no," simplify.