Knowledge Graph for Field Operations
A semantic memory layer over equipment, spare parts, and five years of service history gives the existing diagnostic model asset-specific context it never had — no retraining required.
The challenge
Technicians diagnosing equipment failures worked across three disconnected systems — service manuals, a ticket history database, and a spare parts catalog — with 1,200 distinct equipment classes and 8,500 part SKUs in the field. Before this engagement:
- Technicians searched three separate systems for every diagnosis, with no link between them
- Senior technicians' tribal knowledge of recurring failure patterns was never captured anywhere
- The diagnostic model gave generic recommendations with no visibility into a specific asset's repair history
- Repeat failures on the same unit weren't linked to prior interventions, so technicians re-diagnosed from scratch
- Parts lookup sat in a separate catalog, causing repeat truck rolls when the wrong part arrived on-site
- Mean time to resolution averaged 4.2 hours per ticket, with a meaningful share spent just gathering context
How it works
Better retrieval, same diagnostic model
Rather than retrain or replace the diagnostic model, the engagement built the context layer it was missing:
- 01
Modeled equipment, spare parts, and service interventions as entities and relationships in a knowledge graph
- 02
Backfilled five years and 180,000 historical service tickets into the graph, linking each to the asset it touched
- 03
Connected every asset node to its full intervention history and recurring symptom patterns
- 04
Built a retrieval layer that surfaces relevant graph context to the existing diagnostic model at query time
- 05
Left the diagnostic model itself untouched — no retraining, no architecture changes
- 06
Deployed a technician-facing lookup interface combining diagnosis, history, and parts in one place
- 07
Set the graph to update continuously as new service tickets close
What we built
Key capabilities
Asset-specific context retrieval
The diagnostic model now receives a given unit's actual repair history, not just its equipment class.
No model retraining required
All of the improvement comes from better retrieval and context — the underlying diagnostic model was never touched.
Fewer repeat truck rolls
Parts lookup is now tied to the specific asset and fault pattern, reducing wrong-part dispatches.
Institutional knowledge captured continuously
Every closed ticket adds to the graph, so patterns senior technicians used to carry in their heads are now queryable by anyone.
Before vs after
What changed for field technicians
- Mean time to resolution
- 4.2 hrs → 2.9 hrs
- Diagnostic context
- Generic by equipment class → specific by asset history
- Parts and history lookup
- 3 disconnected systems → 1 interface
- Institutional knowledge
- Tribal, undocumented → captured in the graph
Business impact
What it changed
31% faster resolution
Mean time to resolution fell from 4.2 to 2.9 hours once technicians could see an asset's actual history instead of generic guidance.
No model risk introduced
The gain came entirely from retrieval and context — the diagnostic model itself required no retraining or validation cycle.
Fewer wasted site visits
Linking parts lookup to asset-specific fault history reduced the wrong-part dispatches that had been driving repeat truck rolls.
Technology stack
“The fastest fix here wasn't a smarter model — it was giving the model it already had something worth remembering.”
Keep reading