Five Failures Needed Five Different Repair Decisions

When a repair fails, asking the model to rewrite its instructions again can look like progress while repeating the same decision. WTK tested whether a typed controller could recognize five different persistent failure classes and send each one to the layer that could actually change it.

The result supports the routing mechanism, not the repairs themselves. The controller made the declared decision in every fixed case, but we have not yet shown that those decisions improve a live agent.

Question

When an obligation-bound failure survives one candidate, does WTK stop adding instruction steering and route the next decision to the responsible repair layer while retaining the failure and preserving checks that already pass?

Experiment

We replayed five fixed failure classes through two policies. The instruction-only baseline authorized another instruction rewrite. The typed arm used WTK's production repair-plan comparison and router.

The cases covered output-contract, refusal-boundary, capability-binding, evidence-policy, and goal-contract failures. Each case also carried one passing evaluator identity that the next candidate had to preserve. The expected repair layer was declared before the comparison.

The experiment was deterministic and offline. It made no model or network calls, changed no package, and carried no qualification authority. Every case counted in both arms. There were no retries or best-of selection.

Evidence

The evidence package binds the fixed cases, declared oracle, production router, result, and regression test to one WTK source revision.

Result

The typed controller selected the declared repair layer for all five persistent failures. It retained each failure manifestation and each already-passing evaluator identity without authorizing another instruction-only retry.

The baseline did the opposite. It authorized another instruction rewrite in all five cases and did not preserve the evidence needed to constrain the next repair decision.

Bounded finding

On this fixed matrix, WTK's typed repair routing supported the claim that a persistent failure can be escalated according to its responsible layer instead of being treated as another prompting problem.

The experiment also exposed an unresolved ambiguity. The current output-contract-or-model route combines two materially different choices. A contract-shape failure should not automatically become a reason to select a more capable model.

Boundary

This was a routing experiment. It did not apply any selected repair to a live package and did not measure resolution, new regressions, tokens, cost, latency, or operator intervention. Five correct route selections do not establish general repair effectiveness.

Builder impact

Repair systems should preserve what failed, what already passed, and which layer owns the next change. Prompt rewriting is one repair actuator, not the universal one.

A controller should be able to stop, hold, or escalate when the evidence points to a contract, capability, evidence policy, goal, or model boundary.

Next experiment

WTK should replay retained live failures through instruction-only and typed repair arms from the same starting evidence. Every attempt should remain counted, and the comparison should measure resolution, regression, honest holds, tokens, cost, latency, and operator action.