A demonstration asks a clear question against a clean document. The AI returns a useful answer, complete with a source.
Tuesday introduces a revised manual, an ambiguous product name and someone asking about the model that was discontinued three years ago.
This is where an AI feature needs a connected reliability plan. Evaluation, retrieval, exception handling and operational records should work together so the team can understand both a good result and a questionable one.
Sarang Sanjay Kulkarni’s June 2026 account on martinfowler.com describes PRINCE, a Bayer platform developed with Thoughtworks for working with preclinical research information.1 It discusses retrieval, evaluation, citations and recoverable workflows as parts of the same system.
That is their implementation in a specialist domain. My practical takeaway for a smaller business application is to follow one real task through its information and failure paths, rather than assess only the final paragraph.
Check the evidence before judging the answer
Consider a hypothetical assistant that helps staff locate equipment instructions. The first question is whether it retrieved the right material for the equipment and version.
Make document identity part of the design
A relevant-looking passage may belong to a different model or an obsolete revision. The source records should carry the identifiers needed to distinguish those cases.
When the request is ambiguous, the assistant may need to ask which model the person means. That can be a useful step in the task, rather than a failure to sound immediately helpful.
The ingestion process matters too. If a table was extracted incorrectly or a heading became detached from its instructions, the model may receive poor evidence despite the original document being clear.
Inspect the material supplied to the model. A polished answer can hide a retrieval problem as efficiently as a polished lid can hide yesterday’s washing-up.
We build AI agents with clear jobs and sensible limits. See how.
Assess whether the answer is supported
A source link helps a person inspect the evidence. It does not establish that every claim in the answer follows from that source.
Use representative questions with agreed expected behavior. Include cases where the available documents do not contain the answer and cases where versions conflict.
Check both the selected material and the generated response. A retrieval failure and an unsupported statement call for different corrections. Treating both as “the prompt needs work” can send the team toward the wrong fix.
Plan the moment the workflow cannot continue
A business feature needs an understandable result when a document cannot be read, a provider is unavailable or the evidence remains insufficient.
Keep retries bounded and progress visible
Temporary service failures may justify a limited retry. An unreadable source or unresolved product identity may need another route.
Preserve useful progress where the workflow supports it, but check whether the underlying material has changed before reusing earlier findings. A later retry should not combine a new document version with an old conclusion without noticing.
The person using the feature needs a clear state: still working, waiting for information, ready for review or unable to complete. Those messages should reflect the actual workflow.
Related read: Search your business knowledge before asking AI to improvise.
Give human review enough context to help
For an uncertain equipment instruction, show the relevant question, identified model, source version and unresolved issue. A reviewer can then make a decision without repeating the whole investigation.
Define which kinds of questions the assistant is intended to handle and which require qualified judgment through an established process. The feature’s presentation should make that scope clear.
Leave a record the support team can use
When someone reports a wrong answer, the team should be able to connect it to the request, permitted source material, model configuration and tool results. Record appropriate diagnostics while controlling access to sensitive content.
A useful review of this hypothetical assistant would ask:
- Did it identify the intended equipment and document version?
- Did retrieval supply the evidence needed for the task?
- Did the answer stay within that evidence?
- Did uncertainty lead to the appropriate next step?
- Could the team reproduce and investigate a reported failure?
Run those checks when the model, retrieval setup or source-processing logic changes. Use live feedback to add realistic cases, then verify that a correction helps without damaging previously useful behavior.
PRINCE’s account includes more specialized architecture than every business needs. The connected engineering discipline is the interesting part: evidence, evaluation and recovery support each other.
A dependable AI feature should be useful on the awkward day as well as the carefully prepared one. Tuesday does not read the demonstration script. It generally brings its own documents.