The Effective AI Engineer • Case #013 • 13 of 16
The Engineer Who Followed Failure Backwards
Applying Focus and Creative Challenge to investigate an AI failure before choosing a fix.
Applying Lateral Thinking to Create Meaningful Impact with AI
Before changing the component that produced the answer, investigate the conditions that made that answer possible.
Lateral Thinking tools: Focus and Creative Challenge.
Engineering focus: Failure analysis, execution traces, evidence provenance, controlled experiments and regression evaluation.
Professional benefit: Learn to separate symptoms from explanations, test competing hypotheses and verify a correction across the complete workflow.
1. The situation
A software company had built an AI assistant to answer internal questions about product administration.
The assistant searched approved technical documentation, assembled relevant excerpts and generated an answer with source references. Employees used it to locate procedures before carrying out their work.
During a limited pilot, a support specialist asked how to restore a connector after an upgrade to version 4.2.
The assistant supplied a clear sequence of steps and cited a genuine administration guide.
The steps belonged to version 3.8.
A human reviewer caught the mismatch before the procedure was used. The incident was recorded as a failed answer.
The proposed fix was immediate: strengthen the instruction telling the model to use the requested product version.
But one engineer wanted to establish where the version mismatch entered the workflow.
2. The story
Ananya, the engineer responsible for the assistant, opened the rejected answer with Vikram, the technical lead.
“It ignored the version,” Vikram said. “Add a stronger instruction.”
“Perhaps,” Ananya replied. “What version did the model actually see?”
The answer cited the correct document title. Its source link opened an approved manual. The retrieval dashboard showed a successful request.
Everything looked reassuring until they inspected the excerpt.
It contained the old procedure. Its heading named the connector, but the version information had been removed when the passage was prepared for the model.
“The source is approved,” Vikram said.
“Approved for which version?”
Changing the focus
Ananya wrote the team’s current question: Why did the model ignore the version?
Under it she wrote a different focus: Where did the workflow lose the distinction between versions?
The second question did not excuse the final answer. It opened more places to investigate.
They followed the failed response backwards: from the displayed answer to the generated text, from the text to the assembled context, and from that context to the retrieved passages.
The original request explicitly named version 4.2. The retrieval results included passages from both versions. The context assembler kept their text but omitted their version metadata.
The model had been asked to select a version-specific procedure from evidence that no longer clearly identified its versions.
Ananya recorded this as an observed defect and a candidate explanation—not a completed diagnosis.
A plausible explanation needed a test
The team prepared an isolated replay using retained, authorised evidence from the failed run.
They held the request, model configuration and instructions steady, then compared the original context with a version that preserved document identifiers, product versions and passage provenance.
Across repeated trials, the corrected context helped the model distinguish the procedures. It did not eliminate every failure.
On another failed request, the recorded context was already correctly labelled.
“So metadata was not the cause?” Vikram asked.
“It was a contributing defect in the first path,” Ananya said. “It does not explain every path.”
The failure was sometimes outside the model call
They inspected the second request more closely. The application had returned a cached answer without making a new model call.
The cache key included the connector name and question category. It did not include the requested product version.
An answer previously generated for version 3.8 could therefore be returned for a version 4.2 request.
Their successful replay had bypassed that cache.
“We tested the generation step,” Ananya said. “The user receives the application.”
They added version and relevant configuration information to the cache design and introduced invalidation rules for changes to the indexed documentation. Unknown versions could not silently reuse a version-specific answer.
Challenge the established choice
The team then examined why context preparation removed metadata. It had originally been introduced to reduce repeated headings and keep prompts concise.
That purpose was reasonable. The implementation had treated applicability information as expendable formatting.
Ananya asked: Is deleting the metadata the only way to keep the context concise?
They generated alternatives: compact structured labels, a shared document header with explicit passage links, or retrieval restricted to an established version before context assembly.
They selected compact provenance labels and explicit handling of missing or conflicting versions for the pilot.
The change introduced another tradeoff. In some cases, the assistant now returned an unresolved response when the applicable version could not be established.
The team accepted that behaviour for those cases and improved the clarification path. It also checked for unnecessary abstention on routine questions.
A green test was not the end
One evaluation still marked a corrected answer as failed. Its expected response contained the old procedure.
A support specialist checked the authoritative manual and corrected the evaluation fixture. The team documented the change instead of treating the old expected answer as unquestionable truth.
Other failures remained unexplained. Some old runs lacked enough retained evidence to reconstruct what had reached the model. The team labelled those investigations inconclusive.
For future runs, it added correlated records of retrieval, context assembly, cache decisions and generation. Sensitive content was kept out of general operational logs; authorised evidence snapshots used separate access and retention controls.
The pilot resumed only after tests covered cached and uncached paths, multiple versions, missing metadata and questions that had previously worked.
Vikram returned to the original suggestion. “We still need the version instruction.”
“Yes,” Ananya said. “And a workflow that preserves what the instruction needs.”
3. The Lateral Thinking tools
Focus: change what receives attention
Edward de Bono treats Focus as a creative tool: choosing where to direct attention can open possibilities that the original framing leaves unexplored. [1]
The team began with a model-centred focus: “Why did the model ignore the version?”
Ananya changed it to a workflow question: “Where did the distinction between versions stop being preserved?”
That shift brought context preparation, cache behaviour and evaluation data into the investigation.
Creative Challenge: question uniqueness
De Bono distinguishes Creative Challenge from criticism. It asks whether an established approach is the only way to achieve its purpose, even when the approach has previously worked well. [1]
The context assembler had a legitimate purpose: reduce unnecessary input. The creative challenge was:
Is deleting applicability metadata the only way to keep the context concise?
This generated alternative designs before the team selected compact provenance labels.
4. Making the thinking visible
-
Describe the observed failure.
A request for version 4.2 received a procedure for version 3.8. Avoid beginning with an untested explanation such as “the model ignored the instruction.” -
Identify the actual execution path.
Establish whether the response came from generation, a cache, a fallback or another application route. -
Inspect the evidence at each boundary.
Compare retrieved material with the material actually assembled for the model and the answer ultimately shown to the user. -
Keep observations and hypotheses separate.
Missing metadata is an observation. Its contribution to the failed answer requires investigation. -
Test competing explanations.
Compare controlled changes and check whether the proposed mechanism explains the affected cases. -
Verify the complete correction.
Retest the integrated application and unaffected categories, including routes the isolated replay did not exercise.
A model-generated explanation of its own answer can suggest hypotheses. It does not establish the historical cause. Application records and controlled tests provide different kinds of evidence.
Reusable prompt
We are investigating this observed AI workflow failure: [describe expected and actual behaviour].
Using only the supplied records, separate observations, hypotheses and missing evidence. Identify the execution paths that could have produced the displayed result.
Generate competing explanations across input handling, retrieval, context assembly, model configuration, tools, caching, output processing and evaluation.
For each explanation, identify supporting evidence, contradictory evidence and a controlled test that could distinguish it from another explanation.
Apply Creative Challenge to one established design choice: what purpose does it serve, and what other implementations could serve that purpose?
Do not infer missing events, claim access to hidden model reasoning or label correlation as proof. Mark inconclusive cases explicitly.
5. Comparing explanations and interventions
| Candidate explanation | Evidence to inspect | Possible intervention if supported |
|---|---|---|
| Retrieval supplied an inapplicable procedure | Query, filters, document versions and returned passages | Improve version-aware retrieval and unresolved handling |
| Context assembly removed applicability information | Retrieved passages compared with assembled model input | Preserve compact provenance and version labels |
| The model misused clearly labelled evidence | Actual input, configuration and repeated controlled trials | Test instructions, evidence layout or model configuration |
| The cache returned an answer for a different version | Cache keys, hit decisions, stored provenance and invalidation | Correct cache scope and invalidation rules |
| The evaluator expected an obsolete procedure | Grading logic, expected response and authoritative manual | Correct the fixture and preserve its revision history |
Several explanations can be true in different requests, and several contributing defects can interact within one request. The investigation should not force every failure into one category.
A prompt change may still be useful. Its value should be tested against the observed mechanism and the complete application.
6. Research evidence and limits
Inspect traces and verify outcomes
Anthropic’s evaluation guidance distinguishes execution transcripts from final outcomes. It discusses reading transcripts, repeated trials, evaluation defects and the interaction between a model and its surrounding harness. These distinctions support examining how a result was produced rather than grading its text alone. [2]
Quality failures can originate in infrastructure
Anthropic’s September 2025 postmortem describes three infrastructure issues that degraded response quality. Its account includes routing and token-generation implementation problems, difficult reproduction conditions and changes to evaluation and debugging practices. [3]
This is a documented example showing that output degradation can originate outside application prompts. It does not establish the cause of another system’s failure, including the fictional incident in this case.
Telemetry records operations, with limits
OpenTelemetry’s generative AI conventions describe spans for observable operations and link to conventions for inference, retrieval and tool execution. The referenced document is marked Development, so implementations should track the convention version they use. [4]
The guidance also treats instructions, inputs and outputs as potentially sensitive and large. It advises against capturing that content by default and describes opt-in capture or externally stored content references.
A trace records what the instrumentation observes. It does not expose a complete internal model process or independently establish why an output occurred.
The proposition to test
A broader investigation focus, combined with evidence at workflow boundaries, can help a team select a correction that addresses a demonstrated failure mechanism.
The case illustrates that proposition. It provides no measured claim about diagnosis speed, accuracy or incident reduction.
7. Practice and evaluation
Accessible exercise
Choose one AI result that failed an important requirement.
- Write the expected behaviour and the observed behaviour.
- Remove assumed causes from the initial description.
- List three different explanations.
- Identify the evidence needed to distinguish them.
- Rewrite the investigation focus to include the workflow.
- Challenge one established implementation by identifying its purpose and generating alternatives.
- State which conclusions remain uncertain.
Technical exercise
Reconstruct one failed request in an isolated environment using authorised evidence.
- Correlate the request with retrieval, context assembly, model calls, tools, cache decisions and displayed output.
- Record relevant application, prompt, model and data versions.
- Distinguish original evidence from reconstructed or newly retrieved material.
- Preserve necessary evidence under appropriate access and retention controls.
- Check whether instrumentation omitted a relevant path.
- Form competing hypotheses before choosing an intervention.
- Where feasible, change one relevant factor at a time and repeat trials.
- Inspect interactions when multiple components may contribute.
- Test cached, uncached, fallback and error paths.
- Inspect grading logic and expected results against authoritative requirements.
- Prevent replay from producing unintended external effects.
Verify the correction
A successful rerun of the original example is useful evidence, but it is a limited test.
- Retest the original failure condition.
- Test variations of the same mechanism.
- Use held-out cases that were not used to develop the fix.
- Retest previously successful cases.
- Measure unsupported claims and incorrect applicability.
- Measure unnecessary abstention and clarification.
- Check latency, cost and operational impact.
- Document unresolved failure categories.
Add regression tests that check the relevant boundary as well as the final outcome. Define a monitored rollout and rollback conditions before returning the change to wider use.
8. Professional benefit and transfer
For AI engineers
- Describe failures without prematurely assigning a cause.
- Inspect evidence across application boundaries.
- Recognise cache, data and evaluation failure paths.
- Use controlled tests to assess competing explanations.
- Turn an incident into targeted regression coverage.
- Record uncertainty when evidence is incomplete.
For technical leaders
- Ask what evidence supports a proposed fix before approving it.
- Allocate ownership across data, application and model components.
- Fund diagnostic visibility alongside feature development.
- Distinguish mitigation, demonstrated correction and unresolved explanation.
- Review the effect of fixes on previously successful work.
Limits of transfer
The approach can inform investigations of retrieval assistants, coding tools, document workflows and other AI applications. Each requires evidence appropriate to its architecture.
Historical conditions may be impossible to reconstruct exactly. Provider behaviour, data sources and application state can change. Missing records should remain visible as limitations.
Following the workflow backwards is a useful starting point, but investigations may need to branch across parallel operations, shared services and interacting defects.
Reflection question
If your next AI answer is wrong, what evidence will let you distinguish a model failure from a failure in the workflow around it?
Professional takeaway
Investigate the path that produced the failure, test the explanation and verify the correction where the user experiences the result.
9. Reusable artifact: Failure Investigation Record
Complete the following for a consequential workflow failure.
- Expected behaviour and acceptance requirement.
- Observed behaviour and user impact.
- Immediate containment or mitigation.
- Request identifier and affected time range.
- Actual execution path and recorded boundaries.
- Application, prompt, model and data versions.
- Evidence provenance and access controls.
- Missing, sampled or reconstructed evidence.
- Competing hypotheses and contradictory observations.
- Controlled tests and repeated-trial results.
- Established design choice challenged and its purpose.
- Alternative interventions considered.
- Selected correction and remaining limitations.
- Regression, held-out and unaffected-case results.
- Rollout owner, monitoring and rollback conditions.
- Conclusion strength and follow-up review date.
Completion check: Show the evidence supporting the selected explanation, demonstrate the correction through the actual application path and identify what remains unproven.
References
- Edward de Bono. Serious Creativity: Using the Power of Lateral Thinking to Create New Ideas. 1992. Focus discussion beginning on printed page 91; Creative Challenge distinction on printed pages 104–105. Original method source supplied with the project.
- Anthropic. Demystifying Evals for AI Agents . 9 January 2026.
- Anthropic. A Postmortem of Three Recent Issues . 17 September 2025.
- OpenTelemetry. Semantic Conventions for Generative Client AI Spans . Development-status document checked 6 November 2026, including guidance on capturing instructions, inputs and outputs.
Research note: Sources checked 6 November 2026. Documentation can change. The fictional scenario is not a report about the cited organisations. Focus and Creative Challenge are drawn from de Bono’s work; the investigation and application design are contemporary engineering adaptations.
Develop your engineering judgment
The Effective AI Engineer is a 16-part series combining Lateral Thinking with AI engineering. Each independent case includes a professional scenario, an explained thinking tool, research-grounded discussion and practical exercises.
Apply this case to one failed AI result: describe the symptom, generate competing explanations and identify the evidence needed before selecting a fix.
Join the course: For course and enrolment details, workshops or professional collaboration, contact Ravindra Dastikop and mention The Effective AI Engineer.
Email:
ravindra.dastikop@gmail.com
Cell:
8453212131
