Fleet Release

Fleet Release is the FastCrest control plane for robot software updates. It manages release approval, cohort rollout, health gates, rollback, and release receipts while robot inference and robot control stay local.

Use it when the deployment problem is fleet speed: many similar robots, one tested update, and a business need to move production forward without treating every unit as a separate manual deployment.

What It Controls

Fleet Release owns the software-release plane:

• desired version per robot, site, line, or cohort
• artifact manifest, hash, compatibility, and rollback slot
• staging, canary, production, hold, promote, and rollback state
• heartbeats, health gates, and release receipts

It does not replace ROS, PLCs, local safety controllers, kitchen automation logic, or the VLA runtime. The robot-side agent calls the customer’s existing install, pre-flight, switch, health, and rollback hooks.

Release Flow

1. Publish a signed artifact bundle.
2. Attach a release manifest with hashes, compatibility bounds, pre-flight checks, and rollback instructions.
3. Assign the release to a staging or canary cohort.
4. Agents download to the inactive slot and run local pre-flight checks.
5. The control plane promotes, holds, or rolls back based on health gates and operator approval.
6. Fleet Release exports a receipt showing what ran, where it ran, who approved it, and what gates passed.

Robot Agent Contract

The robot-side agent is intentionally thin. A customer integrates it beside the existing robot stack and implements adapter methods such as:

def install_artifact(manifest): ...
def run_preflight(manifest): ...
def switch_slot(version): ...
def report_health(): ...
def rollback(previous_version): ...

The agent should continue running the last known good version if the cloud is unavailable. Rollout should be convergent: the control plane declares desired state, and each robot reports whether it has reached that state.

Manifest Shape

A release manifest should include:

• release id and artifact version
• artifact URLs and cryptographic hashes
• robot family and hardware compatibility bounds
• migration and pre-flight steps
• health gates and timeout policy
• rollback target and rollback checks

The first pilot schema lives in the Fleet Release product repo and is designed to be small enough for a customer to review before integration.

Pilot Checklist

Start with one robot family and one operational path.

• one artifact source, such as a container registry or object store
• one staging cohort and one production cohort
• one robot-side adapter for install, switch, health, and rollback
• one release receipt format accepted by engineering and fleet operations
• one pricing unit that matches how the customer operates, usually workspace plus site or release volume rather than per-robot tax

Relationship To Tether

Tether proves a deployable runtime artifact: export parity, safety guard configuration, latency, replay traces, hashes, and deployment proof.

Fleet Release moves that artifact through a production robot fleet: cohort assignment, health gates, rollback, and operational receipt.