Diagnostics

Overview

The diagnostic stage sits between initial assessment and repair in the technician workflow. Its purpose is to confirm the root cause before the technician begins work. The platform adjusts the depth and complexity of diagnosis based on how much evidence is already available.

Three entry paths

High confidence — direct to repair

When telemetry data and fault codes converge on a single root cause, there is no ambiguity to resolve. The platform bypasses the diagnostic stage entirely and presents the repair procedure directly, along with the relevant safety warnings, parts list, and specifications.

This path is common when a fault code maps to a well-documented failure mode and telemetry readings are consistent with that failure.

Ambiguous — guided investigation

When the available data points to multiple possible causes, the platform enters guided diagnostic mode. It presents a sequence of targeted checks — measurements, visual inspections, or tests — designed to narrow down the possibilities.

Each check is chosen based on its diagnostic value: the platform prioritizes checks that will eliminate the most possibilities with the least effort. As the technician reports findings, the system records them, updates confidence, and adapts the remaining check sequence.

Symptom-only — full diagnostic tree

When the technician arrives with only a reported symptom and no telemetry or fault code data, the platform presents a full diagnostic tree. Starting from the symptom, it walks through systematic elimination steps — from most common causes to least common — until the root cause is identified.

This path requires the most technician interaction but ensures thorough coverage when no machine data is available.

How diagnostic steps work

Each diagnostic step presented to the technician includes:

• What to check — a specific measurement, visual inspection, or test to perform
• Expected values — the specification range for a passing result (cited from source documentation)
• How to report — what the technician needs to record (pass/fail, measured value, observation)

When the technician reports a finding:

1. The platform records the finding against the diagnostic session
2. Confidence is recalculated based on the new evidence
3. The remaining diagnostic path updates — some branches are eliminated, others are prioritized
4. The next check is presented, or the diagnosis is confirmed if confidence is sufficient

Confidence building

A visual confidence indicator tracks diagnostic progress throughout the investigation. It reflects how much of the diagnostic space has been covered and how strongly the evidence points to a specific root cause.

The confidence indicator is not a percentage — it is a qualitative assessment (investigating, narrowing, confirming) that communicates progress without implying false precision.

Transition to repair

When diagnostic evidence accumulates to the confirmation threshold, the platform transitions to the repair stage. The transition includes:

• The confirmed root cause with supporting evidence
• The relevant repair procedure (cited from source documentation)
• Safety warnings associated with the repair
• Parts required for the repair
• A record of all diagnostic findings (available for the work order)

The technician can also manually confirm a diagnosis at any point if they are confident in the root cause before the system reaches the confirmation threshold.

Chat during diagnosis

The chat interface remains active throughout the diagnostic stage. Technicians can:

• Ask clarifying questions about a diagnostic check ("What tool do I need for this measurement?")
• Request specification values referenced in a check ("What's the normal resistance range for this sensor?")
• Describe unexpected observations that don't fit the available check options
• Request to skip a check they cannot perform and get an alternative path

Chat responses during diagnosis are context-aware — the platform knows which diagnostic step the technician is on and what findings have been recorded so far.

Self-learning diagnostics

Diagnostic decision trees are extracted automatically from your documentation during onboarding. When you upload a service manual, the platform identifies troubleshooting sections, fault code tables, and symptom-based diagnostic flows, then generates structured decision trees that guide technicians through systematic root cause analysis.

These diagnostic templates start as drafts. Your team can review, edit, and activate them through the admin interface before they reach technicians. Once active, the platform tracks how each template performs in the field:

• Templates that consistently lead to correct diagnoses are prioritized — they appear first when a technician encounters a matching symptom, and their confidence scores increase over time.
• Templates that lead to incorrect or incomplete diagnoses are deprioritized — they drop in ranking and are flagged for review.
• New documents automatically generate new diagnostic workflows — when you upload a TSB or updated service manual, the platform extracts any new troubleshooting content and creates additional templates.

This creates a continuous improvement loop: the more your technicians use the platform, the better the diagnostic workflows become. The system learns which paths work for your specific equipment and operating conditions, without requiring manual curation.

Admins can see template performance metrics (success rate, usage count, average resolution time) in the backoffice and can override automatic prioritization when needed.

Equipment-scoped diagnostics

Diagnostic procedures are scoped to the specific equipment model identified on the work order or detected in the conversation. This scoping matters because the same fault code can mean different things on different equipment models — a code that indicates a sensor failure on one model may indicate a wiring issue on another.

When the platform presents diagnostic checks, expected values, and resolution procedures, all content is filtered to the relevant equipment model's documentation. If the technician references a different model mid-diagnosis, the platform detects the switch and adjusts its diagnostic context accordingly.

Multi-attempt repairs

Not every repair resolves the issue on the first try. When verification fails, the platform supports starting a new repair attempt without losing the diagnostic and repair history from the previous attempt.

How it works

1. The technician completes a repair and enters the verification stage
2. Verification reveals the issue persists — the original fault code reappears, or the symptom is still present
3. The technician initiates a new repair attempt from the verification screen
4. The previous attempt is archived to the History widget in the rail, preserving every diagnostic finding, procedure step, and part used
5. The hero card transforms to show the new attempt number (e.g., "Attempt 2") with fresh procedure and diagnostic context
6. The platform uses findings from previous attempts to adjust its diagnostic recommendations — eliminating already-tested hypotheses and prioritizing remaining possibilities

Attempt history

Each attempt is a complete record: diagnosis, procedure followed, parts used, technician notes, and verification result. An attempt detail modal shows the full history of what was tried across all attempts.

When the job closes, the platform auto-generates a multi-attempt correction summary. This narrative covers every attempt — what was tried, what was found, and what ultimately resolved the issue. The summary is included in the work order closure data for warranty claims and fleet analytics.

Analytics

The API tracks attempt counts and outcomes for reporting:

• Jobs requiring multiple attempts are flagged for review
• Recurring multi-attempt patterns across equipment models surface documentation gaps
• Attempt data feeds into diagnostic template improvement — templates that frequently lead to failed first attempts are deprioritized

Outcome tracking and field learning

Every diagnostic session generates structured outcome data that feeds the field intelligence loop:

Step-level outcomes

Each diagnostic check records its outcome: passed, failed, skipped, or inconclusive. When a check produces an unexpected result — a value outside the expected range, a visual observation that doesn't match any documented condition — the technician can annotate the finding.

Those annotations accumulate. When the same unexpected finding shows up across multiple technicians and equipment units, the platform detects the pattern and proposes updates to the diagnostic template.

Resolution capture

When a diagnosis leads to a successful repair, the full path is recorded: symptom reported, checks performed, root cause confirmed, procedure applied, verification passed. That path is linked to the equipment model, the fault code (if present), and the specific diagnostic template used.

When the repair doesn't resolve the issue, the platform captures what the technician did next — off-script fixes, alternative procedures, escalation to a senior tech. The "what actually fixed it" data is the most valuable signal in the system. It's also the hardest to get without building the capture into the workflow.

Network resolution analytics

Across a dealer network, diagnostic outcome data surfaces patterns that no single shop can see:

• Root cause distribution — for a given symptom, what percentage of cases are caused by each possible root cause across the network
• Check effectiveness — which diagnostic checks most efficiently distinguish between root causes, and which are just burning time
• Model-year correlations — specific production batches or model years with higher failure rates for certain components
• Seasonal patterns — diagnostic patterns that correlate with geography or season (corrosion in coastal areas, fuel system issues after winter storage)

This data surfaces in the Adoption Dashboard for OEM network administrators.

Integration with work orders

Diagnostic findings are persisted as part of the work order record. When the job closes, the diagnostic evidence — checks performed, values recorded, diagnosis confirmed, resolution path, and attempt history — is available for:

• Service history (what was checked, what was found, what worked)
• Fleet analytics (recurring diagnostic patterns across equipment)
• Warranty documentation (complete evidence chain from symptom to resolution)
• Field intelligence (outcome data feeding correction workflows and template learning)

Related

• Platform Overview — high-level architecture and workflow stages
• Field Intelligence — how repair outcomes improve future responses
• Context Streams — how telemetry, fault codes, and service history feed into diagnosis
• Widget API — diagnostic step and finding data structures