Documentation
Architecture Overview
rFabric is organized as a 6-plane backbone plus 10 product components. The backbone provides shared state, control, governance, and economics. The components own the robotics workflows teams actually operate.
Backbone Planes
The backbone is shared across every lifecycle component. It is what makes rFabric one connected robotics system rather than a stack of point solutions with fragile handoffs.
Unified Data Model & Traceability
Canonical entities, lineage, immutability, and provenance across datasets, models, releases, fleets, and field operations.
Orchestration
Visual and code-first execution for long-running robotics workflows, approvals, retries, rollback paths, and closed-loop automation.
Platform API, CLI & SDKs
One shared control surface for operators, services, robots, CI, and third-party tooling.
Identity & Access
Human, service, and device identities with approval-aware permissions across data, model, release, and fleet actions.
Governance & Tenancy
Workspace isolation, organization policy, regions, environments, and structural controls for multi-team robotics programs.
Metering & Billing
Usage measurement, cost attribution, and economics for storage-heavy, compute-heavy, and fleet-heavy robotics workloads.
Product Components
The lifecycle groupings below are navigational only. The real architectural unit is the component that owns a durable object set or decision surface.
01 - Data Foundation
Become the system of record for robot data, labels, quality decisions, and training-ready dataset versions.
- Data Ingestion & Preprocessing
- Annotation & Labeling
- Dataset Curation & Versioning
02 - Model Development
Turn curated datasets into reproducible runs, evaluated candidates, and promoted model state with explicit evidence.
- Model Training & Evaluation
- Model Registry
03 - Release Management
Package approved models into deployable artifacts and roll them out through governed, reversible operational workflows.
- Release Packaging
- Deployment & Updates
04 - Live Operations
Operate fleets safely in the field and turn deployment outcomes into new data, new evaluation cases, and better future models.
- Fleet Management
- Monitoring, Alerting & Maintenance
- Human Intervention & Robot Control
Cross-Cutting Contracts
The architecture matters because every component writes into the same entity graph and uses the same control model. That keeps handoffs explicit even as teams adopt more of the platform over time.
Shared entity ownership
Components do not create private metadata islands. Datasets, training runs, models, artifacts, deployments, telemetry, and interventions all exist in one canonical graph.
Control plane and data plane separation
Heavy binary movement happens on the data plane, but state transitions, lineage, approvals, and policy remain authoritative in the control plane.
Promotion-boundary immutability
Curated datasets, promoted models, packaged artifacts, and finalized operational or financial records are versioned instead of mutated in place.
Operations feed development
Intervention sessions, field anomalies, and maintenance outcomes are new data and evaluation input, not terminal dashboards.
Why This Architecture Fits Robotics
Robotics data is multimodal and time-aligned
The platform has to model synchronized sensor streams, derived assets, labels, and quality decisions directly instead of pretending everything is a log line or a file blob.
The deployable artifact is probabilistic behavior
Robotics versioning has to connect datasets, curation ruleset, training context, release packaging, and field outcomes rather than stopping at code commits.
Deployment is physical, not abstract
Rollout, rollback, OTA delivery, fleet health, maintenance, and teleoperation are operating workflows with safety and logistics implications, not just CI/CD steps.
Human-in-the-loop is structural
Review, approval, escalation, and intervention are core parts of robotics workflows. The architecture keeps them first-class instead of treating them as side-channel exceptions.
Design Rules
Robotics-native data model
Robots produce multimodal, time-aligned sensor streams and probabilistic artifacts. The platform has to model that reality directly.
Human gates are first-class
Review, approval, teleoperation, and escalation belong inside the platform rather than in chat threads and side channels.
Structural isolation
Workspace ownership, organization policy, regions, and environments are architecture primitives, not admin afterthoughts.
Field-to-lab compounding loop
Deployment outcomes, telemetry anomalies, and intervention sessions are development inputs, not operational dead ends.