Building a Durable Automotive Diagnostic Workflow

From a diagnostic intake prototype to a durable shop workflow.

A working prototype can prove that an idea is possible. It cannot prove that a repair shop can depend on it.

The first STEP Diagnostics intake prototype demonstrated that an AI-assisted workflow could have a natural conversation with a technician, identify observable facts, preserve source references, and produce a structured summary for review. It also helped us test several product principles: ask one clear question at a time, separate conversation from trusted case state, keep diagnostic authority with the technician, avoid asking the user to select a suspected cause, support English, Spanish, and Russian conversations, and block unsafe transitions when important preconditions are missing.

But the original field-test system still depended on local process memory and browser session state. That was appropriate for controlled experiments. It is not sufficient for a real diagnostic operation.

The work now underway is turning STEP from a field-test prototype into a durable, multi-user workflow.

A diagnostic case must outlive the browser tab

Consider a normal day in a repair shop. A technician starts documenting a vehicle concern. The page reloads. The technician moves to another workstation. A service advisor needs to review the case. Another technician may eventually continue the work. Meanwhile, servers restart, network requests are retried, and multiple updates may arrive close together.

The diagnostic record cannot depend on one browser tab remaining open. It must remain consistent across users, workstations, server processes, retries, interruptions, and reconnects. The browser can display the case and submit commands, but the trusted state must belong to the backend.

Moving from temporary memory to durable state

STEP is adopting PostgreSQL as the canonical store for the production intake workflow. This is not simply a database migration. It changes how the application treats every important transition.

The durable model includes bounded records for:

• organizations and their members;
• confirmed vehicles;
• intake conversations;
• technician and assistant messages;
• current intake state;
• state-transition events;
• summary previews;
• confirmed intake handoffs;
• idempotency records;
• audit events;
• future AI and diagnostic-information operations.

Each record is scoped to the organization that owns it. Large provider responses, raw prompts, authentication material, signed URLs, and licensed diagnostic documents do not become ordinary database fields. The goal is to preserve the case without turning the database into an uncontrolled copy of every external system involved.

What is already working

The first durable vertical slices are now in place. When an authenticated user confirms a supported vehicle, STEP can create a canonical vehicle confirmation and intake conversation in PostgreSQL. The browser receives server-issued identifiers rather than deciding which internal records should be trusted.

Successful intake turns can now be committed as a single transition: the technician message, the assistant response, the validated case snapshot, the audit record, the corresponding event, and the idempotency result. These pieces are committed together. If the transition cannot complete safely, it should not leave behind a partial case update.

A newly started server instance can load the conversation and its transcript using durable identifiers. It no longer needs to depend entirely on the memory of the server that originally created the session.

Why revisions matter

Every conversation has a revision. When the browser submits an update, it includes the revision it believes is current. The backend compares that value with the canonical conversation before accepting the transition.

Suppose two requests are based on revision 12. The first request completes and advances the conversation to revision 13. The second request cannot silently overwrite it as though revision 12 were still current. Instead, the second request encounters a defined conflict and must reload the latest state.

The workflow is: load current case revision, submit technician message, validate expected revision, process and validate response, commit the complete transition, and advance the revision. Revision control is less visible than a new interface feature, but it is essential for a trustworthy multi-user product.

Safe retries without duplicate cases

Retries are another normal part of production software. A request may succeed on the server while the response is lost on the network. The browser cannot know whether it should retry. If every retry creates a new conversation or adds the same message again, the diagnostic record quickly becomes unreliable.

STEP uses operation-specific idempotency keys to distinguish a safe retry from a new action. When the same operation is repeated with the same identity, the application can return the previously committed result instead of duplicating it. If the same key is reused for a materially different operation, the request is rejected.

This helps protect conversation creation, completed intake turns, summary generation, intake confirmation, and later diagnostic transitions. The user should not have to understand idempotency. They should simply be able to retry without damaging the case.

Building for repair-shop organizations

STEP is also moving beyond the assumption of one local user. A repair shop is represented as an organization. Individual employees receive their own memberships rather than sharing credentials. The initial permission model supports roles such as owner, administrator, technician, and viewer.

Authorization is enforced by the backend. Hiding a button in the browser is not considered access control. Every protected request needs an authenticated actor and organization context. Conversations, vehicles, diagnostic cases, provider operations, and audit events remain scoped to that organization.

Cross-shop vehicle history is denied by default. Any future shared vehicle-history feature would require a separate privacy, legal, redaction, and abuse-prevention decision.

What we are working on now

The current work is completing the durable intake path beyond individual conversation turns. That includes loading the canonical conversation before summary generation, persisting summary previews for an exact conversation revision, preventing an old summary from being confirmed after the case changes, creating an immutable confirmed intake handoff, safely replaying an already committed result, moving remaining summary and confirmation state out of local server memory, and restoring the React interface after reload or reconnect.

The confirmed handoff is especially important. A diagnostic workflow should not begin from whatever the conversation currently says. It should begin from a specific summary that the technician reviewed and confirmed at a known revision. If the conversation changes, that confirmation must no longer apply automatically.

AI operations also need durability

Today, a successful completed turn can be stored durably, but the provider operation itself is not yet fully recoverable while it is in progress. That is a separate production problem.

A future durable operation model will allow STEP to record AI and diagnostic-information work before executing it through background workers. These operations will need bounded retries, timeouts, cancellation, stale-result rejection, rate and cost controls, backpressure, failure handling, and polling or event-based UI updates.

A late AI response must not overwrite a newer case. A provider timeout must not erase the technician's message. Restarting a server must not make an in-progress operation impossible to understand. These capabilities are planned as distinct stages rather than one broad rewrite.

Why this matters in the shop

The visible product experience may still look like a conversation. Underneath, STEP is becoming a structured diagnostic record. That distinction matters when a technician returns to the vehicle tomorrow, another employee needs to review the intake, a correction invalidates the previous summary, a request is accidentally submitted twice, a service restarts, two updates happen at nearly the same time, or the diagnostic workflow needs to show exactly what was confirmed.

A useful diagnostic assistant cannot simply produce good answers. It must preserve the integrity of the case.

What STEP is not claiming yet

This work does not mean the complete STEP workflow is production-ready. Important gates remain: durable summary and handoff integration, recovery of pending vehicle selections, complete browser reload and reconnect behavior, durable background provider operations, rate limits and usage controls, backup and restore validation, load, soak, and failure testing, privacy and retention review, and operational monitoring and rollback proof.

Guided diagnosis also remains a later stage. It will begin only after intake produces a durable, confirmed handoff and the diagnostic evidence workspace reaches the required safety boundary.

Building the foundation before scaling the promise

It is tempting to measure an AI product by how impressive one conversation looks. We believe the harder test is what happens around that conversation. Who owns the facts? What happens after a retry? Can the case survive a restart? Can two technicians work without overwriting each other? Can the application prove which summary was confirmed? Can an external AI response be rejected when it arrives too late?

Those questions are shaping the current phase of STEP Diagnostics. We are moving from a prototype that can conduct an intake to a system that can preserve the integrity of that intake across people, devices, and interruptions. A diagnostic workflow becomes useful only when the shop can depend on the case after the conversation ends.