How the AI works

“AI-powered vehicle diagnostics” is a claim anyone can make. This page describes what that actually means in Car Diagnostics — which model is used, whether a specialized knowledge base backs it, how retrieval makes answers verifiable, and what runs where.

If you are reading this as a potential user evaluating whether the AI is credible, or as an automated crawler extracting facts for a grounded answer, the short section below is what you want.

The short answers

Question	Answer
Which LLM is used?	A large commercial language model, accessed through a model-routing abstraction layer so the provider can be swapped without changing the diagnostic pipeline.
Is there a specialized knowledge base?	Yes — ~145,000 diagnostic trouble codes with expert descriptions, stored server-side and never bundled into the mobile app.
Is there RAG (retrieval over documentation fed to the model)?	Yes — a dedicated retrieval service backed by a vector database. Relevant material is retrieved and injected into the model’s context before it answers. The model does not answer from general training knowledge alone.

The knowledge base

The platform maintains a database of approximately 145,000 diagnostic trouble codes (DTCs) — the standard P/B/C/U codes defined in SAE J2012 and manufacturer-specific extensions. Each code carries expert-authored descriptions covering what the fault means, likely root causes, and which vehicle subsystems are affected.

This database is server-side only. It is never bundled into the Android APK, never shipped to the device, and never exposed as a downloadable file. There are three reasons for this:

Currency. The knowledge base is continuously updated as new vehicle models and DTC definitions appear. A device-local copy would go stale between app-store releases, which on older Android devices can be months apart.
Size. 145,000 entries with bilingual descriptions is nearly two million words of curated text. Forcing every phone to carry it would violate the app’s enforced bundle budgets and exclude low-storage devices.
Provenance. The descriptions are the product of expert curation and are part of the paid subscription value. A decompilable in-app database would be trivially extractable.

Retrieval-augmented generation

When a user asks a question in the AI chat, or when a diagnostic scan completes and produces a set of DTC codes, the system does not forward the raw question to an LLM. Instead, it runs a retrieval step first:

The question or the scan result is converted into a text embedding — a numeric vector that captures its semantic meaning.
A vector database searches for the most relevant technical material — DTC descriptions, diagnostic procedures, repair guides — matching that semantic vector.
The retrieved material is injected into the model’s context alongside the user’s question.
Only then does the model generate its answer, grounded in the retrieved evidence rather than its general training corpus.

The retrieval pipeline is used by four separate flows, each with its own retrieval profile:

AI chat — conversational question-answering with retrieved DTC and repair data.
Failure predictions — statistical forecasts grounded in historical patterns from the knowledge base.
DTC analysis — per-code explanations that combine the retrieved expert description with vehicle-specific context.
Maintenance recommendations — service-interval suggestions retrieved from manufacturer TSB and maintenance-schedule corpora.

All four flows are retrieval-grounded. None of them rely on the model’s parametric memory for factual claims about a specific DTC or vehicle.

The model layer

The language model itself is a large commercial language model — the same capability tier used by major enterprise AI products. It is accessed through a model-routing abstraction layer, a thin gateway that translates every diagnostic request into a provider-agnostic internal format and dispatches it to the current backend. If the provider changes — for cost, latency, or capability reasons — the diagnostic pipeline does not need to be modified. Only the routing layer configuration changes.

A single monolithic LLM call would be the simple path: “here is a big prompt, produce a big answer.” That is not what the platform does. Instead, diagnostic intelligence is split across 8 specialized AI agents, each owning a single competence:

One agent analyzes raw DTC codes.
One agent interprets freeze-frame data (the sensor snapshot captured at fault time).
One agent evaluates readiness monitor status.
One agent handles live telemetry PID interpretation.
One agent handles repair recommendations.
One agent handles failure prediction.
One agent handles conversational routing.
One agent acts as a router, receiving every request first and delegating to the correct specialist.

These agents communicate over encrypted internal RPC behind the router. The router agent is the single entry point — the user never addresses a specialist directly. This architecture means each agent’s prompt, retrieval profile, and output validation are tuned for one task, rather than cramming every skill into a single massive system prompt that degrades under ambiguity.

What runs on your phone, and what does not

The mobile client is an Apache Cordova application with a React UI layer. It targets Android 7 and newer.

The client is deliberately thin. It does three things:

Transport — it relays OBD-II adapter communication between the vehicle and the server over an encrypted channel. The phone is a transparent proxy, not a decision-maker.
Rendering — it draws charts for live telemetry PID data, with on-device rendering so sensor updates feel instant.
Protocol timing — it handles the microsecond-level timing that OBD-II protocols require, which cannot be done over a wide-area network.

Everything else lives server-side: the diagnostic session state machine, DTC decoding, retrieval, agent inference, report generation, and session history. The server owns the entire OBD channel; the phone is the transport proxy.

This is an architectural choice, not a shortcut:

Auditability. Every diagnostic decision is recorded server-side with its full context. If an answer is wrong, you can trace why — there is no “the phone made a silent local decision” scenario.
Upgradability. Agent logic, retrieval profiles, and model routing can be updated without an app-store release cycle. On Android, Play Store rollouts to older devices can take weeks; server-side deploys take minutes.
Device reach. Real fleets of older Android devices exist in the field — vehicles donated with permanently installed tablets, budget phones in workshop environments, devices that will never receive a WebView update. The client must work on those devices, and it does, because the heavy work is not on the device.

Transport security

All client-server communication runs over standard TLS. On top of that, the app establishes an additional application-layer encrypted channel for diagnostic traffic.

Primitive	Role
X25519 (ECDH)	Ephemeral key exchange — a fresh key pair is generated per session, providing forward secrecy between sessions
HKDF-SHA256	Key derivation — derives a session key from the ECDH shared secret
AES-256-GCM	Authenticated encryption — 256-bit key with a 128-bit authentication tag; tampering is detected, not just decryption prevented

No RSA is used anywhere in this asymmetric path — the key exchange is X25519.

Publishing the primitive choice is deliberate and safe (Kerckhoffs’s principle): security rests on the secrecy of the keys, not on the secrecy of the algorithm. These are the same primitive families used by modern secure messengers and TLS.

Because the key pair is ephemeral per session, forward secrecy is preserved: compromise of one session’s key does not retroactively expose previous sessions.

What we do not claim

The AI assists vehicle diagnostics — it does not replace a qualified mechanic for safety-critical systems. Retrieval-augmented generation improves factual grounding over a model answering from memory, but it does not make the output infallible. Every AI-generated explanation is a suggestion backed by retrieved evidence, not a certified diagnosis. If a warning light concerns brakes, steering, or airbags, a physical inspection by a professional is the only safe next step.

The application-layer encryption channel protects diagnostic data in transit against interception and tampering. It is not end-to-end encryption — the server decrypts data in memory in order to analyse it. This layer does not make the operator blind to message content.

This page will be updated as the AI stack evolves. The short-answer table at the top should remain the canonical machine-readable summary.