Conversational Retrieval

For a high-level overview of the full conversation intelligence system -- intent classification, context gating, entity memory, cross-session context -- see Conversation Intelligence. This page covers the mechanisms that make multi-turn conversations work.

Beyond single-shot Q&A

Standard retrieval treats every query as independent -- no memory, no context, no follow-up. Planara's conversational retrieval layer adds multi-turn awareness so technicians can ask follow-ups, refine their question, and drill into specifics without repeating themselves.

This is implemented across several stages of the query pipeline. There is no separate "chat mode" -- every query runs through the same pipeline. Conversation state determines which stages activate.

Intent classification

Every query is classified into one of 5 intent types before entering the pipeline:

Intent classification drives routing. An acknowledgment or navigation_meta intent short-circuits to a deterministic response. A contextual_followup intent triggers query rewriting and context gating. A status_report intent updates the diagnostic state and may advance the workflow. A knowledge_query intent proceeds to full retrieval and skill routing.

Query rewriting

When a query is classified as contextual_followup, the query rewrite stage reformulates it into a standalone question using conversation history. This is critical for retrieval quality -- searching on "What about the oil?" returns garbage. Searching on "What is the oil capacity for the engine?" returns the right documentation.

The rewrite preserves the technician's intent while making the query self-contained. The original phrasing is kept for display; the rewritten version is used for retrieval and generation.

Context gate

The context gate checks whether the current question can be answered from the existing conversation without a new retrieval pass. This handles cases like:

• "Can you repeat that?" -- return the previous response
• "What was the torque spec you mentioned?" -- extract from the previous response
• "Tell me more about step 3" -- expand on a specific part of the previous answer

When the context gate fires, the pipeline skips retrieval entirely and routes directly to generation with the conversation history as context. This is faster (no search round-trip) and avoids retrieving potentially different documentation that could contradict the previous answer.

Deterministic resolver

For known patterns -- fault codes, standard greetings, simple acknowledgments -- the deterministic resolver returns structured responses without invoking the AI at all. This covers:

• Fault code lookups: "What is P0217?" returns the structured fault code definition, common causes, and related codes from the fault code database
• Greetings and closings: "Thanks" returns a polite acknowledgment
• Equipment identification: Known model numbers route to the correct equipment context

Deterministic responses are instant (no generation latency) and fully grounded (data comes from verified lookup tables, not generation).

Conversation state tracking

Each session maintains state across queries:

• Query history: All queries in the session, with their rewritten versions
• Response history: Generated responses (used by the context gate and query rewriter)
• Active equipment context: The equipment model being discussed, carried forward from query to query
• Active fault codes: Fault codes mentioned or diagnosed, accumulated across the session

State is scoped to the session_id. A new session starts fresh. State is stored in memory during the session and persisted so the widget endpoints can access it.

What the technician sees

The conversational layer is invisible to the technician. There is no "chat mode" toggle, no special syntax. The tech just asks questions and gets answers. Behind the scenes:

• Conversational responses: Follow-up answers are shorter and more focused because the pipeline knows what was already covered
• Follow-up question chips: Every response includes AI-generated follow-up questions rendered as tappable chips. These suggest natural next steps ("What torque wrench setting?", "Do I need to replace the gasket?")
• Shorter answers on follow-ups: When context gate fires or the query is a refinement, the response focuses on the delta -- what's new -- rather than repeating the full procedure
• Consistent equipment context: Once the tech asks about a specific model, subsequent queries assume that model unless explicitly changed

Related

• Platform Overview -- full pipeline architecture
• Widget API -- follow_up_questions field in response shapes
• Context Streams -- the 8 data streams injected into generation