From signal to decision

The situation

02:10. A condition-monitoring alert fires: "Gearbox 2 — high vibration, band 3." The operator on shift sees it. They have no basis for judging whether band 3 on this gearbox means anything, and no authority to stop a running line at two in the morning to find out. So they do the correct thing available to them: acknowledge the alert, write a line in the log, carry on.

07:00 handover runs four minutes and covers eleven items. The gearbox is item seven. The day supervisor, who could authorise a stop, hears it as background. On Monday the reliability engineer opens the alert list and finds this one sitting among a week of others, all acknowledged, none actioned.

Nobody failed. The detection worked perfectly. The chain from that detection to a decision was never built.

The principle

A signal is only worth generating if it reaches someone who both trusts it and still has time to act — everything upstream of that handoff is preparation.

The chain has five links: detect, interpret, recommend, decide, act. Most industrial AI effort goes into the first two, because that is where the data is and where the vendors compete. The chain almost never breaks there. It breaks at link four, the handoff to a human, and it breaks in exactly two ways.

Trust. The person receiving the signal cannot see what it was based on, so they cannot tell a real event from the eleventh false positive this month. Unverifiable output gets acknowledged, not acted on. Timing. The signal reaches someone whose window has closed, or someone whose window is open but who lacks the authority to use it. Authority and information sitting in different people is the failure this chain breaks on, and no model fixes it.

This is where AI actually earns its place. Not detecting better — your instruments already detect. Turning a detection into something a tired person at 02:10 can check in ninety seconds and act on.

Worked example

Shown here in Claude.

Job: Convert this alert into a note the night operator can act on or
defer in under two minutes. You are preparing the decision, not making it.

Inputs: Alert — Gearbox 2, high vibration band 3, 02:07. Band 3 has fired
four times in ninety days on this asset; two were traced to load changes,
two to nothing found. Oil sample nine days ago, normal. Line is mid-run,
four hours to the scheduled changeover. Operator on shift cannot authorise
an unplanned stop.

Output: Exactly three blocks.
  WHAT CHANGED — the numbers only, with the comparison baseline.
  WHAT IT COULD MEAN — the two most likely explanations, most likely
    first, each with the evidence for and against it in this case.
  WHAT TO DO NOW — one action the operator can take without authority,
    and one decision named for whoever holds the authority, with the
    deadline it must be made by.

Standard: Every claim points at a stated number or the history above. If
the evidence cannot separate the explanations, say so and name the single
observation that would, plus who takes it. Never write "monitor closely".

The returned note ran nine lines. The part that mattered was the last block:

WHAT TO DO NOW
  Operator, now: log oil temperature and load at 15-min intervals until
    changeover. No stop required.
  Supervisor, decide by 06:00: pull Gearbox 2 at the 06:10 changeover
    for a 20-min inspection, or run to the weekend.
  What would settle it: band-3 spectrum against the two load-change
    events in the history. Reliability engineer, 10 min, from the desk.

Read what that does to the chain. The operator now has an action inside their authority. The supervisor has a decision with a name, an option pair, and a deadline that lands before their window closes. And the whole thing can be checked against the numbers in the note, which is what makes it trustworthy at 02:10.

In your tool

Trust is built by making output checkable. The capability to look for is getting the tool to point back at the exact source it used, rather than asserting.

Product surfaces checked 2026-08-04.

Try it

Pick one alert type your area receives regularly. On paper, write the five links: who detects it, who interprets it, who recommends, who decides, who acts. Put a name against each. Then mark how long the window between detection and useful action actually is.

You are done when you can point at one link and say why it stops there. In physical operations it is nearly always the same two shapes: a person with the information and no authority, or a person with the authority and no information.

Common failures

• Tuning the threshold instead of fixing the handoff. The alert fires too often, so someone raises the limit. Volume drops, trust does not return, and the chain still ends at an acknowledged row. Threshold work is cheap and visible; handoff work is neither.
• A recommendation with no owner and no deadline. "Recommend inspection at earliest opportunity" belongs to nobody and expires never. It survives three handovers and is closed by the failure.
• Letting the model make the call. Asking "should we stop the line?" moves accountability to a system that cannot hold it. Ask it to prepare the decision — options, evidence, deadline, owner — and leave the call with the person who answers for it.