Skip to content
Skild Robotics Operations

Incident response

Scope

What to do when an incident occurs: how to respond on-site, when to escalate, and how to file an Incident Report.

Purpose

Capture enough detail to support debugging, continuous improvement, and any required regulatory or customer-facing response. The remote operator owns the report submission; the on-site operator owns physical intervention. [SOURCE: SOP V3 §XX; ABM Ops Manual §"Issue Reporting"]

Required inputs / tools

SourceForm / DashboardOwner
Universal GO2forms/d/e/1FAIpQLSeC5T0...per April 2026 GO2 ABM SOP §XX
ABM/LGA intakeforms/d/1Z9JovFV.../editper sites/lga/incident-response-lga
ABM dashboardspreadsheets/d/1Jcf7q1r.../editanway@skild.ai
Vegaforms/d/e/1FAIpQLSfdHS2Q...per Skild Vega SOP §Incident Reports

Plus: deployment Slack channel; phone (for photographic documentation if available).

Reportable issues

Report all of the following, regardless of whether they resolved on their own: [SOURCE: SOP V3 §XX "Reportable Issues"; ABM Ops Manual §"Issue Reporting"]

  • Loss of localization during navigation.
  • Camera stream not available.
  • Robot metrics data not available.
  • Robot unresponsive to teleoperation.
  • Failure to reach a waypoint during navigation.
  • Robot crashing due to overheat.
  • Robot crashing due to low battery.
  • Any requirement for on-site physical intervention, including E-Stop usage.
  • Any collision, fall, hardware anomaly, or unexpected behavior.

Procedure

Before — during the incident

  1. Safety first. Stop or sit the robot using the appropriate method (software stop preferred; physical E-Stop only for dramatic hazards). See /general/safety/.
  2. If a physical hazard is developing (crowd, wet floor, approaching animal/child), the on-site operator intervenes physically.
  3. If the remote operator loses connection or control: the on-site operator takes appropriate safety action per site procedure (initiate stop, move to safe staging position, or E-Stop if required). [SOURCE: ABM Ops Manual §"On-Site Oversight and Safety Intervention"]

During — physical event (fall, collision, tip-over)

  1. Engage the E-Stop immediately.
  2. Do not right the robot while powered.
  3. Once E-Stopped, carefully reposition on a flat surface.
  4. Before powering back on: inspect for visible damage, verify cable connections, confirm LiDAR is flush and clean, check camera positions. [SOURCE: SOP V3 §V "Response to Falls or Tip-Overs"]
  5. Submit an Incident Report before resuming operations.

A fall can displace internal cable connections that are not visible externally. Always inspect before restarting. If anything appears abnormal, report it and do not resume until cleared. [SOURCE: SOP V3 §V]

After — Report submission (remote operator)

Remote operator submits the Incident Report form immediately after the issue resolves. If an issue cannot be resolved remotely, the remote operator contacts the on-site operator for physical intervention. [SOURCE: SOP V3 §XX]

  1. Open the appropriate Incident Report Form (see Required inputs / tools).
  2. Fill in required information: see “Required information” below.
  3. Submit.
  4. For incidents involving collision, injury, or airport/site escalation: notify management directly. [SOURCE: SOP V3 §XX]
  5. Notify Skild through the designated Slack channel.

After — Post-resolution

  • If an issue appears repeatable or patterned, document it explicitly. Submit a formal report via the Incident Report form (not just a Slack message). [SOURCE: SOP V3 §XVIII "Shutdown" item 5]

Required information in every report

Capture enough detail to support debugging: [SOURCE: SOP V3 §XX + ABM Ops Manual]

  • Time of the incident.
  • Location (site + zone + nearby landmark). At LGA: terminal + CCA/CCB/Food Court + landmark.
  • What the robot was doing at the time (starting a loop, turning a corner, docking attempt, etc.).
  • Operational mode (autonomous or teleoperation).
  • Observed symptoms and any alerts on screen.
  • Corrective actions taken and the outcome.
  • Environmental factors (crowd density, obstacles, layout changes).
  • Photographic documentation if available.

Roles

  • On-site operator: physical intervention, ground-truth assessment, escalation to site/airport authorities if needed.
  • Remote operator: report submission, system-side analysis, coordination with engineering.
  • Site escalation: management direct notification for collision / injury / airport / customer-facing escalation.

Severity ladder (escalate further when any of these apply)

  1. Standard issue (localization loss, missed waypoint, recoverable thermal sit) → file Incident Report; resume after resolution.
  2. Hardware anomaly (collision, fall, visible damage) → file report; do not resume until cleared.
  3. Public-facing incident (injury, property damage, security/airport involvement) → notify management directly first, then file report.
  4. Repeated occurrences of same issue across multiple shifts → escalate as a pattern, not a one-off. Flag in report.

Quality checks

  • Time, location, mode, and corrective action are documented in the form (the form rejects vague answers).
  • A Slack message to the deployment channel summarizes the event with the form link (so others know it happened).
  • For physical events: the robot was inspected before re-powering.

Common failure modes

IssueLikely causeAction
Operator unsure whether something is “reportable”Threshold ambiguityDefault to report. The reportable list above is broad on purpose.
Report submitted without enough detailSubmitted during the incident, not afterSubmit after resolution. Use a notes app to capture details in real-time, then transfer.
Same issue keeps happening, no aggregationEach occurrence reported as a fresh one-offFlag explicitly: “Recurring — see prior reports on [date].”

Escalation

  • Injury, collision, or airport/site authority involvement → notify site management directly, before or in parallel with the form.
  • Robot damage requiring out-of-service → deployment Slack + site coordinator. Do not deploy a damaged robot.
  • Security or law enforcement interaction → cooperate (see /general/safety/), then file report.

Source notes

  • [SOURCE: GO2_Standard_Operating_Procedure_V3.docx] §V, §XVIII, §XX.
  • [SOURCE: GO2_Standard_Operating_Procedure_ABM.docx] (April 2026, Tyler Kugima) §XX. Authoritative for ABM-LGA.
  • [SOURCE: ABM Operations Manual.docx] §“Issue Reporting”.
  • [SOURCE: Skild Dexmate/Vega SOP] §Incident Reports — Vega-distinct form.