Venture sheet/ R1 · the case
Knowledge out to the field. Events back in.
The case: why a service organisation needs a knowledge graph, and what it costs not to have one.
We reduce a field service organization's logistics and labor costs by building knowledge workflows — every procedure a technician would otherwise memorize or look up. Our workflows will serve the procedure in real time. No escalation delays or logistics miscommunication.
Load
The expensive part of a service call is what the technician doesn't know yet.
A machine is down, and the procedure that would settle the fault already exists.It is in the manual, indexed by part, not by symptom.It is in a case note nobody can find, so a part is guessed at and shipped twice.It is in one engineer's memory, so the call escalates and the customer pays the overtime.It went with the engineer who left, and their replacement is trained from the same manual.Almost none of this is the cost of diagnosis.It is the cost of retrieval.
- Knowledge workflow
- Any situation in field customer service that would require a service employee to memorize or look up a procedure.
Half one — knowledge out
The manual is already a graph pretending to be a book.
Procedures reference other procedures. A remove-and-replace page delegates to a remove-and-install page, and a recalibration follows it. Components connect to their neighbours; symptoms point at candidate faults. Flattened into pages, every one of those links has to be re-derived by the technician, from memory and search, at the machine, under a downtime clock.
Stored as nodes and edges, fault localization becomes traversal. Open the failed component and everything connected to it is already there. Open the symptom and the candidate causes are there with the check that discriminates between them, the procedure that resolves each one, and the flat-rate time, torque figures, warnings and correction code attached to the node instead of pages away.
Half two — events back
The record writes itself while the work is being done.
The other half of the job is administrative: what was done, which part, how long, what the machine did afterwards. Today it is typed up after the fact, from memory, at the end of a long day — which is why audit trails thin out exactly where they matter most.
Elastic Service is designed as a closed loop. Field events flow into the CRM, and the CRM schedules the next field event: one system of record, closed on itself. Consumer wearables are built to remove the administrative half, so the engineer narrates with both hands still on the machine and the report becomes a by-product of the visit instead of an hour at the end of it. The audit trail gets denser instead of thinner.
Mechanism
Two halves of one loop.
Neither half is the product. The circuit is. The graph serves the procedure to the technician, and the closed call re-enters the graph as evidence about which symptom led to which fault and which check settled it. Every pass sharpens the next one.
Drawn as a causal loop diagram, the design states its own failure mode. Capturing evidence takes time away from the wrench, so the loop only pays if retrieval saves more than capture costs — that is the balancing loop below, and it is the first thing the first article is built to measure.
End of sheet · EE-DOC-101 · Rev A · The case for Elastic Knowledge Graph (EE-DOC-102). What would have to be true, and what exists today, is on Status (EE-DOC-004).