When a Technical RAG Should Answer, Ask, or Escalate

A technical question can look simple while still missing the operating condition, product revision, measurement context, or approved source needed for a defensible answer. Retrieval-augmented generation (RAG) is a workflow that retrieves from an approved source library before composing an answer. It may find related text and still fail to support the specific conclusion being requested. If every search result becomes an answer, fluent language can hide a weak evidence chain. This prototype specification reframes classification as knowledge routing: first decide whether the approved RAG or database documentation can answer the question, then either provide a source-linked response, ask for the missing context, or hold the case for expert review.

Why related documentation may still be insufficient

A query may be a direct documentation lookup, a comparison, a request that lacks essential context, or a case that depends on judgement beyond the approved knowledge base. Similar wording can lead to very different evidence requirements.

Retrieval alone answers, “What text looks related?” The engineering question is, “Do the approved sources directly support the answer for this exact request?”

What happens when fluent wording outruns the evidence

If the system routes by language similarity alone, it can:

• answer from a source that is related but not sufficient;
• combine statements that do not support the requested conclusion;
• overlook missing technical context;
• present an outdated or unapproved source as current guidance.

Correct wording is not enough. The route must reflect the strength and relevance of the evidence.

First decide whether the question is answerable

The useful decision is whether the approved RAG or database contains documentation that is current, specific, and direct enough to answer the question.

Turn evidence quality into an evidence-matched route

1. Capture the minimum context

Identify the question, the requested decision, and any missing technical condition needed to interpret it. Unknown context remains explicit.

2. Search only approved sources

Retrieve from the documentation collections the workflow is allowed to use. Source identity, revision, and citation stay attached to the candidate evidence.

3. Check answerability

Ask whether the retrieved material directly supports the requested answer, is current for the relevant context, and is sufficiently specific. A semantically similar passage is not automatically sufficient.

4. Select one of three routes

• Answer with citations when approved documentation directly supports the response.
• Ask for context when the documentation may answer, but the question is underspecified.
• Expert review when the answer requires judgement, evidence outside the approved sources, or a higher-risk decision.

What the proposed workflow would need to prove

The evaluation plan connects the workflow definition to six evidence checks:

Review the route, not only the label

For each evaluation question, inspect four outputs:

1. the minimum context the system believes it needs;
2. the approved sources it retrieved;
3. why those sources do or do not support an answer;
4. the resulting route: answer with citations, ask for context, or expert review.

This makes the system useful even when it cannot answer. A well-routed refusal protects the evidence boundary and shows exactly what information is needed next.

A small synthetic routing example

Question: “Can this controller operate at 500 kHz?”

Missing context: exact controller revision, gate-drive condition, converter topology, operating mode, and which limit the reader wants to check.

Retrieved source: an approved datasheet for a related revision that lists an oscillator range but does not establish the requested operating condition.

Route: ask for the exact part revision and operating context. The related datasheet is not sufficient evidence for a yes/no answer.

This synthetic example demonstrates the route, not the performance of a deployed classifier.

Reusable answerability record

A false answer can lead a reader to accept an unsupported technical conclusion; a false escalation adds review cost but preserves the evidence boundary. The acceptable balance depends on the consequence of error.

Continue with Field Note 001 to see the same separation applied to execution state, rule outcome, review, and final disposition.