rFabric
Get early access

Release Management

Deployment & Updates

Deployment & Updates are responsible for activating approved artifacts on real fleets through governed rollout policy and long-tail operational update control. They decide where a release goes, in what order, under which checks, with which canary behavior, and how failures trigger rollback or escalation.

What This Surface Owns

Deployment & Updates own rollout execution, activation policy, OTA coordination, and long-tail per-robot update state.

  • Select rollout targets across fleets, sites, cohorts, and robot classes.
  • Stage activation using canary, cohort, or progressive rollout strategies.
  • Monitor rollout state and trigger promotion, pause, or rollback actions.
  • Keep deployment history explicit and attributable.

Release Packaging creates deployable units. This surface owns both the initial rollout decision and the ongoing update lifecycle once those units reach the field.

Rollout Capabilities

Targeting

  • Deploy by fleet, site, robot class, hardware revision, program, or customer boundary.
  • Support deployment cohorts that reflect operational risk and business context.
  • Avoid “all robots at once” assumptions in heterogeneous or customer-facing fleets.
  • Respect region, sovereign-zone, and customer residency boundaries when rollout policy requires them.

Staged rollout

  • Canary one robot or one small cohort first.
  • Progress by percentage, environment, geography, or operational confidence.
  • Promote only when health checks and cohort behavior support the next step.

Health-aware activation

  • Evaluate post-activation signals such as success rate, intervention rate, crash frequency, latency drift, or thermal anomalies.
  • Pause rollout automatically when thresholds are crossed.
  • Keep health logic tied to the release and cohort context, not just generic error counts.

Rollback

  • Revert a rollout when canary or cohort behavior indicates unacceptable risk.
  • Preserve the rollback event, trigger reason, and restored artifact in the lifecycle record.
  • Trigger related incident or maintenance workflows when a rollback points to deeper issues.

Deployment Contract

Before activation, the Deployment Manager should know:

  • which artifact is being activated
  • which approved model it derives from
  • which target robots or cohorts are eligible
  • which rollout policy applies
  • which health signals define acceptable rollout behavior
  • which previous artifact is the rollback target

This makes deployment a governed transition between explicit states, not a best-effort push.

Operational Modes

Lab and staging rollout

  • Fast validation on internal fleets.
  • Good for early evidence and operational sanity checks.
  • Often lower approval overhead but still fully traceable.

Production rollout

  • Stricter policy, approval, and cohort logic.
  • May require phased activation over time or by site.
  • Designed for customer-visible or mission-critical environments.
  • Can also require region-specific control planes, local activation windows, or sovereign deployment topology for regulated customers.

Hotfix deployment

  • Fast path for rollback or urgent corrective release.
  • Keeps the same audit and evidence model even when speed matters.
  • Useful when a fleet issue requires rapid but still controlled action.

Relationship To Neighboring Surfaces

Upstream

  • **Model Registry** defines which candidates are approved.
  • **Artifact Builder** provides the signed, validated release unit.
  • **Evaluation & Release** provides the evidence and policy that justify rollout.
  • **Fleet Manager** provides the target inventory, segmentation, and operational grouping.

Downstream

  • **Update Manager** continues lifecycle management after the initial rollout decision.
  • **Telemetry & Monitoring** validates rollout health and cohort behavior.
  • **Maintenance System** handles deeper incidents or blocked rollouts.
  • **Human-in-the-Loop Operations** may absorb early operational risk during staged autonomy rollout.

Why This Matters Architecturally

The Deployment Manager is where approval becomes action.

  • It carries release evidence into operational policy.
  • It treats rollout as a monitored, reversible lifecycle transition.
  • It recognizes that fleets are segmented, heterogeneous, and risk-sensitive.
  • It ensures the platform can say not only what was approved, but exactly how it reached production.

Without this surface, release discipline ends at the registry boundary and real rollout becomes an ad hoc operations exercise.

Reliability And Governance

  • Rollouts are policy-aware and auditable.
  • High-risk activations can require explicit approval.
  • Cohort state, pause actions, rollback triggers, and final outcomes are durable deployment records.
  • Customer, site, and program boundaries remain enforceable across rollout actions.
  • Region-specific compliance constraints can also shape where a release may be activated, who may operate it, and which reporting path applies after rollout.

Why Teams Care

Safer rollout

Staged activation and health-aware policy reduce fleet-wide regressions.

Operational clarity

Teams can see which cohort received what, when, and why rollout progressed or stopped.

Better recovery

Rollback is a governed lifecycle event, not an emergency shell command.

Scalable release operations

One control plane can manage rollouts across many fleets and environments without flattening real operational differences.