Deployment Intelligence and Command: product boundaries

Physical AI programs fail in two different modes. During deployment, they fail when evidence, root cause, corrective action, and retesting are incomplete at acceptance. After go-live, they fail when supervised operations cannot explain what operators saw, acknowledged, and commanded before a failure became an engineering problem.

Those failure modes need different record structures and different workflows. A single undifferentiated tool usually privileges one mode and starves the other. Dagmont separates the modes into two products and connects them at escalation so each mode gets a purpose-built record without inventing a third product category.

Deployment Intelligence owns the deployment case: incident observations, evidence artifacts, hypotheses, corrective actions, retest plans and outcomes, reports, audit trails, and customer acceptance decisions. It answers questions such as what failed during commissioning, what evidence confirms the root cause, what changed, whether the change held under retest, and whether the customer accepted the system. It is not a live robot command console.

It receives operational context from Command when a live failure escalates, then owns the investigation and acceptance work that follows.

Command owns supervised live operations: robot and mission state visible to operators, alert handling, acknowledgements, command history, and the creation of Deployment Intelligence cases from live failures. It answers questions such as which alert fired, who acknowledged it, which commands were issued, what the mission looked like at the time, and what operational package was handed to investigation. It is not the system of record for root cause analysis, corrective action verification, retesting, or customer acceptance.

Those remain Deployment Intelligence responsibilities after escalation.

Escalation is the only intentional seam. When a live failure needs structured investigation, Command creates a Deployment Intelligence case with the operational snapshot and command history. From that moment, investigation work happens in Deployment Intelligence.

Operators do not recreate the same narrative in email. Engineers do not open a blank case and ask the floor to remember the night shift. The seam is also a decision boundary: escalation does not automatically return the robot to dispatch.

Return to operation remains a human decision under site control procedures after the investigation record supports that decision.

Three mistakes appear repeatedly. First, treating Command acknowledgements as acceptance evidence. An acknowledgement proves an operator saw an alert; it does not prove root cause or customer acceptance.

Second, opening Deployment Intelligence cases without an operational snapshot, which forces investigators to reconstruct live context from incomplete notes. Third, using Deployment Intelligence as a live console for routine alert handling, which buries operational noise inside investigation cases and makes acceptance reviews harder to read. The corrective practice is simple: use Command for supervision, use Deployment Intelligence for investigation and acceptance, and escalate deliberately when the work changes character.

Customers and partners understand the boundary fastest when it is stated as two sentences. Deployment Intelligence proves what failed, what evidence supports the cause, what changed, what retesting showed, and what was accepted. Command shows how live operations were supervised and how failures moved into that investigation record.

Share the Command product page for live operations questions and the Deployment Intelligence product page for acceptance and investigation questions. In proposals and runbooks, name the escalation owner and the return-to-operation owner explicitly so nobody assumes the software makes those decisions.

• State in the runbook that Dagmont has two products and no third product category
• Assign commissioning and acceptance work to Deployment Intelligence cases
• Assign live alert acknowledgement and command history to Command
• Require an operational snapshot whenever Command creates a Deployment Intelligence case
• Prohibit treating alert acknowledgements as customer acceptance evidence
• Document the human owner for return-to-operation decisions after escalation
• Train support partners on which product to open for which question
• Review one recent live failure for boundary leakage during post-incident review