Platform Backbone

Orchestration

Orchestration is the execution model for long-running robotics workflows. It replaces brittle sequencing, hidden scripts, and side-channel handoffs with explicit workflows that read and write the same shared platform entities as the rest of rFabric.

What This Surface Owns

Cross-component workflow execution

The platform needs one runtime for data intake, review, curation, training, promotion, rollout, rollback, maintenance, and intervention loops.

Workflow definitions over canonical platform entities
Explicit states, retries, branches, and rollback paths
Execution history that remains queryable later

Human and machine coordination

Robotics workflows are not fully automated by default. Orchestration keeps approvals, escalation, and operator handoffs inside the same execution model.

Approval steps and manual review gates
Event-driven automation where it is safe
Structured failure handling instead of ad hoc intervention

Execution Model

Visual workflow builder

A visual surface makes lifecycle automation legible to data, ML, platform, and operations teams that need a shared operational picture.

Step, condition, gate, notification, and rollback modeling
Execution views that expose waiting conditions and failure points
Templates for common robotics operating patterns

Code-first workflows

Engineering teams still need workflows in version control. The visual and code-first surfaces should compile into the same runtime so teams are not split into separate execution systems.

Workflow definitions reviewable in pull requests
Parameterization by workspace, environment, fleet, or customer
Safe reuse for release and operations automation

Why Robotics Needs Orchestration

The lifecycle is circular

Robotics does not stop at deploy and monitor. Operational anomalies and intervention sessions become new data and new evaluation scope.

Human gates are structural

Review, approval, teleoperation, and escalation are normal operating behavior, not rare exceptions.

Physical rollout needs rollback paths

A robotics workflow has to encode the path from promotion to canary to rollback to maintenance response with real operational context.

The platform needs reusable patterns

Teams should not rebuild the same data-to-model, release-promotion, and intervention-correction loops for every program.

Example Release Flow

from rfabric import Workflow

workflow = Workflow("release-rollout-loop")
workflow.attach_dataset("folding_v12")
workflow.launch_training(config="sweep.yaml")
workflow.run_evaluation(pack="manipulation_release_v4")
workflow.require_approval(role="ml-lead")
workflow.build_artifact(target="jetson_orin")
workflow.deploy_canary(fleet="staging_fold_arms")
workflow.monitor(metric="intervention_rate", max_value=0.03)
workflow.promote_or_rollback()

Why Teams Care

Operational consistency

Teams standardize high-value lifecycle flows instead of encoding them differently in every script and every program.

Faster iteration

Event-driven transitions reduce dead time between collection, curation, training, promotion, and rollout.

Better governance

Approval, escalation, and rollback logic become explicit platform behavior rather than tribal convention.

Debuggability

When a lifecycle process fails, teams can inspect the exact step, input, branch, and surrounding context that produced the failure.