Reconcile stop signals with operator reason codes, group recurring stops, assemble the evidence around an event and propose candidate factors — an engineer establishes the cause and owns the countermeasure.
Take stop signals from the historian, PLC tags or MES alongside the reason code and notes the shift entered.
02
Pull what surrounded the stop — alarms, process values, changeover, shift, material lot and the last intervention.
Reason
03
Reconcile the recorded stop against the signal — start, end, duration, asset — and mark where the two disagree.
04
Trace a stop that cascaded down the line back to where it started, and mark blocked and starved time as such.
05
Group stops that behave like the same failure, and hold apart the ones that only share a reason code.
Decide
06
Propose candidate contributing factors, each with the evidence under it and what would rule it out.
07
Flag events too thin to investigate, and estimate the stopped time that never reached the record at all.
Out
08
Present the event, its group and the candidate factors for an engineer to accept, reject or send back.
09
Track whether a countermeasure held at 30 and 90 days, and reopen the group when the stops return.
→Product statement
The agent assembles and proposes. An engineer or a team establishes the cause, decides the countermeasure and owns whether it worked.
Example workflow
One stop, end to end
AgentHuman
1Stop detectedHistorian, PLC tag, MES downtime record or the line's own counter
2Record reconciledSignal start, end, duration and asset against the reason code and notes the shift entered
3Event groupedMatched to an existing recurring-stop group, or opened as one of its own
4Evidence assembledAlarms, process values, changeover, shift, material lot and the intervention before it
No human action required
Stages 1 to 4 run without a person in the loop — reconciliation, grouping and evidence assembly finish before anyone is asked to read anything. An event that will not reconcile ends that stretch early.
5DecisionSplits on whether the event reconciles and the evidence is sufficient
Reconciled, evidence sufficient
Reaches the engineer as a proposed factor set.
Unreconciled or thin record
Goes to a person with the gaps named, and no factors.
Reliability or CI engineer
Reads the event, its group and the evidence under each proposed factor, then decides what the cause was and what to do about it.
Accept factor · Reject · Request more evidence
Cause agreed — handed back▼
6Findings filedWritten to the downtime record only where write access and policy allow; the cause field stays empty
7Outcome evaluatedReason-code accuracy, engineer agreement, cascade attribution and what the countermeasure did at 90 days
Rejections
Factors the engineer rejects are counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Declaring the cause of a downtime event.
Approving or scheduling a countermeasure.
Deciding that a countermeasure worked.
Naming an operator, crew or shift as the cause.
Automation boundaryAgent acts unaided
✓Reconcile stop signals against reason codes and mark the disagreements.
✓Group recurring stops, and hold apart the ones that only look alike.
✓Assemble the alarms, process values, changeover, lot and shift context around an event.
✓Propose candidate factors with the evidence for each, and flag records too thin to work.
Write actions run only inside the approval boundaries agreed during implementation. The cause field is not one of them.
Overwriting a reason code the shift entered.
Re-attributing downtime between assets in the record.
Changing the reason-code taxonomy or capture thresholds.
Raising, changing or closing a maintenance work order.
Example output
One stop, annotated
Everything the agent proposes stays attached to the event and the signals it was assembled from.
Downtime output · single stop eventIllustrative example
Stop signal
Reason code entered
Next asset
Candidate factor
Confidence
Cause
Filler 2 stopped for 14 min 20 s
Changeover, keyed at shift end
Starved 11 min
Cap-feed jam, not changeover
78%
Not established by the agent
As receivedThe signal, the code the shift keyed and what the next asset did — as recorded, contradictions included.
Evidence usedAlarm three minutes beforeNo recipe change loggedNine like stops in 30 days
Why this factor is proposedNo recipe change was logged; one alarm precedes nine stops. Correlation, not cause.
ActionAccept factorRejectRequest more evidence
What the score decidesConfidence decides how much evidence an engineer should demand, not who is at fault.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every recorded stopHistorian, PLC, MES or the line counter
03Reconciliation
Apply the plant's own taxonomy
Use the client's reason-code list, asset hierarchy, line topology, shift pattern and changeover records.
01Approved path
Hand the engineer an assembled event
Alarms, process values, lot and changeover context arrive gathered against the stop, so an investigation starts from a record rather than from a query.
02Human review
Show which stops share a pattern
Recurring stops are grouped and the thin or contradictory records are separated out, so the meeting argues about evidence instead of about the data.
04Build an evidence trail
Retain the signal, the entered code, the reconciliation, the sources read, the proposed factors, the engineer's decision and the 30- and 90-day check.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Machine & process dataPLC and SCADA tags · historian · OPC UA Alarm and event logs · edge collectors
MES & downtime captureSiemens Opcenter · Rockwell FactoryTalk In-house MES · operator terminals
Maintenance & work ordersSAP PM · IBM Maximo Fiix and Limble · work-order history
Agent
Downtime root-cause analysis
Reconciles the stop Assembles the evidence Proposes candidate factors
Production contextShift calendars · changeover records Lot genealogy · material receipts
The stops that get recorded well are the long ones, and they dominate any plant-wide figure. Short stops, night shifts and cascades are where the entered code and the signal disagree. Reported by slice, not in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Stops under two minutes
7.2%
3.8×
Review
Night and weekend shifts
5.5%
2.9×
Review
Cascaded line stops
3.7%
1.9×
Watch
Long stops, single asset
1.5%
0.8×
Normal
Bar: mis-recorded-event rate vs. long-stop baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
A rejected factor is worth as much as an accepted one
What an engineer throws out says something the evidence did not. So does a countermeasure that held for a month and then quietly stopped holding.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Stops return in a closed group, or reason-code accuracy slips on a reviewed sample.
02Diagnose
Traced to the signal, the entered code, the asset map, the grouping rule or evidence that was never pulled.
03Improve
The reconciliation rule, grouping threshold or evidence set changes under change control, with a named approver.
04Verify
Re-run over stored events from that cohort, including the factors the engineer rejected.
05Learn
The rejected factor becomes a negative case, and the group keeps its 30- and 90-day check.
Learn → DetectThe return edge. A group is closed only after the 90-day check, and when a conclusion is withdrawn the people who acted on it are told.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, signals and taxonomy, reconciliation and grouping, evaluation, review workflow, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Workflow discovery and automation boundary.
02Historian, PLC and MES signal assessment.
03Asset hierarchy and line-topology mapping.
04Reason-code taxonomy review and mapping.
05Stop-signal reconciliation logic.
06Cascade and blocked/starved attribution.
07Recurring-stop grouping and thresholds.
08Evidence assembly from alarms and context.
09Candidate factors, confidence and rule-outs.
10Unrecorded-stop study on the pilot line.
11Engineer review and rejection workflow.
12Countermeasure tracking and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne line, one asset groupProductionPlant-wide downtime recordAdvancedMulti-line / multi-plant
Introduced at Pilot
Stop-signal and reason-code reconciliation✓✓✓
Recurring-stop grouping✓✓✓
Evidence assembly around an event✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Client reason-code taxonomy mapping—✓✓
Candidate factors with evidence and rule-outs—✓✓
Cascade and blocked/starved attribution—✓✓
Engineer review and rejection workflow—✓✓
Observability and evaluation—✓✓
Introduced at Advanced
Countermeasure durability tracking——✓
Multi-plant and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on signal sources, asset and line topology, reason-code taxonomy, number of lines and plants, review controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your reason-code list and how operators actually key it→Reason-code taxonomy review and mappingWeek 2
02Asset hierarchy and how the line is physically connected→Asset hierarchy, line topology and cascade attributionWeek 1
03Access to the historian, PLC tags and MES downtime records→Signal assessment, then stop-signal reconciliation logicWeek 2
04A sample of events an engineer has already worked through→Reconciliation baseline and the reviewed-sample comparisonWeek 3
05Investigations that reached the wrong conclusion→Evaluation suite, regression cases and failure-mode testingWeek 4
06Where your capture threshold sits and what falls under it→Unrecorded-stop study on the pilot lineWeek 5
07Named reliability or CI engineers to review events→Engineer review workflow, then pilot events and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy. Week 5 carries both the unrecorded-stop study and the first supervised review sessions.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Workflow discovery, asset hierarchy and line topologyW2Signal access, reason-code taxonomy and reconciliation logicW3Cascade attribution and recurring-stop groupingW4Evidence assembly, candidate factors and failure-mode testingW5Unrecorded-stop study, supervised review sessions and correctionsW6Engineers work live events, then Agent Care starts
Reading the bandThe unrecorded-stop study runs in week 5, before anyone builds a Pareto from this data. A chart drawn from an incomplete record is worse than no chart.
At the end of W6Engineers have worked real events from the assembled record alongside their existing process, and the first 30- and 90-day countermeasure checks are already scheduled.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Manufacturing AI agent
Build a downtime agent around your own stop records.
Show us how a stop reaches your system today, your reason-code list, and one recurring stop nobody has settled. We'll reconcile a month of your own events against a sample your engineers have already worked, and show you what the record cannot tell you.
