ZDash: AI Diagnostic Agent
In developmentZDash started with my own car. I was using an outdated diagnostics program to read ECU data, then feeding those readings into ChatGPT to help me understand the problem and work through repairs. Moving information between the two tools gave me the idea: build a diagnostics app that connects directly to the ECU and includes an AI agent that can investigate the data.
That became ZDash, a Windows diagnostics app for Nissan and Infiniti CONSULT-I vehicles. I built an OpenAI-powered diagnostic agent with hybrid service-manual retrieval, schema-defined LangChain tools, LangGraph investigation control, and browser-based parts research.

The problem
A useful diagnostic assistant needs more than a fault code and a generated explanation. It needs relevant vehicle history, fresh ECU observations, applicable service-manual evidence, and follow-up checks from the driver. I built ZDash’s AI workflow to gather that information through controlled tools, validate the evidence behind its answers, and preserve investigation progress across messages and application restarts.
What I built
- Hybrid RAG over factory service manuals. Prepared 83 Z32 manuals covering 8,618 pages. OpenAI’s text-embedding-3-small and PostgreSQL/pgvector combine semantic retrieval with full-text search. Retrieved passages retain manual year, section, and page metadata for citations.
- A tool-using diagnostic agent. Integrated GPT-5.4 mini through OpenAI Responses with selective access to vehicle details, fault codes, telemetry, recordings, maintenance, and other ownership records. LangChain’s schema-defined tools execute diagnostic retrieval, giving the model access to relevant information without sending the entire workspace upfront.
- Fresh ECU evidence. Added controlled access to one fresh, read-only engine fault scan and up to four telemetry snapshots per message. Results expose timestamps, units, freshness, channel support, missing values, and simulator labels. Application code checks the active vehicle and connection before and after operations.
- Browser-based parts research. Integrated OpenAI Decisions to select actions from observed browser controls, with Electron validating and executing those actions. LangChain’s structured-output parser processes extracted product data before grounding and fitment checks. Saved product cards retain inspected links, source quotes, available prices and part numbers, and missing application details.
- Persistent LangGraph investigations. Implemented preparation, assessment, tool execution, answer, and waiting stages. A driver-check tool saves a specific question and pauses the investigation; the next reply resumes it with fresh permissions and runtime checks. SQLite checkpoints survive restarts and encrypted backup/restore.
Why I built it this way
- Combine semantic and exact-term retrieval. Symptom descriptions benefit from semantic matching, while fault codes and component names need exact terms. Reciprocal-rank fusion combines both rankings, with full-text fallback when embeddings are unavailable.
- Give LangChain and LangGraph distinct responsibilities. LangChain handles diagnostic tool schemas and structured product parsing. LangGraph controls execution stages, saved state, and pause/resume behavior. Grounding, permissions, and fitment remain application-enforced checks.
- Enforce permissions outside the model. Tool availability depends on the request: diagnostics, shopping, records, or a combination. Shopping-only requests cannot access ECU tools. Explicit exclusions and permissions are checked again before execution. Browser research blocks purchasing, sign-in, uploads, and downloads.
- Validate evidence beyond its schema. Structured output establishes a usable shape; it does not establish factual support. Manual citation checks reject invented references, including references written in prose. Product grounding preserves inspected evidence, while local fitment rules check year, chassis, exact engine, and applicable restrictions.
- Bound execution and define recovery. Investigations allow eight tool rounds, sixteen executions, and four manual searches, with request deadlines. Interrupted ECU and browser operations are not automatically replayed. Unsaved results remain unknown, while completed checkpoints support continuation. A deterministic local fallback remains available when cloud AI fails.
What I learned
I learned to build an AI workflow around explicit evidence and state. Retrieval relevance, citation validity, and factual support require separate checks. Tool schemas define inputs, while application code controls access and validates results. Persistent investigations also require clear recovery rules: saving a conversation does not guarantee that every interrupted operation produced a durable result.
Evidence & current limits
Verified 122 tests, 17 UI workflows, build/typecheck, persistence, encrypted backup/restore, and browser behavior. These checks demonstrate implemented workflows; they do not establish diagnostic accuracy or physical-car reliability. Physical-car and packaged-Windows acceptance remain open. Supplier coverage is incomplete, and a process crash during browser research can lose listings collected before the tool returns. Manual retrieval remains a development prototype; the Z32 corpus does not establish coverage for other vehicles.
More on the retrieval pipeline
Offline extraction preserves the manual year, section, and PDF page when splitting text into chunks. The documented corpus contains 8,861 chunks, of which 7,795 are embedded. The corpus has 1,052 flagged pages; OCR and diagram-only material need review.
Online retrieval embeds the question, runs vector and full-text searches, and fuses their rankings into up to eight passages. Exact-year results precede adjacent-year fallback. Numbered excerpts accompany vehicle context through generation and citation validation.
A reference matching a retrieved passage is a structural check. Whether the passage supports the answer needs a labeled grounding evaluation. The current corpus and loopback gateway are for private development; other catalog vehicles do not inherit Z32 coverage.
What’s next
Moving forward, I’m working on adding mobile and Apple CarPlay support to bring ZDash’s diagnostics and AI-assisted workflows into more accessible, in-car experiences.
More project screens
Explore the interface. Select an image to view it at full size.

