TraceDX · Own product
Visit TraceDXAn evidence-led diagnostic workspace for automotive technicians.
TraceDX is my own product: a workspace where a technician keeps the messy evidence from a diagnostic job, the reasoning drawn from it, the next test worth doing and the report at the end in one case record.
The problem.
Automotive diagnosis rarely arrives as clean data. A technician moves between scan-tool screens, typed notes, measurements, photographs, PDFs and what the last repair did, and the reasoning that connects them usually lives in their head or in a notebook.
A scan tool reads the vehicle and a general-purpose assistant answers a question, but neither holds the case. What I wanted to build was the layer in between: one record where the raw evidence, what it shows, the current assessment, the tests done and the outcome stay attached to each other.
The systems involved.
TraceDX uses Next.js on Vercel, Supabase Postgres, authentication and private object storage, row-level access controls, OpenAPI.com's Automotive API for vehicle registration lookup, OpenAI models for evidence extraction and assessment drafting, and server-side PDF generation for technician and customer reports.
What I built, and why.
I designed the case model and the loop around it: capture rough evidence, confirm or correct what it shows, form a current assessment, choose the next test that would move the diagnosis furthest, record the result, revise the assessment, then close the case with a report. Every screen is built around the question the technician is actually holding — what should I do next, and why.
Responsibility and boundaries.
TraceDX is my own product, built inside my own business. Nobody commissioned it, so there is no client to credit and no client result to report. I did the product definition, the architecture, the interface, the build, the testing and the deployment, and I set the conditions it has to meet before it goes near a real workshop. It is built to support a technician's judgement: it does not replace a scan tool, published repair data, or the safety-critical procedures a qualified person is responsible for.
Implementation detail.
Raw evidence stays visible next to whatever was extracted from it, and every extracted observation can be edited or rejected before it counts. Next steps are ranked by what they would rule in or out. Reports are generated from the same case record the technician has been working in, so the report and the evidence cannot drift apart.
The outcome.
The product works end to end today: a case can run from mixed evidence, through an assessment and next-test loop, to a private report and a recorded outcome. It has not been through a workshop pilot. I am still completing final test-method and workshop-device checks before deciding whether it is ready for one, so there is nothing here about customer results, adoption or performance — only the software and how it is built.
Related scenarios.
Demonstration screens using fictional cases and vehicle details. No customer data.
