Venture sheet/ R2 · core
Recognise the event. Keep the record.
The product: a knowledge graph built from what actually happened at the machine, in three layers.
We build a knowledge graph from the real world: events recognised at the machine as they happen, organised by an engineer's judgement into a graph that walks symptom to fault to check to procedure, and written back into the system of record. The graph is built to hold what the manual never did — what was tried, in what order, and what the machine did in between.
Load
The record that would make a machine troubleshootable has never been kept.
A fault is cleared at a customer site, and the machine goes back to work.What the engineer saw before the fix is nowhere.What they did next, and in what order, is typed up from memory the following day.What the machine was doing while they worked was never measured at all.A machine that troubleshoots would need a corpus of troubleshooting, the way language models needed a corpus of language.No such corpus exists, because every observation that belongs in it lived in one engineer's hands and left with them.Nothing was recording.
- Event recognition
- Turning what the instruments saw and what the engineer did, at the machine, on one clock, into a record that can be named, found and compared.
Layer 1 — Sentinel
Recognise the event at the machine, on one clock.
Sentinel is the intake. Instruments on the cabinet — the band the machine talks on, a thermal camera, whatever the equipment criteria on EE-DOC-004 admit — and the engineer's own narration, written to one time-stamped log. The pipeline is built to recognise events in that stream: a reading that moved, an action that was taken, the order they came in.
An event is not a data point. It is a thing with a name: the fan stalled, the interlock opened, the engineer reseated the board. Recognition is what turns telemetry into something a person can be asked about later.
Layer 2 — Curator
Organise it the way an engineer would.
Curator is the human layer. Events are organised and categorised into the graph — what belongs with what, which symptom points at which fault, which check settles it, which procedure follows. That organisation is judgement, not a model, and it comes from eleven years of doing it by hand at two in the morning.
The techniques are the company's. They are not published on this sheet, and the sheet does not pretend otherwise: what is stated here is that the layer exists, what it takes in, and what it produces — a graph an engineer can traverse from the symptom in front of them.
Layer 3 — Return
Write it back where the organisation already looks.
Return closes the loop. The organised record goes back into the CRM — the system the dispatcher schedules from and the manager reports from — so the system of record holds what actually happened, not what was typed from memory the next day.
Nothing is replaced. The CRM stays the CRM. What changes is that the field event arrives already recognised and already organised, and the next field event is scheduled from a record that is true.
Mechanism
A record that teaches where to point the next instrument.
The three layers close on themselves. Every event recognised at the machine is organised into the graph; every traversal of the graph in the field is itself an event — what was looked up, what was tried, whether it worked — and it comes back through Return. Every pass points the next one better.
The loop has a brake. Recognition only runs where the engineer consents to be on record and the customer admits instruments onto the machine; where either is withdrawn, the intake stops and the graph holds what it had. The balancing loop is drawn, not assumed.
End of sheet · EE-DOC-102 · Rev A · The case for it is Elastic Service (EE-DOC-101). What would have to be true, and what exists today, is on Status (EE-DOC-004).