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.
Context
Trade training has two kinds of tool, and both fall short. One is static content: manuals, PDFs, flowcharts, worksheets. The other is open-ended AI chat: 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.
That gap is real in a workshop. A senior technician knows what to ask: what vehicle, what transmission, hot or cold, under load, codes or no codes, fluid checked, wiring inspected, fault confirmed. A beginner says "it slips." Diagnostic Buddy is built to bridge that gap. I built it as the interactive piece of a training-modernisation proposal for an automotive registered training organisation, to show that legacy trade material can become an interactive diagnostic system for apprentices, trainers, and technicians.
What it does
It helps a user work a fault from vague symptom to structured next step, without pretending to be a magic answer machine. The user can type, but the system does not depend on perfect free text. It guides them with fault categories, focused follow-up questions, and suggested reply buttons.
It takes workshop-style input and makes it usable. "Hilux 4WD light flashing after a water crossing, no codes, actuator still moving," or "6L80 harsh shift hot, no codes, fluid checked," turns into a structured diagnostic context and 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 replies are the part that matters most, and not only for ease of use. A user with dirty hands, gloves, a torch, and a scan tool can move through the diagnosis by tapping, not typing. The buttons also feed the model cleaner state and cut junk input. It is a data-quality layer wearing a usability hat.
It tells you how sure it is. A confidence meter shows whether the current answer rests on strong, moderate, or weak context: how much vehicle detail was given, whether codes or scan data exist, whether the fault is confirmed. A low-confidence answer is not useless; it tells you what is missing. In training, that teaches the real lesson: diagnosis is evidence-based.
The design principle
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. That makes the output more reliable, more consistent, and easier to assess.
The model is held to diagnostic discipline. It is not allowed to say "replace the transmission." It is steered toward "this could indicate X, confirm Y before replacing parts, check A then B, confidence is moderate because scan data is not yet available." The tool is built around diagnostic thinking, not answer generation.
How it works
Four layers: a mobile-first interface, a guided input and state layer, the model and API reasoning layer, and a demo fallback. The front end owns the question flow and renders the result. The backend takes structured context, builds a controlled prompt, calls the model, and returns a fixed response shape. The UI owns the layout; the model only fills a controlled 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.
Two decisions make it real. It was built with a higher-capability model and moved down to a Sonnet-class model for runtime, on the logic that once the diagnostic structure is constrained, the live task does not need the expensive model. A constrained path on a cheaper model is what makes it commercially viable. And the live API is not the only load-bearing wall: a demo mode shows the full experience even when the API is down, rate-limited, or switched off for a presentation. Failures never surface as stack traces or broken JSON; the user gets a clean fallback and keeps their input.
What it is, and what it is not
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 can suggest fault paths, test priorities, and missing data. 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.
A chatbot waits for the user to know what to ask. Diagnostic Buddy helps the user work out what to ask next. That is the point.
Evidence
