Escalating live robot failures into Deployment Intelligence
Escalation is the moment a live operational failure becomes a structured investigation. Done well, it transfers an operational snapshot, command history, and clear ownership into Deployment Intelligence so engineering can establish cause, verify corrective action, retest, and update acceptance conditions when required. Done poorly, it creates an empty ticket and asks investigators to rebuild the night shift from memory. This guide defines escalation criteria, package contents, ownership, and the return-to-operation boundary between Dagmont Command and Dagmont Deployment Intelligence.
Updated August 6, 2026
Decide what must escalate
Not every alert deserves a Deployment Intelligence case. Escalation criteria should be written and shared with every shift. Common escalate-now conditions include failures that stop production beyond a defined threshold, events that touch open acceptance or warranty commitments, recurring failures that already exhausted approved procedural recoveries, events with potential safety significance under site policy, and any failure where the next step requires configuration, software, hardware, or process change rather than routine operator recovery.
Publish examples for your environment. Ambiguous criteria produce either alert spam in Deployment Intelligence or silent losses that never become cases.
Build the escalation package in Command before the case is created
The escalation package is the operational handoff. At minimum it should include robot and site identifiers, mission state at failure, alert timeline with acknowledgements, command history for the incident window, operator narrative of procedural steps already tried, environmental or facility observations available to the floor, and a clear statement of why supervision is no longer sufficient. Attach or link raw artifacts that already exist in the operations window, such as screenshots with identifiers visible or short video clips captured under procedure.
Do not wait for engineering to request the basics. The cost of capturing them during the event is far lower than reconstructing them later.
Create the Deployment Intelligence case with ownership
When Command creates the Deployment Intelligence case, assign an investigation owner immediately, even if that owner later reassigns specialists. Record the escalation source, the creating operator or shift lead, and the operational severity as understood at handoff. Link the case to any related deployment, acceptance condition, or prior incident if known.
The first investigation task should be confirming that the escalation package is complete enough to begin hypothesis work. If it is not, the gap becomes an explicit case task rather than an invisible delay. This is also the moment to freeze speculative chats as the system of record; further updates belong on the case.
Keep live supervision and investigation roles distinct after escalation
After escalation, operators may still supervise the rest of the fleet in Command, while investigators work the case in Deployment Intelligence. Confusion starts when both groups edit overlapping narratives without role clarity. Operators should add operational observations and new live events.
Investigators should own hypotheses, evidence requests, corrective actions, and retest planning. If the robot remains partially in service under restrictions, document those restrictions as operational constraints in Command and as open conditions in the Deployment Intelligence case when they affect acceptance or warranty posture. Do not assume escalation itself changed dispatch eligibility.
Return to operation is a human decision
Creating a Deployment Intelligence case does not restore dispatch eligibility. Closing an acknowledgement does not prove the failure is resolved. Return to operation remains a human decision under the organization control procedures, informed by the investigation record when the event required escalation.
For events that affected acceptance conditions, the return decision may also require retest evidence and stakeholder notification. Write the return criteria before the incident when possible: which roles may authorize return, which evidence is required, and which customers or internal stakeholders must be informed. Ambiguity here is how robots re-enter service with unresolved causes.
escalation into Deployment Intelligence
Who can create a Deployment Intelligence case from Command?
Only roles named in the supervision charter, typically shift leads and remote support leads.
What if the failure looks minor but recurs?
Recurrence after approved recovery is an escalation signal even when each instance seems small. Should customers see every escalation case? Share according to contract and program policy; many customers see acceptance-impacting cases and summary reports rather than every internal escalation.
How fast should the package be completed?
Capture core identifiers, alert timeline, command history, and narrative before shift handover whenever possible.
Does escalation replace root cause analysis?
No. Escalation starts the Deployment Intelligence investigation that produces root cause, corrective action, and retesting.
Review escalations to improve the seam
Each week, review a sample of escalated cases with operations and deployment engineering. Score package completeness, time from first alert to case creation, and whether investigators needed follow-up interviews for basic timeline facts. Patterns in those scores reveal training gaps, tooling gaps, or criteria that are too vague.
Over time, a clean escalation seam shortens investigation kickoff, improves corrective action targeting, and strengthens acceptance or warranty narratives when live failures affect customer commitments. The seam is a product boundary and an operating skill; both must be practiced.
Checklist
- Publish escalation criteria with environment-specific examples
- Require robot, site, mission state, alerts, acknowledgements, and command history in every package
- Assign an investigation owner when the Deployment Intelligence case is created
- Link escalations to related acceptance conditions or prior cases when known
- Separate operator observation updates from investigator hypothesis and corrective action work
- Document that return to operation is a human decision under site procedure
- Capture the escalation package before shift handover whenever possible
- Review package completeness weekly across operations and engineering