Plain-language maintenance log

A small facility’s technicians write what they did in plain language: “replaced the belt on pump 3, it was fraying”, rather than filling out a rigid form. Someone still needs that turned into a real log entry: which piece of equipment, what was done, when, filed against that equipment’s own history rather than as a flat note nobody can search. And every so often, a note buried in otherwise routine language is actually describing something that needs a person’s attention now, not at the next scheduled review.

The pipeline is three steps: extract a fixed record from the note, find the equipment it concerns in a small graph of what the facility has, and let the model decide whether this is routine or needs flagging.

Example run

"Replaced the belt on pump 3, it was fraying and
starting to smell hot before I shut it down."

Walkthrough

The three steps compose the runnable code already on the structured output, knowledge graphs and function calling pages, unmodified in shape, each written against the site’s own shared examples (structured output reads a warranty record, knowledge graphs walks from a part to its warranty class) rather than a literal maintenance note. Composing them means keeping the same functions and swapping in this job’s own schema and its own two-hop walk (equipment to line, line to last-serviced date), and offering save_log_entry and flag_for_review in place of lookup_part. Nothing here ships that exact pair of tools yet; what’s illustrated above is the shape those three pages’ code already is, run for this job.

The run above shows a note that reads as routine until its last clause. Extraction pulls a clean record (equipment, action, a condition field carrying the technician’s own words) and the graph walk finds pump 3’s line and that it was serviced two months ago, nothing unusual on its own. The model reads the condition field’s “starting to smell hot” alongside a worn belt and calls flag_for_review instead of save_log_entry, the one decided_by: "model" step in the whole run; a note that only said “replaced the belt, routine wear” would have taken the other tool instead, with nothing else in the pipeline changing. Either way your code links the entry into the equipment’s history; what the flag adds is a review task on top of it. Log both tools offered, which one was called, and the graph path behind the record, so a note that should have been flagged and wasn’t can be found afterwards.

What to measure

Knowledge graphs and function calling are each scored on their own by the site’s shared 60-question set (see docs/EVALS.md); structured output is not. None of the three answers this job’s actual task, so build a labeled set of real or synthetic notes instead: the record a person would extract, the equipment it should link to, and whether a facilities lead would flag it. Watch whether the escalation tool gets called on the notes that actually need it, and only those, checked against a sample of routine entries to confirm none should have been flagged instead. Add one measure specific to the graph: how often the named equipment fails to resolve to anything in it, which is a data problem, not a model one. No result file exists for any of the three on this task yet, so this recipe cannot claim a score for any of it.

Variations

• Add human approval before saving an entry whose equipment id the graph doesn’t recognize: a missing link and a safety concern are different problems and shouldn’t share one gate.
• Move to a single agent if escalating ever needs more than one lookup: checking recent notes on similar equipment before judging this one.
• Route by facility area first with routing if the same pipeline serves more than one site, each with its own equipment graph.
• Rebuild the graph on a schedule, not on every note; knowledge graphs’ own page is direct about the cost: extraction is expensive, and paid once per equipment change, not per entry.

Design choices