Skip to content
DocEE-DOC-101
TitleElastic Service
RevA
Issued2026-08-21
Sheet1 / 1
Used onEE-DOC-001

Venture sheet/ R1 · 75%

Knowledge out to the field. Events back in.

Rung R1 — the revenue engine, and the proving ground for everything Elastic builds.

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.

Master planFollow the build

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.
  1. 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.

  2. 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.

Fig. 2 — a knowledge workflow, as traversal

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.

Fig. 1 — the service loop, signedCompiled from a signed model and verified on every build: loop polarity is derived from the edge signs rather than asserted, variables that feed nothing back are rejected, and the traversal in Fig. 2 is checked to terminate in the event that re-enters this loop. Edit an edge and the figure, the table below, and this page either agree or the build fails.
Table 1 — loop audit. Polarity is the product of each loop's edge signs.
LoopPathSignsPolarityReading
R1events → evidence → knowledge → wrench time → events+ + + +reinforcingThe flywheel: work captured is work made cheaper next time.
R2knowledge → time-to-procedure → frustration → tenure → knowledge− + − +reinforcingRetention. Engineers who can find the procedure stay, and the ones who stay hold more of it.
R3knowledge → time-to-procedure → repeat visits → wrench time → events → evidence → knowledge− + − + + +reinforcingCoverage buys back the capacity that repeat visits consume.
B1events → evidence → wrench time → events+ − +balancingThe honest one. Capture costs wrench time; if it costs more than retrieval saves, the design fails.

The diagram is convertible to a stock-and-flow model — documented knowledge, tacit knowledge, and captured-but-unintegrated evidence are the stocks. In that reading the design claim is a single inequality: retrieval savings must exceed capture cost. Stated that way it is testable rather than persuasive, and the sources for both diagrams live in the repository beside the page.

Position

The last mile is unowned.

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.

§ 01 / Placement rung R1

R1 earns the ladder.

Service takes the largest share of the planned budget and sits at the top of the ladder because it is the rung that meets a customer first. The rule from the master plan is not softened here: no rung spends money the rung above it has not already earned. What Service earns funds miniFactory, whose fixtures, spares and tooling come back into Service. Robotics is designed to deploy inside Service contracts. Sentinel instruments are designed to feed the Service audit trail. The Thinktank exists to produce the people who can staff it.

There is a second reason, and it is the one that matters to the software. Elastic runs its own service contracts, and Service is designed to host every Elastic software product in production. We are the first customer of everything Elastic writes. Nothing is sold on a claim we have not already had to live with under our own downtime limits.

Table 1 — Budget allocation by venture. Published on purpose; see § 05.
RungVentureAllocFunction
R1Service75%Revenue engine. Funds every rung below.
R2miniFactory20%Makes components — including its own.
R3Robotics4%Non-humanoid material handling.
R4Sentinel0.8%EM-wave detection, all wavelengths.
R5Thinktank0.2%Field-engineer training.
Aerospace0%Design lab. Drawings only.

§ 02 / First article in design

The Graph Generator, on a manual anyone can check.

The first article is the Graph Generator — the engineering-knowledge-ingesting CMS named on the homepage — holding the knowledge workflows described above. The first demonstration is deliberately small and deliberately checkable: 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.

Pick a symptom and watch it walk to a candidate fault, to the check that confirms it, to the procedure that resolves it, to the recalibration that follows. Anyone can open the source page and see whether the graph told the truth. The domain we are aiming at is medical and industrial; the demonstration corpus is public on purpose, so the mechanism can be inspected without a customer's data or a customer's permission. This is not a deployment. It is a first article, and it is in design.

§ 03 / Falsifiers open questions

Four things would have to be true.

  1. The graph must be cheaper to keep current than the manual it replaces. This is loop B1 stated as arithmetic. If maintaining nodes and edges costs more than reissuing pages, the argument fails at the second revision.
  2. 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.
  3. Capturing field work as it happens is a trust problem before it is a technical one. An engineer wearing a recording device in a treatment room is a design constraint in a regulated environment — consent, scope, retention, and who is permitted to replay what. We would rather state that here than discover it at a customer site.
  4. 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 four ways this design is wrong.

§ 04 / Status no solicitation

Forming — Sunnyvale, California

Elastic Engineering is forming in Sunnyvale, California. Service has no product in the field, no pilot, no customer and no revenue. What exists is research, a design, and a plan for the first demonstration. This sheet states an intent; it offers nothing and solicits nothing.

If part of it intersects a problem you own, open a conversation.

PartnersInvestorsPress

End of sheet · EE-DOC-101 · Rev A · Service is R1 of EE-DOC-001.