Architecture Monograph
How to replace the human analyst at the keyboard — but not the human judgment — with a closed-loop team of AI agents that finds the root cause, forecasts what happens next, and asks a person before it does anything that matters.
Across five case studies — battery fade, NVH, weld resistance, isolation faults, brake corrosion — the method never changed: define the symptom, list candidate causes, screen them statistically, reject the confounders, abduce the best explanation, confirm it with a physical signature, then forecast the future and decide what to do. This document turns that repeatable method into a framework of cooperating AI agents. Numbers are computed by real tools, not guessed by a language model; physics decides whether a cause is even possible; and a human signs off at the few points where being wrong is expensive or unsafe. The loop does not stop at the diagnosis: it forecasts remaining life, recommends a fix, watches whether the fix worked, and remembers the case for next time.
The five reports all walk the same path. That path is the specification for the agents.
Every case study followed one pipeline: a symptom is observed; hypotheses are drawn from a small set of failure-mode families (mechanical, thermal, electrical, software, manufacturing, usage, environmental); a statistical screen finds what correlates; confounders are rejected by holding variables constant and by asking whether a physical mechanism even exists; the surviving explanation is reached by abduction; it is confirmed by a signature unique to the cause (a control-chart sawtooth, a diurnal peak, an order-tracking spike); the root cause is stated; a mitigation is designed; and a prognosis forecasts what happens with and without the fix.
Because the steps are explicit, they can be handed to agents. But three of them carry real consequences — declaring a root cause, approving a fix, and acting on a fleet — so those get human gates. The goal is not full autonomy; it is to do the slow, repetitive 90% automatically and bring a person in for the 10% that needs judgment or carries liability.
Read it top to bottom as authority, bottom to top as flow. People sit at the top and approve. The orchestrator plans. A team of specialist agents does the work, checked by a verification layer, computing through deterministic tools, all standing on a foundation of data and knowledge. A feedback bus along the bottom closes the loop. The diagrams below are interactive — hover or tap any block for what it does; the workflow can be played step by step, and the loop animates.
Nothing works without a clean, queryable substrate — and a working version of this framework taught us that the substrate is two kinds of evidence, not one. The structured side is the numeric record: telematics and a feature store (time-series signals, measurements), build genealogy (which part, lot, station, software version went into which vehicle), and charge/cycle logs. The unstructured side is everything that does not fit in a column: service and repair notes, technical bulletins (TSBs) and engineering memos, the DTC catalog that defines each trouble code, OEM manuals and component datasheets (where the physical limits live), and prior RCA reports.
The two flow through different ingestion lanes (the tools of §4.4) into one working context. Numeric data is joined into the feature store. Documents are parsed (and OCR'd), chunked and embedded into a vector index for retrieval (RAG), and mined for entities and relationships that populate a knowledge graph; DTC codes are decoded to the subsystems they implicate. The knowledge graph then links structured genealogy to extracted facts — this VIN runs this firmware; this firmware runs the balancing routine; a bulletin references that routine — so an agent can traverse from a loose symptom to a short list of mechanistically connected suspects. A case memory of past resolved RCAs (with their signatures) and a provenance/audit store complete the layer, the latter keeping every retrieved fact tied to its source document. Practical note: most failed investigations fail here — missing genealogy, un-joined data, or unread documents — not in the reasoning.
The orchestrator (a supervisor agent) turns a symptom into a plan and walks it through a state graph — the explicit workflow of Figure 2, where each node is a stage and edges include loops and human gates. It manages working memory (the current case file) and long-term memory (retrieval over past cases). Think of it as the lead investigator who assigns tasks, not the one doing every calculation.
Each RCA stage becomes a focused agent with a narrow job, its own tools, and a clear hand-off. Narrow agents are easier to test and harder to derail than one do-everything agent.
| Agent | Its one job | Tools it calls | Feeds gate |
|---|---|---|---|
| Triage | Define the symptom, scope, and success criteria | Data query, case retrieval | G1 |
| Hypothesis | List candidate causes across the 7 families | FMEA/taxonomy KB, retrieval | G1 |
| Statistics | Correlation screen; the four-gate test | Code sandbox, stats/ML | — |
| Causal / confounder | Hold variables constant; reject proxies | Causal inference (partial corr, DAG) | — |
| Physics / mechanism | Does a physical pathway exist? Simulate it | Physics sim / surrogate models | G2 |
| Confirmation | Design the signature test (sawtooth, diurnal…) | Code sandbox, signal processing | G2 |
| Synthesis | State the root cause with evidence | — | G2 |
| Mitigation | Propose containment + corrective + robustness | KB, simulation (what-if) | G3 |
| Prognostics | Forecast RUL / probability of failure | Survival models, Monte-Carlo | G4 |
| Reporter | Generate the human-readable report | Templating | — |
The hybrid principle lives here. Agents call deterministic functions: a sandboxed code executor (Python with pandas, SciPy, scikit-learn), statistical/ML routines, a causal-inference toolkit (partial correlation, mediation, DAGs), and physics simulators or surrogates (thermal, electromagnetic, electrochemical). This layer also owns the ingestion tools the data layer depends on: document parsing/OCR, chunking and embedding, entity-and-relation extraction (to build the knowledge graph), a DTC decoder, and retrieval (RAG) over the vector index. The numbers in every figure of the five reports came from tools exactly like these — never from prose; and the priors, meanings, and physical limits came from these retrieval and extraction tools.
This is the layer that makes the difference between a demo and a system you trust. It encodes the four-gate test as machine checks and adds grounding, uncertainty, and a critic.
| Gate / check | Question | How it is enforced |
|---|---|---|
| Association | Does it correlate? | Effect size above a set floor |
| Significance | Could it be chance? | p-value / confidence on held-out data |
| Materiality | Does it explain enough? | Variance explained (ΔR²) threshold |
| Mechanism | Is it physically possible? | Physics agent must find a pathway |
| Grounding | Is the claim backed by data? | Verifier rejects uncited statements; each fact links to its source row or document |
| Uncertainty | How sure are we? | Confidence score attached to every output |
| Evidence fusion | Do independent streams agree? | A root cause must converge statistics + mechanism + graph, not rest on one |
| Critic / reflection | What did we miss? | Second agent argues the opposite case |
The critic deserves emphasis: a dedicated agent whose only job is to attack the leading explanation — propose a confounder, demand the mechanism, look for the alternative. This is the structural defense against an agent falling in love with its first idea. Equally important is evidence fusion: the strongest conclusions are the ones where independent streams agree — a statistical result, a physical mechanism drawn from a datasheet, and a path through the knowledge graph all pointing the same way. A cause backed by only one stream is treated as a lead, not a verdict.
Four checkpoints, each an asynchronous approval with full context and a one-click override. Gates are where accountability lives.
| Gate | Before… | The human sees | Can… |
|---|---|---|---|
| G1 | committing to a hypothesis set | symptom, scope, candidate causes | add/cut hypotheses |
| G2 | declaring the root cause | evidence, confounders rejected, mechanism, confidence | accept / send back |
| G3 | committing to a mitigation | options, trade-offs, simulated effect | choose / revise |
| G4 | acting on the fleet | prognosis, who is affected, risk | approve / stage / hold |
Diagnosis answers "what is wrong"; prognosis answers "what happens next, and when." Once the mechanism is known, a degradation model projects it forward: remaining useful life (RUL), probability of failure over time, and the effect of each mitigation. The engine uses survival / reliability models (Weibull, Cox), physics-of-failure projections, and Monte-Carlo simulation for confidence intervals — exactly the prognosis sections of the five reports (RUL fans, escape-vs-interval curves, fault-day forecasts). Crucially, it reports uncertainty, not a single number, so G4 is an informed decision.
After G4, the chosen action is deployed (an OTA update, a maintenance-interval change, a field bulletin). The loop then monitors the outcome — did the fault rate fall, did Cpk rise, did the dawn fault peak vanish? It runs drift detection to catch the world changing, updates the case memory so the next investigation is faster, and re-opens automatically if the symptom recurs. This is what makes it a loop rather than a one-shot report generator.
Around all of it: full tracing of agent steps and tool calls; an evaluation harness that replays known cases (the five reports make an ideal golden set — the system must reproduce each ground-truth root cause); cost and latency tracking; access control and audit logs; and alignment with safety and quality standards (§10). If you cannot measure whether the agents are right, you cannot relax the gates.
The orchestrator walks the state graph below. Forward edges advance the case; the dashed edges are the loops that make it honest and closed: send-back when evidence is thin, and re-open when a fix recurs.
Walk the weld-resistance case through it. Triage: modules fail the resistance spec. Hypotheses: lot, electrode wear, station, energy, line speed (G1 approved). Statistics: lot and station correlate. Causal: holding electrode wear constant collapses both — they were proxies. Physics: foil resistivity is in spec, so the lot has no mechanism (veto). Confirmation: the SPC sawtooth appears, the fingerprint of tool wear. Synthesis: root cause is the dressing interval (G2 signed off). Mitigation: tighten the interval, add an end-of-line screen (G3 approved). Prognosis: escape-vs-interval curve sets the maintenance set-point (G4 approved). Deploy & monitor: Cpk rises from 0.5 to 3.6; the case is stored. The same graph would have walked any of the other four.
Strip away the detail and the framework is an ordinary feedback controller: sense, decide, act, measure, repeat — with a person holding the decision lever.
And the team that runs it is an orchestrator with specialists and a critic, all sharing one memory and one toolbox.
Do not start at full self-driving. Climb the ladder one rung per case-type as the evaluation harness proves the system reliable. Safety-critical actions stay human-approved indefinitely.
| Level | What the agents do | What the human does |
|---|---|---|
| L0 | Fetch & visualize data | Everything else (the five reports were here, by hand) |
| L1 | Draft hypotheses & run the screen | Approves every step |
| L2 | Full RCA draft with evidence | Signs off root cause & fix (G2–G4) |
| L3 | RCA + prognosis + mitigation proposal | Approves fleet action only (G4) |
| L4 | Auto-resolve known recurring cases | Audits samples; safety stays gated |
| Failure mode | What it looks like | Built-in guard |
|---|---|---|
| Confirmation bias | Agent locks onto its first guess | Critic agent argues the opposite; mandatory confounder search |
| Hallucinated mechanism | A plausible-sounding but unreal physical story | Physics gate must simulate/cite a real pathway |
| Confounder blindness | Blaming a proxy (the supplier-lot trap) | Partial-correlation step is non-optional |
| Data leakage / overfit | Looks great in-sample, wrong in field | Held-out validation; report uncertainty |
| Number hallucination | Model invents a statistic | All numbers come from tools, never prose |
| Automation complacency | Humans rubber-stamp the gate | Gate shows dissent/confidence; critic's objection surfaced |
| Silent drift | World changes; old model still trusted | Drift detection re-opens the case |
| Runaway cost/looping | Agents loop forever | Step budgets, timeouts, escalation to human |
lifelines library).References are pointers for further reading; titles and editions are given at a stable, conceptual level rather than as live links.