Route Cause Analysis: Stop Sending Every AI Failure to Training

TL;DR for operators

An AI failure is an observation, not a diagnosis.

A low benchmark score, an incorrect answer, or a broken agent run does not tell you whether the underlying problem belongs in the training data, model objective, retrieval policy, procedural instructions, tool interface, or execution environment. Treating all of these as “model quality” produces expensive interventions with weak causal logic.

Three recent papers collectively suggest a more disciplined operating model:

1. Decompose the failure into a stable capability slice. Separate the task, information conditions, solving operations, and output constraints before deciding what went wrong.
2. Decide where the missing capability should live. Stable and reusable knowledge may belong in model parameters. Current, rare, or instance-specific knowledge may need retrieval.
3. Externalize procedures, not just facts. Domain workflows require skills, dependencies, parameter rules, tool contracts, and persistent computational state.
4. Re-evaluate the same failure slice. A broad score increase is not enough. Verify that the intended weakness improved and that solved cases did not regress.
5. Test the complete workflow. A model that chooses the correct method but loses a file path halfway through the process has not completed the task. It has merely failed with better reasoning.

The practical implication is simple: stop asking, “How do we improve the model?” Ask, “Where does this particular failure belong?”

AI improvement has become a routing problem

Enterprise AI teams now have an impressive menu of interventions.

They can add documents to a retrieval system, fine-tune the model, revise the prompt, purchase a larger model, add tools, build a multi-agent workflow, increase inference-time sampling, introduce validators, or simply generate another synthetic dataset and hope the loss curve knows what management meant.

The abundance of options creates a less glamorous problem: choosing the correct intervention.

The default response is usually to add more of whatever the organization already owns. Teams with a data platform request more training data. Teams with a retrieval platform add another index. Agent teams expose another tool. Model teams propose another training run.

This is organizationally convenient. It is not necessarily diagnostic.

A benchmark regression may be caused by missing knowledge. It may also be caused by a malformed output, a scoring parser, an absent termination token, a noisy search result, an inappropriate domain procedure, or a stale intermediate file. These are not variations of the same problem. They are failures in different parts of the system.

The three papers considered here form a complementary logic chain:

• Data and Evaluation Closed-Loop for Model Capability Enhancement provides a method for diagnosing what actually failed.¹
• Search Beyond What Can Be Taught examines the next decision: whether missing knowledge should be internalized by the generator or supplied through external search.²
• SP-Mind shows what happens when knowledge must be turned into a long-running domain workflow involving specialized tools, procedural constraints, files, and computational state.³

Together, they suggest that evaluation should not merely rank systems. It should route failures toward the mechanism best equipped to correct them.

A useful abstraction is:

The difficult step is not adding the intervention. It is choosing the branch.

Step one: diagnose below the benchmark name

The evaluation closed-loop paper begins with a useful objection to standard model development: a benchmark score is too coarse to represent a capability, while an individual failed example is too noisy to establish one.

Its proposed intermediate unit is the capability slice.

A capability slice groups evaluation examples that share four structured properties:

This decomposition matters because benchmarks routinely mix these conditions.

Two questions may both be classified as mathematics while requiring completely different operations. One may require arithmetic substitution. Another may require concept alignment, equation formulation, symbolic transformation, boundary-case reasoning, and several intermediate constraints to remain consistent at once.

Calling both “math” is descriptively true and operationally unhelpful.

The same applies in reverse. Samples from different benchmarks may belong to the same capability slice because they require the same underlying operation under similar information and output conditions.

The paper’s central proposal is therefore not merely finer reporting. It is a translation layer between evaluation and intervention.

A weak slice involving whole-passage evidence aggregation may motivate training material with distributed dependencies. A weak slice involving symbolic transformation may motivate derivation-heavy supervision. A failure concentrated in rigid output constraints may indicate that the model solved the task but expressed the result in a form the evaluator rejected.

That last possibility is not theoretical.

The reasoning regression that was not a reasoning regression

In one case study, continued pre-training improved almost every benchmark but caused the model’s BBH score to fall from 47.27 to 25.14.

The obvious interpretation was that additional training had damaged multi-step reasoning.

The slice analysis pointed elsewhere.

BBH contains a large proportion of rigidly formatted, exact-match tasks. A prediction-level audit showed that the updated model often generated the correct answer first and then continued producing irrelevant text. The scorer rejected the enlarged response even though the gold answer was already present.

Among audited cases where the gold answer appeared as a response prefix, the base checkpoint was accepted only 37.34% of the time. In 62.66% of these cases, additional suffix text followed the correct answer.

The root cause was missing loss supervision on the <EOS> token at document boundaries. The model had learned to reach correct answers, but not reliably to stop.

Restoring termination supervision raised BBH from 25.14 to 66.44 without changing the data mixture. The proportion of gold-prefix responses containing an extra suffix fell from 62.66% to 0.31%.

The apparent reasoning failure belonged in the training objective.

More data would have been an impressively expensive way to misunderstand a missing stop signal.

When the data really was the problem

The paper’s second case study deliberately moves in the opposite direction.

The model showed persistent weakness on difficult mathematical tasks. Increasing the number of generated attempts did not reliably reveal valid solutions, especially on AIME problems. This indicated that the correct reasoning trajectories were not merely being ranked poorly; they often had negligible probability under the model.

Operation-level decomposition showed that arithmetic itself was not the central weakness. Accuracy deteriorated most sharply when arithmetic had to be composed with operations such as:

• concept alignment,
• equation formulation,
• multi-hop composition,
• symbolic transformation,
• constraint tracking,
• counting, and
• boundary-case reasoning.

The authors used those diagnosed combinations to weight the sampling of synthetic mathematical instruction data. They held the architecture, optimizer, token budget, broad data mixture, and candidate instruction pool fixed. The controlled variable was which examples were selected from that pool.

At Pass@128, the experimental checkpoint reached 26.67 on both AIME2025 and AIME2026. The untargeted base checkpoint scored 6.67 on each; the warm-start checkpoint had scored 6.67 and 0.00, respectively.

The intervention did not produce dramatic gains everywhere. Standard one-output benchmark results moved modestly, and some slices remained difficult. The strongest effect appeared under repeated sampling, suggesting that the targeted data first made valid trajectories reachable before making them the model’s default response.

That distinction is important. An intervention can broaden the useful part of a model’s output distribution before it changes the modal answer observed by a single-sample evaluation.

What this paper shows

The same diagnostic loop correctly produced two opposing decisions:

• In one case, it ruled data out and found a termination-supervision defect.
• In the other, it ruled data in and identified which operation combinations the added data needed to contain.

This is stronger evidence for the methodology than two examples in which “add more targeted data” happened to work. A diagnostic system that recommends the same treatment for every case is not a diagnostic system. It is a procurement preference.

Step two: decide where knowledge should live

Once a failure has been diagnosed as missing knowledge, another routing decision remains.

Should the system learn that knowledge into its parameters, or retrieve it when needed?

The SearchGen paper studies this question through text-to-image generation, where the distinction is unusually visible. Modern image generators can render polished scenes while confidently inventing the appearance of a recent mascot, a regional cultural symbol, a niche fictional character, or a historically specific artifact.

The rendering machinery is functioning. The world model is not.

The authors build SearchGen-20K and SearchGen-Bench from 20,839 prompts spanning 12 failure categories and 22 domains. The benchmark separates knowledge-sensitive criteria—such as entity fidelity and factual correctness—from more conventional rendering criteria such as composition, physical plausibility, and image quality.

On prompts that could be handled using parametric knowledge alone, tested generators occupied a broadly comparable performance range. On search-intensive prompts, open generators fell to roughly 22–28 out of 100, while rendering-quality components remained noticeably stronger.

The failure was not simply an inability to make images. It was an inability to make the requested image.

Search seems like the obvious remedy. Unfortunately, obvious remedies remain subject to engineering.

Retrieval can destroy a correct answer

The paper compares selective search with a policy that searches indiscriminately.

Blind search reduced performance for every tested generator on prompts that did not need external knowledge. For Qwen-Image-2, the overall score on the NoSearch subset fell from 70.7 without search to 60.4 with blind search. A reasoned search configuration instead reached 76.5.

The authors identify two characteristic failure modes.

Concept corruption occurs when search retrieves an imperfect reference for something the generator already understands. The external material overrides a more accurate internal representation.

Reference copying occurs when the generator treats an image result as a compositional template, reproducing its incidental background, framing, lighting, or style rather than extracting only the missing attribute.

The system has gained access to more information and produced a worse result. This is not unusual in retrieval systems; visual generation merely makes the corruption easier to see.

The knowledge boundary

The paper describes the division between parametric and retrieved knowledge as a generator-specific knowledge boundary.

On one side is knowledge that the generator can usefully internalize:

• stable visual identities,
• recurring concepts,
• fixed symbols,
• reusable stylistic or structural conventions.

On the other side is knowledge that remains contextual:

• post-training events,
• rapidly changing information,
• extreme long-tail entities,
• instance-specific references,
• combinations that cannot be economically represented in a fixed training corpus.

The boundary is not universal. It depends on the generator.

A stronger generator may already know what a weaker generator needs to search for. After additional training, the same model may move some concepts from the contextual side to the internalized side. A static retrieval policy therefore becomes miscalibrated as the generator improves.

The paper’s response is a teach-then-search co-training process.

First, the generator is trained on successful search-augmented examples, allowing it to internalize stable knowledge and become more resistant to imperfect references. Then the search reasoner is recalibrated against the improved generator so that it stops retrieving concepts the generator can now handle itself.

The reasoner uses a three-stage protocol:

1. Gate: identify important knowledge gaps and decide whether search is needed.
2. Filter: select results that fill the specific gap with minimal extraneous content.
3. Integrate: specify which retrieved attributes should enter the generation rather than passing raw references through without interpretation.

For the Klein-4B generator, search-intensive performance increased from 26.4 with the initial search reasoner to 29.2 after generator training and 31.8 after reasoner recalibration. The final result slightly exceeded the 31.2 score obtained using a much larger frontier reasoner as a generator-agnostic oracle.

The point is not that an 8B reasoner has generally surpassed frontier systems. The point is narrower and more useful: a smaller policy calibrated to a specific generator can outperform a larger policy that does not know where that generator’s boundary lies.

What this paper adds to the chain

The evaluation paper asks, “What capability failed?”

SearchGen adds, “Where should the missing knowledge reside?”

That second question prevents two common forms of excess:

• over-training, in which teams repeatedly teach the model information better supplied at runtime;
• over-retrieval, in which teams inject external material into tasks the model could already perform correctly.

The optimal answer is not “put everything in the model” or “retrieve everything.” It is to maintain a moving allocation between the two.

Step three: turn knowledge into executable work

A model may be correctly diagnosed. It may retrieve the right information. It may even identify the correct tool.

None of this guarantees that it can complete a real workflow.

SP-Mind examines this problem in spatial proteomics, where a typical analysis may involve illumination correction, image registration, background subtraction, tissue dearraying, probability mapping, cell segmentation, marker quantification, and biological clustering.

These stages are not a loose bag of functions. They form a dependency graph with expected file formats, intermediate artifacts, parameter constraints, and scientific assumptions.

SP-Mind combines:

• a ReAct-style reasoning cycle,
• arbitrary code and shell execution,
• specialized spatial-proteomics tools,
• human-curated procedural skill templates,
• container abstractions,
• persistent conversational state, and
• persistent filesystem state.

The model backbone was held constant across experimental conditions. This allowed the authors to compare the effect of domain tools and skills rather than quietly attributing every improvement to a larger model.

Tools are not procedures

The most instructive part of SP-Mind is its distinction between a tool description and a domain method.

A tool API may explain available arguments. It does not necessarily tell an agent:

• which preprocessing steps are prerequisites,
• how to inspect the data before choosing parameters,
• what marker distributions are biologically meaningful,
• which output from one stage is valid input to another,
• how to recover from an expected error,
• or when a technically successful result is scientifically implausible.

SP-Mind therefore retrieves task-specific BioSkill templates. These templates encode reasoning strategies, dependencies, parameter heuristics, and recovery procedures. Only the relevant skill is injected, limiting the context dilution that would result from placing every possible methodology into every prompt.

On SP-Bench—102 tasks across 18 categories, eight processing stages, and four difficulty levels—SP-Mind achieved an average execution success rate of 68.9%. Its no-skill version reached 62.4%, while the strongest alternative equipped with the same spatial-proteomics tools reached 55.4%.

General-purpose agent baselines averaged between 14.7% and 19.3%.

This separation is revealing:

• Giving a general agent domain tools produced large gains.
• Adding a purpose-built orchestration architecture produced further gains.
• Injecting procedural skills produced an additional, smaller improvement.

Capability was distributed across several layers. No single layer deserved all the applause, despite the traditional preference for assigning it to whichever model name fits on the slide.

The remaining bottleneck is operational state

SP-Mind’s weakest results appeared on the most complex tasks. It achieved 95.8% on basic tasks but 33.3% on the challenging tier involving four or more stages.

The failure analysis explains why.

In long workflows, the agent could complete upstream stages and later:

• save an artifact to the wrong directory,
• reuse a stale path,
• pass the wrong intermediate file to a downstream tool,
• insufficiently inspect a schema mismatch,
• or mishandle a tool-specific input contract.

These are not primarily failures of biological knowledge. Nor are they solved merely by adding another tool.

They are failures of workflow bookkeeping.

The paper also provides an important warning about procedural augmentation. On one PDAC-IMC cell-annotation dataset, the full skill-augmented system scored 0.648, below its no-skill variant at 0.762 and below two specialized agent baselines.

A skill template is therefore not automatically beneficial simply because an expert wrote it. A procedure can be mismatched to a modality, overspecify a method, or steer the model away from a better data-dependent approach.

The SearchGen lesson reappears in a different form: external context must be selectively routed, even when that context contains expert knowledge rather than search results.

The combined architecture: diagnose, place, execute, verify

The three papers can be assembled into one operational framework.

This table is a business interpretation of the combined research, not a framework formally evaluated by any one paper. Its value comes from preserving the distinctions that the individual experiments expose.

A failure should move downward only as far as necessary.

Do not rebuild the model when the scorer is rejecting a correct answer. Do not add retrieval when the model already knows the concept. Do not fine-tune factual knowledge when the missing ingredient is a procedure. Do not add procedural instructions when the actual problem is that the system cannot remember where it saved the file.

An operating model for enterprise AI improvement

The research suggests six practical stages for teams building AI products.

1. Define the unit of failure before deployment

Do not wait for a broad quality score to decline.

For each important workflow, define slices based on:

• input or background condition,
• requested task,
• operations required,
• output contract,
• tools used,
• and workflow depth.

For a customer-support system, slices might separate policy lookup, account-state retrieval, refund calculation, exception handling, and exact CRM-field generation.

For an investment-research agent, slices might distinguish factual retrieval, cross-document comparison, numerical reconciliation, scenario modeling, and citation completion.

2. Preserve raw traces

Aggregate scores erase the evidence needed for diagnosis.

Retain:

• original inputs,
• retrieved context,
• search decisions,
• tool calls,
• intermediate artifacts,
• raw model outputs,
• parser-transformed outputs,
• validation results,
• and terminal failure states.

The BBH termination bug was visible only because raw and filtered responses could be compared. SP-Mind’s operational failures were visible because execution traces exposed stale paths and malformed intermediate inputs.

No trace, no root cause. Only opinions with dashboards.

3. Assign a failure owner by system layer

Each diagnosed failure should have one provisional technical owner:

• evaluation,
• objective,
• data,
• retrieval,
• skill,
• tool,
• state,
• or permission layer.

This owner represents a hypothesis, not a conviction.

The purpose is to prevent every problem from being routed to the same team and to make the proposed causal mechanism explicit before resources are committed.

4. Change one controllable variable

The most persuasive experiments in these papers use controlled comparisons.

The evaluation paper holds the token budget and broad mixture fixed while changing how synthetic math examples are sampled. SP-Mind holds the backbone model constant while comparing tools, architecture, and skills.

Enterprise teams rarely achieve laboratory purity, but they can still avoid changing the model, prompt, retrieval corpus, tool interface, and evaluator simultaneously. That produces a new system, not an explanation.

5. Re-test both the target and the abstention set

Every intervention needs two evaluation groups:

• a target set on which the diagnosed failure should improve;
• an abstention or preservation set on which the intervention should have little effect.

SearchGen’s NoSearch subset performs this second function. It reveals whether retrieval damages tasks the generator already handles.

A training intervention should likewise be checked for regression on unrelated capabilities. A procedural skill should be tested on tasks where it is relevant and tasks where it should not be injected.

6. Evaluate the completed business artifact

Model-level correctness is not workflow success.

The final evaluation should inspect whether the system:

• followed the required sequence,
• used approved data and tools,
• respected permissions,
• produced the requested artifact,
• saved it in the correct location,
• preserved the expected schema,
• and reported errors rather than concealing them.

SP-Bench’s execution metric is strict because scientific work is strict. A beautifully reasoned explanation accompanied by a missing output file is not partial success in most operational settings.

It is an incident with good prose.

What to measure

A routing-based evaluation program requires more than one top-line accuracy number.

The final row is particularly useful for generative systems.

A treatment that improves Pass@128 but not Pass@1 has changed the probability distribution without yet making the correct behavior dominant. That can still be meaningful, but deployment may require a stronger selector, verifier, search procedure, or further training.

Where the combined argument stops

The three papers provide converging evidence, not a universal systems law.

The evaluation closed-loop methodology was tested on one continued-pre-training pipeline and a fixed collection of benchmarks. Its evaluation-to-data rules are explicitly heuristic. The experimentally validated intervention used synthetic instruction data; the proposed mapping into non-instruction pre-training corpora remains less directly tested.

SearchGen’s co-training experiment uses one generator-training pass followed by one reasoner-recalibration pass. Its findings are demonstrated on particular open visual generators, and much of the evaluation relies on an automated multimodal judge. It remains unclear how the knowledge boundary behaves across much larger generators, repeated training cycles, or other modalities.

SP-Mind operates in one specialized scientific domain and depends on human-curated skills. Its results show that skills help on average, not that a supplied skill is always correct. Its declining success at greater workflow depth also shows that persistent state is necessary but not sufficient; more explicit state machines, artifact typing, and contract validation may still be required.

The business framework developed here therefore should not be interpreted as “seven layers that guarantee reliable AI.”

It is a method for producing better intervention hypotheses and testing them more honestly.

That is less exciting than a universal architecture. It is also more likely to survive contact with a production system.

The system should know where its ignorance belongs

The usual debate about AI capability is framed as a contest among larger models, more data, better retrieval, and more autonomous agents.

The papers here point toward a more mature question.

Not every failure belongs inside the model. Not every unknown fact belongs outside it. Not every procedure belongs in a prompt. Not every correct local action composes into a valid workflow.

Reliable improvement requires a routing discipline:

1. localize the failure,
2. identify the missing signal,
3. place that signal in the correct substrate,
4. protect already-solved behavior,
5. execute through explicit contracts,
6. and re-evaluate the same failure at the level where it originally appeared.

The best AI system is not the one with the most data, tools, retrieval, or agent loops attached to it.

It is the one that can distinguish which of those mechanisms the current problem actually requires.

Cognaptus: Automate the Present, Incubate the Future.