Layer 4: Operations
Fleet Management
Fleet Management is the inventory and control surface for the physical side of the platform. It maintains robot identity, topology, grouping, lifecycle state, software lineage, and operational segmentation so every other surface knows which physical assets exist, how they are organized, and what context applies to them.
What This Surface Owns
Fleet Management owns the digital representation of the deployed robot estate.
- Maintain identity and lifecycle state for every managed robot.
- Organize fleets by site, customer, program, robot class, or custom grouping.
- Track hardware, sensor, and software configuration over time.
- Provide the targeting surface for deployment, updates, monitoring, and operations workflows.
It is the digital twin inventory layer of the platform, not only an asset list.
Core Capabilities
Robot identity
- Stable identity for every robot, even as software, model, or site assignment changes.
- Hardware revision, compute profile, sensor suite, and commissioning metadata attached to the same record.
- Calibration and operational state attached to the robot lifecycle.
Fleet segmentation
- Group by site, facility, customer, environment, robot type, or internal program.
- Use the same grouping for rollout targets, monitoring scopes, maintenance planning, and reporting.
- Support overlapping logical views without duplicating underlying robot identity.
Lifecycle state
These states matter because deployment, update, and maintenance logic depend on them.
- commissioned
- active
- staging
- maintenance
- quarantined
- retired
Configuration visibility
- Current model and artifact state.
- Current runtime config and update status.
- Service history and recent incidents.
- Sensor or hardware differences that affect rollout eligibility.
Digital Twin Principle
Every physical robot should have a durable software-side twin in the platform.
That twin should know:
- where the robot is
- what hardware it contains
- what software and model it is running
- what maintenance events have affected it
- what incidents and interventions have occurred
- which datasets or operational evidence it contributed to
This is what lets the platform connect field behavior back to training and release decisions with precision.
Relationship To Other Surfaces
Upstream and shared dependencies
- **Identity, Access & Governance** scopes who can act on fleets and robots.
- **Unified Data Model** preserves fleet identity as part of the entity graph.
Downstream consumers
Fleet Management is the shared physical context layer for the rest of operations and deployment.
- **Deployment Manager** targets fleets and cohorts for rollout.
- **Update Manager** tracks compliance and drift per robot.
- **Telemetry & Monitoring** segments signals by robot, site, and cohort.
- **Maintenance System** attaches service history to the robot lifecycle.
- **Human-in-the-Loop Operations** routes intervention and operator context by fleet structure.
Why This Matters Architecturally
The platform cannot operate fleets safely if robots are only referenced as ad hoc IDs in logs and scripts.
- Rollouts require clear targeting.
- Monitoring requires stable segmentation.
- Service work requires durable robot history.
- Data provenance benefits when collection sessions stay linked to real robot identity and context.
Fleet Management gives the rest of the platform a stable understanding of the physical world it is controlling and learning from.
Why Teams Care
Control
Teams know what robots exist, where they are, and what state they are in.
Safer rollout
Cohort targeting and configuration visibility reduce invalid deployments.
Operational clarity
Maintenance, incidents, and telemetry all attach to the same robot lifecycle record.
Scale
One platform can manage multi-site, multi-customer, and heterogeneous fleets without flattening real operational boundaries.