Where the company stands.
The dossier behind the two venture sheets, in one place: what we claim, what order the plan reads in, what has to be on the bench, what ships first, what would prove us wrong, and what exists today.
§ 01 / Position model open
The record is the product. The model is open.
The data mostly exists. PLM and SLM systems hold it — bills of material, change history, the engineering source of truth — in interfaces built for engineers at desks. Field service management systems run who, when and where: scheduling, dispatch, parts, the app that closes the ticket. Neither owns the how. Between the repository and the ticket sits the diagnosis and the repair, which is the part the technician is standing in front of. A general-purpose wiki has no structure to traverse, so it becomes one more thing to search.
None of this requires novel science. Graph traversal is old mathematics, the procedures are already written, and the wearable is bought off a shelf. What is missing is the arrangement. We are building the last mile into the technician's hands.
We do not state how this is sold, because we have not earned the right to: no instrument is in the field, and a business model on a sheet with no first article is a forecast dressed as a plan. What is stated is what the graph is, what it is built from, and what would have to be true.
Machines are monitored. Engineers are not. The party that records both, on one clock, and organises the result the way an engineer would, is building something neither the monitoring vendor nor the manual publisher holds. We are building to be that party.
§ 02 / Reading order the set
The case, the core, the equipment, and where it leads.
Service, EE-DOC-101, is the case: the cost of a service call is the cost of retrieval, and every sheet after it is an answer to that. It states the loop, not who runs it — the company's position on contracts is deliberately open until there is a first article to argue from. What is not open is the loop itself: knowledge out to the field, events back into one record, and it holds whoever is holding the wrench.
The knowledge graph, EE-DOC-102, is the product the case argues for: a knowledge graph is the retrieval. Its three layers are one product, not three ventures, which is why they share a sheet and a number.
miniFactory is the equipment: what has to be on the bench to build the prototype hardware, stated as criteria in § 03. Robotics, the Thinktank and the Aerospace design lab are expansion vision — where the record leads once it exists. None of it is scheduled or funded by the sheets above it.
§ 03 / Equipment criteria under construction
Under construction.
This section is being written and is not yet issued. The rest of the sheet stands.
§ 04 / First article in design
A symptom walked to a fix, on a manual anyone can check.
The first article is one publicly published service manual, ingested into nodes and edges, with a hand-authored symptom-to-fault overlay laid on top of it, because manuals ship procedures and almost never ship diagnosis. One symptom is walked to a candidate fault, to the check that confirms it, to the procedure that resolves it, to the recalibration that follows — on the prototype hardware, recorded as it runs. Anyone can open the source page and see whether the graph told the truth.
It is deliberately on public material: the mechanism can be inspected without a customer's data or a customer's permission. The domain we are aiming at is medical and industrial. This is not a deployment. It is a first article, and it is in design.
§ 05 / Falsifiers open questions
Six things would have to be true.
- The engineer must consent to being on record, and keep consenting. Scope, retention and who may replay what are design constraints, in a regulated room more than anywhere. An opt-out that is not real makes the corpus coerced and the recording stop. We would rather state that here than discover it at a customer site.
- Observation and action must land on one clock. If the instrument log and the engineer's narration cannot be aligned to the second, there is telemetry and there is a report, and no event to recognise.
- Off-the-shelf instruments must be good enough. The equipment criteria in § 03 admit catalogue parts only. If an instrument has to be invented, this has become a research program, and the ethos sheet, EE-DOC-002, says we do not bill for discovery.
- The graph must be cheaper to keep current than the manual it replaces. The balancing loop stated as arithmetic. Curator is human judgement; if keeping nodes and edges organised costs more than reissuing pages, the argument fails at the second revision.
- The source data must be ingestible without a rewrite. PLM and SLM systems hold the structure. Getting it out in a form worth traversing is an engineering problem, not a formality.
- Someone has to let their field events into one record. The loop only closes if the CRM is the CRM. That is a decision a customer makes, not a feature we ship.
They are the six ways this design is wrong.
§ 06 / Forming no solicitation
Forming — Sunnyvale, California
Elastic Engineering is forming in Sunnyvale, California. Nothing is in the field: no instrument, no pilot, no customer, no revenue, no corpus. What exists is research, a design, its equipment criteria, and a plan for the first article. This sheet states where the company stands; it offers nothing and solicits nothing.
If part of it intersects a problem you own, open a conversation.
sam@elastic-engineering.com
End of sheet · EE-DOC-004 · Rev A · Used on the cover sheet. This sheet is replaced, not amended.