Conversation Intelligence

Beyond single-shot Q&A

Standard technical search treats every query as independent. Planara's conversation intelligence layer maintains context across an entire service session, so technicians can ask follow-ups, report findings, and drill into specifics without repeating themselves.

This is not a separate "chat mode." Every query runs through the same pipeline. Conversation state determines which stages activate and how they behave.

How it works

Intent classification

Every query is classified before entering the pipeline. Two classification paths run in sequence:

Fast path (regex, no AI call): Catches navigation commands ("go back", "start over") and acknowledgments ("thanks", "got it"). These return deterministic responses instantly -- no retrieval, no generation. Roughly 15% of technician messages are acknowledgments that previously wasted a full pipeline round-trip.

AI classification path (~150ms): When conversation history exists, distinguishes between:

Intent classification eliminates unnecessary work. A "thanks" message no longer triggers a 15-second retrieval round-trip.

Query rewriting

When a query is classified as a follow-up, the pipeline rewrites it into a standalone question using conversation history. This is critical for retrieval quality.

Without rewriting: The technician asks "What about the drain plug torque?" Searching on this partial question returns poor results.

With rewriting: The pipeline rewrites it to "What is the drain plug torque specification for the Yamaha F300A oil change procedure?" Searching on this standalone question returns the correct documentation.

The original phrasing is preserved for display. The rewritten version is used for retrieval and generation. Up to 3 diverse reformulations may be generated for parallel retrieval, maximizing the chance of finding the right documentation.

Context gate

After query rewriting, the context gate checks whether the 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 generates from conversation history. This is faster (no search round-trip, ~150ms instead of 15-30 seconds) and avoids retrieving different documentation that could contradict the previous answer.

The gate uses a fast AI model that evaluates whether the conversation context contains enough information for a complete, accurate answer. It does not guess or infer values -- if the answer requires specific specs or procedures not present in the conversation, the gate passes and full retrieval runs.

Orchestrator (contextual query understanding)

After query rewriting, the orchestrator reads the full conversation context and determines what the user actually needs -- not just what keywords match. This is a fast AI call (~200ms) that sets a response strategy for the rest of the pipeline.

The orchestrator also rewrites vague conversational queries into specific retrieval queries when needed. "What about that thing we discussed?" becomes a targeted lookup.

The clarify strategy is particularly important: when the query is genuinely ambiguous and the wrong interpretation would waste time or be dangerous, the system asks a specific question instead of guessing. This is nearly instant (~200ms) because it skips retrieval and generation entirely.

Clarifying questions are always labeled as clarifications in the API response (response_type: "needs_clarification", with the question and selectable options in a structured clarification object) — never presented as confident answers. This is enforced at the API boundary: if the pipeline ever produces a bare question with no grounded content ("Are you asking about the engine-driven pump, or the electric transfer pump?"), it is reclassified as a clarification before it reaches the client, so consumers render it as a question with tappable options rather than an answer card. When a site has multiple machines, the options are labeled with clean machine names so the technician can pick the right unit at a glance.

Self-evaluation (post-generation quality check)

After generation, the pipeline checks: did the response actually answer what the orchestrator requested? This is a closed feedback loop that catches strategy-response mismatches.

Deterministic checks run first (free, ~1ms):

• spec_lookup: Does the response contain a numeric value with units?
• diagram: Does the response cite specific manual pages?
• procedure: Does the response have populated procedure steps?

If a deterministic check fails, a fast AI model (~150ms) attempts a targeted correction -- supplying just the missing element as an addendum. Maximum one retry, then the response passes through as-is.

Proactive suggestions

After self-evaluation, the pipeline scans the context streams for signals the technician didn't ask about but should know:

• TSB matches: A Technical Service Bulletin in the context is relevant to the current issue but wasn't mentioned in the response
• Recurring faults: The same fault or procedure appears 2+ times in the equipment's service history -- suggests a root cause
• Parts warnings: A part referenced in the response is backordered or unavailable

Proactive suggestions are pure signal detection -- no AI calls, under 5ms. They appear as a "heads up" alongside the response, not as part of the answer text.

Conversation memory (entity extraction)

After each exchange, a fast AI model extracts structured entities from the conversation:

Entities are stored in a structured table with bi-temporal tracking. Each entity records the session, turn index, and context. Entities can be invalidated when corrections occur (e.g., the technician initially says "F300A" but later clarifies "F350A").

This structured memory enables:

• Equipment context carry-forward -- once the tech mentions an F300A, all subsequent queries assume that model until explicitly changed
• Diagnostic state accumulation -- findings from each check are accumulated across the session, building a diagnostic picture
• Cross-session history -- entities are indexed by namespace and equipment model, enabling lookups like "what issues have been reported on this equipment model?"

Conversation state summary

After 2+ exchanges, the pipeline generates a structured summary of the conversation state: equipment being discussed, current diagnosis direction, checks completed, open questions, and the last answer given. This summary is prepended to the query context before the pipeline runs.

The summary costs ~200ms (fast AI model) and is non-blocking -- if it fails, the pipeline falls back to raw conversation history. The summary prevents context drift on long sessions where the full history exceeds the AI model's effective attention window.

Honest knowledge gaps

When the documentation doesn't cover what was asked, the platform says so explicitly instead of producing a vague non-answer. A knowledge-gap response:

• States the gap plainly — "that isn't covered in the documentation for this equipment" — and never fills it with a guess
• Keeps proof of understanding — the response reflects back what was asked, so the technician knows the question was understood, not misheard
• Offers the closest documented information available — an adjacent spec, the section that would contain the answer, or the relevant component reference
• Gives a concrete next step — such as contacting the manufacturer's dealer or distributor with the unit serial number, or measuring the worn part and cross-referencing

A bare restatement of the question is never served as an answer. Knowledge-gap responses are typed distinctly in the API (response_type: "knowledge_gap") so consumers can suppress procedure steps, parts lists, and follow-up chips that would imply an answer exists.

Short reply understanding

Brief technician responses ("yes", "done", "185 degrees") are interpreted as answers to the platform's previous question, not as new queries. When the last AI message asked a question ("What does the voltage read?"), short replies are routed through the full pipeline with the question-answer pair as context.

Previously, short replies were consumed by the frontend's local intent classifier before reaching the pipeline, causing a "tech answers a question and nothing happens" failure mode. This is now fixed at both the frontend and API layers.

Dynamic equipment detection

When a technician asks about a different equipment model mid-conversation, the entity extraction layer detects the model reference and adjusts retrieval scope automatically. There is no need to close the session or start a new work order. The platform flags cross-model queries so the technician knows which model the answer applies to.

Follow-up chips

Every AI response includes tappable follow-up chips -- contextual next actions the technician can tap instead of typing. Chips are generated through a cascade:

1. Primary: The generation AI model includes them as follow_up_questions in the structured response
2. Contextual fallback: If the model returns empty chips, a fast AI path generates grounded chips from the response content, retrieved source metadata, and current workflow stage (~200ms). These are constrained to things the system can actually deliver -- no "contact dealer" or "visit website" suggestions
3. Stage-aware defaults: If both AI paths fail, static chips appropriate to the current workflow stage are used (assess → "What should I check first?", repair → "Show me the next step", etc.)

For responses containing a question, chips are answer options ("At idle", "Under load", "Both") rather than new questions. This is detected by the presence of "?" in the summary and switches the chip generation to answer-option mode.

Chips adapt to what was just discussed -- two consecutive responses will never show the same chips. This prevents the "tapping the same button and getting the same answer" failure mode.

What the technician sees

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

• Follow-up answers are shorter and more focused because the pipeline knows what was already covered
• Equipment context persists without repeating model numbers
• Diagnostic findings accumulate across the session
• The platform asks targeted follow-up questions and provides tappable answer options
• Short replies are understood in context

Workshop idiom awareness

The conversation layer understands industry-specific idioms and informal language. Phrases like "throw it in the bay" (assign to a service bay), "she's running hot" (overheating), or "it's throwing a code" (displaying a fault code) are interpreted correctly in context rather than literally.

This is handled by the domain ontology and contextual language understanding, not a hardcoded dictionary. The system adapts to each tenant's industry terminology.

Status report recognition

When a technician reports the outcome of a check or repair — "done", "fixed", "alarm cleared", "voltage reads 12.4V" — the system recognizes these as status reports rather than new questions. Status reports update the conversation state, acknowledge the finding, and suggest the next step in the diagnostic or repair sequence.

The recognition system uses a combination of pattern matching for common phrases and AI classification for more complex reports. This eliminates the failure mode where a technician reports a finding and the system tries to search for documentation about it.

Post-retrieval topic filtering

When conversation history exists, retrieved results are reordered by relevance to the current conversation topic. This prevents topic drift — if the technician is discussing cooling system troubleshooting and a result about the fuel system scores high on the raw query, it will be demoted in favor of cooling-related results.

The filter uses the conversation state summary to weight results, not a separate retrieval pass. Cost: negligible.

Related

• Platform Overview -- full pipeline architecture
• Conversational Retrieval -- details of the conversation retrieval layer
• Context Streams -- the data streams injected into generation