Framework Walkthrough
Watching the human-gated agent team diagnose and forecast the battery-degradation case — and, crucially, fusing the structured fleet data with the messy pile beside it: service notes, bulletins, DTC catalogs, manuals, and a knowledge graph.
A fleet monitor flags a cohort of vehicles whose battery state-of-health (SOH) is fading faster than the rest, with a cluster of battery DTCs. The agent team takes it from there: it pulls together the numeric telematics and the unstructured record — repair notes, technical bulletins, DTC definitions, cell datasheets, a prior root-cause report — builds them into one working context backed by a knowledge graph, then runs the diagnosis. A tempting correlation with fast-charging is rejected as a confounder; the real cause is a cell-balancing timing bug in firmware v3.2.1 that lets cell voltages drift apart and over-stress the pack. The prognostics engine forecasts remaining life and the effect of the patch; a human approves the fleet update; the loop then watches the fade rate fall and remembers the case.
A real investigation never starts with a tidy table. It starts with a tidy table and a stack of paper.
The structured side is what you would expect: time-series telematics (SOH, per-cell voltages and the imbalance ΔV, charge events, pack temperatures), build genealogy (which firmware version and cell lot went into which VIN), and fleet signal tables. That is the data the five case studies analyzed.
But beside it sits everything that does not fit in a column: service and repair notes written by technicians, technical bulletins (TSBs), engineering memos, the DTC catalog that says what each diagnostic trouble code means, OEM manuals and cell datasheets with the voltage limits, and prior RCA reports. A human analyst reads all of it instinctively. The framework has to ingest it deliberately — and that is the part this walkthrough makes explicit.
Structured and unstructured sources flow through different ingestion lanes into one unified working context. The numeric data is joined into a feature store; the documents are parsed, embedded for retrieval, and mined for entities and relationships that build a knowledge graph; DTCs are decoded to the subsystems they implicate.
| Unstructured source | How it is processed | What an agent does with it |
|---|---|---|
| Service / repair notes | Parse → embed → extract entities | Hypothesis agent retrieves similar past complaints |
| Technical bulletins (TSB) | Embed + link to firmware/part in KG | Priors: "a balancing TSB exists for this BMS" |
| DTC catalog | Decode code → subsystem + meaning | Triage maps the DTC cluster to the pack/BMS |
| Cell datasheet / manuals | Extract limits (max cell V, temp) | Physics agent checks the over-voltage mechanism |
| Engineering memos | Embed → retrieval | Context on the v3.2.1 release & known risks |
| Prior RCA reports | Embed + store signature features | Case memory: "we have seen this shape before" |
The knowledge graph stitches the structured genealogy (this VIN has this pack, running this firmware) to facts extracted from documents (this firmware runs the balancing routine; this DTC indicates capacity loss; a bulletin references this routine). Agents traverse it to turn a loose symptom into a short list of mechanistically connected suspects.
Each card is one stage. The colored tags show what it reads — structured unstructured graph — plus the tool it calls and the output it produces. Orange cards are human gates.
Continuous monitoring flags VINs whose SOH slope exceeds the fleet, co-occurring with a cluster of battery DTCs. A case is opened automatically.
Decodes the DTC cluster against the catalog (capacity-loss codes implicate the pack/BMS), fixes the affected VIN set, and writes the success criterion: explain the excess fade.
Enumerates candidates (firmware balancing, fast-charging habit, cell lot, thermal exposure, manufacturing…). Retrieval surfaces a prior RCA with a similar fade shape and a TSB touching the BMS balancing routine; the graph already links the symptom to firmware and to fast-charging. Hypotheses are pre-ranked by these priors.
The reviewer sees the scope and the ranked hypotheses with their document citations, trims one implausible item, and approves.
Runs the correlation screen in a sandbox. Fast-charging frequency shows a strong tie to fade (r ≈ 0.74); cell ΔV is strong; ambient temperature looks weak. A naïve read would blame fast-charging.
Partial correlation controlling for cell ΔV collapses fast-charging from 0.74 to ≈ −0.09 — it was riding along with the imbalance. Ambient temperature, freed of the confound, emerges as a secondary accelerant. The graph guides which variable to control.
Pulls max cell-voltage limits from the cell datasheet and confirms a real pathway: a balancing timing error lets ΔV grow, pushing cells past their voltage ceiling and accelerating fade. Fast-charging alone has no such pathway at the observed rates → vetoed as a cause.
Stratifies by firmware version. The v3.2.1 cohort shows the balancing-timing signature — elevated ΔV — that the other versions do not. That version split is the smoking gun.
Sees the converged evidence — statistics, mechanism, version signature — with confidence and the rejected confounder. Signs off.
Recommends a firmware patch correcting the balancing timing, plus an interim charge-ceiling for the affected cohort. Retrieval confirms a precedent patch path in a prior bulletin.
Reviewer weighs the patch vs the interim limit and the simulated effect, and approves the patch for validation.
Runs a Monte-Carlo remaining-life model on the mechanism: median RUL ≈ 20 months (80% CI 16–25) if left alone; probability of failure by 24 months ≈ 89% unfixed versus ≈ 1% with the patch.
Sees who is affected, the prognosis, and the risk. Approves the staged over-the-air rollout.
The patch ships staged and reversible. The loop monitors ΔV and the fade slope to confirm the fix worked, and writes the resolved case — including its signature — back into the knowledge graph and case memory for next time.
The point of the run is that no single evidence stream carries it. The matrix shows which of the three each stage drew on; the decisive root-cause call (synthesis) used all three at once.
The root-cause call at G2 was not a single test. It was the convergence of a statistical result, a physical possibility, and a graph-and-document prior — which is exactly why it survived scrutiny.
Because the mechanism is known, the prognostics engine can project it. The contrast is the whole business case for acting now.
A purely structured pipeline would have flagged fast-charging and stopped. Fusing the unstructured record and the knowledge graph is what supplied the priors, the mechanism, and the meaning — and let the framework reject the confounder and name the firmware bug with confidence, all under human sign-off.