DIAGNOSTIC BUDDY
a guided AI diagnostic assistant for automotive training
A mobile-first AI diagnostic assistant for automotive training that turns messy technician input into a structured diagnostic pathway.
A phone-friendly assistant that walks a mechanic from a vague symptom to the next thing to check, without needing to know how to prompt an AI.
- Live prototype
- 2025-26
What it is
A new mechanic looks at a fault and does not know what to ask next. Diagnostic Buddy turns a vague symptom into a clear path: the likely cause, what to check first, and how strong the evidence is so far. It is built for the workshop floor, designed so you can tap your way through it with gloves on instead of typing.
The work
Context
Between a manual and a chatbot
Trade training has two kinds of tool, and both fall short. One is static content: manuals, PDFs, flowcharts. The other is open-ended AI chat, which is flexible but easy to misuse, easy to hallucinate, and dependent on the user already knowing how to prompt it.
Diagnostic Buddy sits between them. It uses a model, but it constrains the interaction into a diagnostic workflow, because the goal is not to answer questions, it is to guide better diagnostic thinking. I built it as the interactive piece of a training-modernisation proposal for an automotive registered training organisation.
What it does
From a vague symptom to the next step
It helps a user work a fault from vague symptom to structured next step. Workshop-style input like "6L80 harsh shift hot, no codes, fluid checked" turns into a practical response: likely fault direction, the reasoning behind it, the next checks, clarifying questions, risk notes, and when to stop guessing and test.
The suggested reply buttons are the part that matters most. A user with dirty hands, gloves, a torch, and a scan tool can move through the diagnosis by tapping, not typing, and the buttons also feed the model cleaner state. It is a data-quality layer wearing a usability hat.
The design principle
You should not need to know how to prompt
One rule drives the build: the user should not need to know how to prompt the AI. The app does the prompting architecture for them. Instead of a blank chatbox, it walks the user through a structured sequence, collects fault context, normalises it, preserves the original technician language, and hands the model a clean diagnostic package.
The model is held to diagnostic discipline. It is steered toward "this could indicate X, confirm Y before replacing parts, confidence is moderate because scan data is not yet available." A confidence meter shows whether the answer rests on strong, moderate, or weak context, which teaches the real lesson: diagnosis is evidence-based.
How it works
A controlled contract, not a free chat
Four layers: a mobile-first interface, a guided input and state layer, the model and API reasoning layer, and a demo fallback. The UI owns the layout; the model only fills a fixed contract of summary, confidence, likely area, reasoning, next test, warning, and suggested replies. That is the line between an AI toy and a controlled AI product.
It was built with a higher-capability model and moved down to a Sonnet-class model for runtime, on the logic that once the structure is constrained the live task does not need the expensive model. The live API is not the only load-bearing wall: a demo mode shows the full experience even when the API is down, and failures never surface as stack traces.
What it is, and what it is not
Honest about its limits
This is a live, API-connected prototype, mobile-first, with the guided flow, suggested replies, confidence meter, and demo mode all working. It is functional enough to demonstrate the concept and useful enough to assist real diagnostic thinking. It is not a production system, and it is not yet grounded in approved course content.
The honest line holds throughout: the AI assists diagnostic reasoning, it does not replace verification. It is not trusted for final repair decisions, exact specifications, or anything safety-critical. The confidence meter, the guided questions, and the structured output exist to keep it transparent instead of magical.