PAR-OS: An AI-Native Operating System Architecture for Autonomous Robots

Abstract — Modern robot software stacks are assembled from middleware (ROS 2/DDS), learning frameworks, simulators, and cloud services that were never designed to interoperate. The result is that capabilities now central to autonomy — persistent memory, world modeling, policy execution, fleet learning, and simulation-in-the-loop reasoning — exist only as ad hoc application code, re-implemented per deployment and invisible to the system layer. We argue that these capabilities should be operating-system abstractions, in the same sense that files, processes, and sockets are abstractions in a conventional OS. We present PAR-OS, an AI-native robot operating system organized around six first-class kernel objects: Skills, Policies, Beliefs (a transactional world model), Memories, Twins (continuously synchronized simulations), and Leases (fleet-level resource and knowledge contracts). PAR-OS introduces a two-level scheduler that composes hard real-time control with utility-based scheduling of anytime AI inference; a bounded-staleness consistency model for digital-twin synchronization; a certified safety kernel based on runtime shielding and control barrier functions that holds regardless of learned-policy behavior; and a closed-loop fleet learning pipeline with staged, verifiable deployment. We describe the architecture, its programming model, and an evaluation methodology, and identify the research problems the architecture exposes.

1. Introduction

Robot software architecture has not kept pace with robot capability. The dominant platform, ROS 2, is best understood as a communication substrate: it provides typed publish/subscribe over DDS, lifecycle-managed nodes, parameter services, and hardware abstraction. These are necessary but no longer sufficient. Over the past five years, the computational core of autonomy has shifted from handcrafted perception–planning–control pipelines to learned components — vision-language-action (VLA) models, diffusion policies, RL controllers — surrounded by large-scale simulation, cloud training infrastructure, and semantic world models. None of these have first-class representation in any deployed robot operating system.

The consequences are visible in practice. Consider a mobile manipulator deployed in a warehouse today:

No system-level memory. The robot's map lives in one node's process memory, object knowledge in another's, and task history in application logs. A power cycle or node crash silently destroys accumulated knowledge; nothing in the platform defines what robot memory is, how it persists, or how components share it.
No policy abstraction. A diffusion policy, an MPC controller, and a PID loop are all "just nodes." The system cannot reason about their latency distributions, preemptibility, confidence, fallback relationships, or resource needs — so developers hand-tune executor threads and QoS profiles per deployment.
Simulation is offline. Simulators are used before deployment, then discarded. The running robot cannot ask "what happens if I take this trajectory?" because no synchronized model of its environment exists at runtime.
Fleets do not learn. Experience gathered by robot i improves robot i at best. Data pipelines from deployment back to training are bespoke, and pushing an updated policy to a fleet is an uncontrolled software-deployment problem with physical safety consequences.
Safety is convention, not construction. Velocity limits and e-stops are scattered across drivers and application code. Nothing architecturally prevents a learned policy from commanding an unsafe action if a downstream check is misconfigured.

Each of these problems is solvable in application code, and each is solved — repeatedly, incompatibly, and fragilely — in every serious robotics deployment. This is precisely the signature of a missing OS abstraction. Before virtual memory, every program managed overlays; before sockets, every application reimplemented network protocols. We contend that robot memory, world state, policies, simulation, and fleet knowledge have reached the same threshold.

Thesis. A robot operating system should schedule and manage intelligence — models, memories, beliefs, and simulations — with the same rigor that conventional operating systems manage processes, memory, and I/O, while enforcing physical safety beneath the intelligence layer.

This paper makes four contributions:

Abstractions (§3). Six kernel objects — Skill, Policy, Belief, Memory, Twin, Lease — with defined semantics, lifecycle, and isolation properties, forming a narrow waist between AI workloads and robot hardware.
Mechanisms (§4). A two-level AI-aware scheduler; a transactional, versioned world model with subscription queries; bounded-staleness twin synchronization; a shielded safety kernel with formal guarantees; and a staged fleet-learning deployment protocol.
Programming model (§5). An intent-level API compiled into skill graphs, with recovery and monitoring synthesized by the system rather than written by the developer.
Evaluation methodology and research agenda (§6–7). Metrics and testbeds for evaluating an OS whose "workload" is embodied intelligence, and the open problems the design exposes.

2. Design Principles

P1 — Intelligence is a scheduled resource. Neural inference, planning, and control are heterogeneous computations with radically different timing semantics: a torque loop misses at 1 kHz are faults; a VLM query is anytime and preemptible. The OS must model both in one scheduling framework rather than forcing them into a uniform executor.

P2 — World state is shared, versioned, and transactional. Perception should write once into a system-maintained belief store; all consumers read consistent snapshots. Components must never disagree about world state because they subscribed to different topics at different times.

P3 — Simulation is a runtime service. Every robot carries a Twin: a physics- and semantics-level model of itself and its environment, synchronized within a bounded divergence, queryable for prediction, counterfactuals, and replay.

P4 — The fleet is the unit of learning. Experience, skills, and maps are fleet assets governed by explicit contracts (Leases), not per-robot side effects. Deployment of learned artifacts is a first-class, staged, reversible OS operation.

P5 — Safety is enforced below learning. All actuation passes through a minimal, verified safety kernel that cannot be bypassed by any policy, skill, or application, and whose guarantees are independent of model behavior.

P6 — Location transparency with physical awareness. Computation migrates across onboard, edge, and cloud tiers, but the scheduler is explicitly aware of the latency, bandwidth, and disconnection semantics of each placement; hard-real-time and safety-critical paths are pinned onboard by construction.

P7 — Everything is observable and replayable. Every kernel object exposes structured telemetry; the combination of Belief versioning and deterministic skill execution yields system-wide time-travel debugging.

3. Kernel Abstractions

PAR-OS is structured as a microkernel-style system: a small trusted core (scheduler, Belief store, safety kernel, capability system) with all other services — perception, planning, learning, twin management — running as isolated user-level servers. The kernel exposes six object types, each named by a capability and manipulated through a narrow system-call interface.

3.1 Skill

A Skill is the unit of robot capability: a typed, versioned, composable behavior with an explicit contract.

skill Pick(target: ObjectRef) -> Grasped {
  requires:  Belief.reachable(target), Gripper.free
  ensures:   Belief.held(target)
  invariants: force < F_max, workspace ⊆ W_task
  resources: {arm: exclusive, wrist_cam: shared, gpu: 4 TOPS}
  budget:    {time: 30 s, energy: 120 J, risk: low}
  fallbacks: [Pick.v2_scripted, AbortAndReport]
}

Skills declare preconditions and postconditions over Beliefs, resource requirements, invariants delegated to the safety kernel, and an ordered fallback chain. Because contracts are machine-checked at invocation, the kernel can synthesize monitoring (postcondition verification), recovery (fallback dispatch), and admission control (resource reservation) without application code. Skills compose recursively into skill graphs — DAGs with data and control dependencies — which are the schedulable unit for tasks.

3.2 Policy

A Policy is an executable decision-maker bound inside a Skill: a PID loop, an MPC solver, an RL policy, a diffusion policy, or a VLA model. The kernel does not interpret policy internals; it interprets a uniform execution profile:

timing class: hard-periodic (e.g., 1 kHz torque), firm-deadline (e.g., 30 Hz visual servoing), or anytime (e.g., LLM task planning);
latency distribution (measured online, not declared);
preemption semantics: preemptible, checkpointable, or run-to-completion;
confidence interface: a calibrated score or OOD signal, if the policy provides one;
degradation ladder: reduced-fidelity variants (smaller model, shorter horizon) the scheduler may substitute under load.

This profile is what makes AI-aware scheduling (§4.1) possible: the scheduler trades quality for time using the degradation ladder rather than simply missing deadlines.

3.3 Belief (World Model)

The Belief store is a typed, versioned scene graph maintained by the kernel: entities (objects, humans, rooms, the robot itself), attributes with explicit uncertainty (poses as distributions, class labels with confidence), relations (on, inside, held-by, affords), and task state. It replaces raw-topic plumbing as the interface between perception and everything else.

Three properties distinguish it from a blackboard or a TF tree:

Transactional writes with provenance. Perception servers commit updates as transactions tagged with source, timestamp, and model version. Conflicting estimates (two detectors, different poses) are fused by pluggable estimators inside the store, so consumers never see disagreement.
MVCC snapshots. Readers receive an immutable snapshot at version v; a planner planning against Belief@v can later validate whether its plan's preconditions still hold at v' > v — a cheap, well-defined replan trigger.
Standing queries. Components subscribe to semantic conditions (∃ human: distance(human, robot) < 1.5 m), evaluated incrementally by the store, rather than filtering raw streams themselves.

3.4 Memory

Memory segments give knowledge an OS-defined lifecycle beyond process lifetime. PAR-OS distinguishes four segment types with different consistency and retention semantics: spatial (metric/topological maps; CRDT-mergeable across robots), semantic (object and environment knowledge; fleet-shared, versioned), procedural (skill parameters and policy weights; deployed via Leases, §3.6), and episodic (append-only execution logs; the substrate of the learning pipeline and of replay debugging). Segments are checkpointed, access-controlled, and survive reboots and reprovisioning — the robot's knowledge is an OS-managed asset, not a side effect of whichever process happened to hold it.

3.5 Twin

A Twin is a runtime simulation of the robot and its environment, constructed from the Belief store and kept synchronized under an explicit consistency contract (§4.2). Twins serve prediction (twin.rollout(traj, horizon=2 s) before committing a motion), counterfactual evaluation (scoring candidate skills or recovery options), anomaly detection (divergence between predicted and observed state as a residual signal), and synthetic data generation (domain-randomized variations of episodes actually experienced). Twins are ordinary kernel objects: they can be checkpointed, forked (many hypothetical rollouts from one synchronized base state), and rate-limited by the scheduler like any other anytime workload.

3.6 Lease

A Lease is the contract by which fleet-level resources and knowledge flow to and from a robot: the right to execute a task in a spatial region, a subscription to a shared map shard, or — critically — the deployment of a new policy version. Framing deployment as a lease gives it semantics deployment scripts lack: leases are scoped (which robots, which environments, which task classes), revocable (a fleet-wide rollback is a lease revocation, guaranteed to complete within a bounded interval), and conditional (a canary lease may require the safety kernel's intervention rate to stay below a threshold, else it self-revokes).

4. System Mechanisms

4.1 Two-Level AI-Aware Scheduling

PAR-OS separates scheduling into a real-time plane and a cognition plane, connected by explicit reservations.

The real-time plane runs hard-periodic and firm-deadline policies (control loops, safety monitors, state estimation) under a reservation-based EDF discipline on dedicated cores, with WCET budgets enforced by the kernel. Nothing in the cognition plane can steal these cycles; admission control rejects skill graphs whose real-time components are infeasible.

The cognition plane schedules anytime workloads — planners, VLM queries, twin rollouts, learning jobs — by maximizing expected utility under residual resources:

maximize Σᵢ uᵢ(qᵢ, tᵢ) subject to Σᵢ rᵢ(qᵢ) ≤ R_residual

where each workload i exposes a quality knob qᵢ (its degradation ladder: model size, rollout count, planning horizon), uᵢ is task-derived utility (a blocking Pick outweighs background map refinement), and tᵢ is completion time. Placement across onboard/edge/cloud tiers enters the same optimization through per-tier latency and disconnection-risk terms; workloads whose failure would strand a safety- or liveness-critical path are constrained to onboard placement. In degraded connectivity, the scheduler walks down degradation ladders rather than dropping tasks — the robot gets worse, not stuck.

4.2 Twin Synchronization as Bounded Staleness

Perfect twin fidelity is impossible; unspecified fidelity is useless. PAR-OS makes the twin contract explicit: each Twin advertises a divergence bound ε over a state metric d(·,·) and a horizon H, maintained by a synchronization engine that (a) continuously corrects twin state from Belief updates, (b) performs online system identification on residuals to adapt dynamics parameters, and (c) escalates honestly — when d exceeds ε, the Twin marks affected queries as unreliable and triggers re-perception rather than returning confident nonsense. Consumers declare the (ε, H) they require; a grasp verifier may demand centimeter fidelity over 2 s while a traffic-flow predictor tolerates coarse fidelity over minutes. This turns "is the simulation good enough?" from folklore into an admission-controlled, monitored property.

4.3 Safety Kernel: Shielding Below Learning

All actuator commands, from any policy, traverse a safety kernel: a minimal component (target: small enough for formal verification, deployed on an isolated core or MCU with independent sensor taps) implementing runtime shielding. It maintains conservative reachability envelopes and control barrier function (CBF) constraints for force, velocity, workspace, and separation from humans; each incoming command is minimally projected into the safe set (QP-based filtering) or replaced by a verified stopping maneuver if no safe projection exists.

The resulting guarantee is architectural, not behavioral: for the modeled constraint set, no software above the safety kernel — including any learned policy, any skill, any application, and any code deployed via Lease — can cause a violation. Learned components are thus free to be aggressive, exploratory, or wrong; the cost of a bad policy is task failure and shield interventions (which are themselves logged as high-value training signal), never a safety violation. Shield intervention rate becomes the system's canonical safety metric, consumed by canary leases (§3.6) and the learning pipeline (§4.4).

4.4 Closed-Loop Fleet Learning

Episodic memory feeds a pipeline the OS owns end to end: experience → curation → training → validation → leased deployment → monitoring. Three design points matter. First, curation is prioritized: shield interventions, postcondition failures, and high-twin-divergence episodes are weighted above routine successes, and twin-generated domain-randomized variants of failures augment scarce negatives. Second, validation gates on the Twin fleet: a candidate policy must clear scenario suites replayed across the fleet's accumulated twin states — effectively regression testing against every environment the fleet has seen — before any physical canary. Third, deployment is a Lease: staged (canary → cohort → fleet), condition-monitored (success rate, shield interventions, latency profile), and revocable with bounded rollback time. Model updates thereby inherit the operational discipline of modern software deployment while remaining accountable to physical-safety telemetry.

4.5 Security and Identity

Each robot holds a hardware-backed identity (TPM/TEE); all deployed artifacts — skills, policies, map shards — are signed and attested before the Lease manager will activate them. Capabilities gate every kernel object: a third-party inspection skill may hold read access to the Belief store's object graph but no capability for actuation or episodic memory export. Fleet communication is mutually authenticated and encrypted; Lease revocation doubles as the security kill switch for compromised artifacts.

4.6 Observability

Because Beliefs are versioned and skill execution is logged against Belief versions, PAR-OS supports deterministic semantic replay: any episode can be re-executed against recorded Belief history, with the Twin substituting for physics, to reproduce planner and policy decisions exactly. Distributed tracing spans skill graphs across onboard/edge/cloud placements; the debugging workflow for a robot fleet becomes structurally identical to that of a distributed cloud service, with the Twin providing what cloud systems lack — a physics-grounded counterfactual engine.

5. Programming Model

Developers program against intent, not plumbing:

kitchen = paros.space("kitchen")

with paros.task("clear_table", budget=Budget(time="5 min", risk="low")):
    mug = kitchen.find("coffee mug", min_conf=0.8)   # standing Belief query
    robot.pick(mug)                                   # Skill invocation
    robot.navigate(kitchen.fixture("dishwasher"))
    robot.place(mug, into="top rack")

The runtime compiles this into a skill graph; resolves each invocation to a concrete Skill version via the procedural-memory registry; checks contracts against the current Belief snapshot; reserves resources through admission control; and attaches synthesized monitors for every postcondition. When pick fails its postcondition (Belief.held(mug) is false at verification), the kernel — not the application — walks the fallback chain, optionally consulting the Twin to rank recovery options, and surfaces a structured exception only when the chain is exhausted. Three properties fall out: applications are portable across embodiments that implement the same Skill contracts; they are robust by default, since recovery is synthesized; and they are auditable, since every action traces to a contract check against a versioned Belief.

Escape hatches are explicit: developers can register new Skills wrapping arbitrary controllers, and hard-real-time components are written against the real-time plane directly — PAR-OS narrows the waist; it does not forbid expertise.

6. Evaluation Methodology

An OS for embodied intelligence must be evaluated on system properties, not task demos. We propose four axes with concrete metrics:

Scheduling. Deadline-miss rate for the real-time plane under adversarial cognition load (target: zero, by construction); cognition-plane utility versus an oracle schedule; graceful-degradation curves (task success rate as a function of available compute/connectivity), compared against a ROS 2 executor baseline where degraded resources cause missed deadlines rather than reduced quality.

Belief/Twin. End-to-end perception-to-consumer latency and snapshot-read scalability versus topic-based plumbing; measured twin divergence d(t) against advertised ε across manipulation and navigation workloads; anomaly-detection ROC using twin residuals versus learned baselines.

Fleet learning. Sample efficiency of fleet-shared versus per-robot learning (tasks-to-threshold across N robots); regression-catch rate of twin-fleet validation (fraction of bad candidate policies stopped before physical canary); rollback latency under lease revocation.

Safety. Shield intervention rate over policy training generations (expected to decline as interventions feed the pipeline); zero constraint violations across all conditions, including deliberately adversarial policies injected as red-team workloads; verification effort for the safety kernel (LOC in the trusted computing base).

Testbeds should span at least a mobile-manipulator fleet (N ≥ 5) in a semi-structured logistics environment and a long-horizon household manipulation setting, with ablations removing individual abstractions (no Twin, no fleet Leases, no degradation ladders) to attribute end-to-end gains.

7. Related Work

Robot middleware. ROS/ROS 2 and DDS define the communication substrate PAR-OS assumes but do not provide memory, world-model, policy, or learning abstractions; OROCOS and YARP address real-time componentry without the cognition plane. PAR-OS is complementary at the transport layer and a departure at the abstraction layer — closer in spirit to how a kernel relates to a network stack.

Cloud and fleet robotics. RoboEarth, Rapyuta, and KnowRob pioneered shared robot knowledge and cloud offload; FogROS 2 addresses placement. PAR-OS integrates these as kernel concerns (Memory segments, Leases, tiered scheduling) with defined consistency and revocation semantics rather than as external services.

Learning-based control and VLAs. Language-conditioned skill systems (e.g., SayCan-style planning over skill libraries) and VLA policies motivate the Skill/Policy split: PAR-OS is deliberately model-agnostic, providing the contract, scheduling, and safety machinery such models require in deployment.

Runtime assurance. The safety kernel builds on Simplex-style runtime assurance, CBF-based safety filters, and shielded RL; PAR-OS's contribution is architectural placement — shielding as an unbypassable OS layer with an isolated TCB — plus the coupling of intervention telemetry to fleet learning and deployment gating.

Digital twins. Industrial twin frameworks target monitoring; simulation-based robotics (domain randomization, real-to-sim) targets training. PAR-OS's Twin differs in being a runtime kernel object with an admission-controlled consistency contract, consumed by planning, anomaly detection, and validation online.

8. Limitations and Open Problems

The design surfaces hard problems rather than hiding them. The Belief store risks becoming a semantic bottleneck; its schema-evolution and cross-embodiment ontology problems are unsolved. Bounded-staleness twins are only as honest as their divergence metric — contact-rich manipulation strains any tractable d(·,·). The safety guarantee is conditional on the modeled constraint set; perception failures that corrupt the shield's state estimate remain the deepest open issue, motivating the independent sensor path but not eliminating the problem. Utility functions for the cognition plane must currently be hand-derived from task structure; learning them is itself a research problem. Finally, fleet learning under Leases raises data-governance questions (cross-site episodic data, customer isolation) that the capability system frames but does not answer.

9. Conclusion

PAR-OS reframes the robot operating system: from middleware that moves messages to a kernel that manages intelligence. Its claim is not that any single mechanism — shielding, twins, federated skills, utility scheduling — is new, but that making them jointly first-class, with defined contracts, consistency, and safety semantics, is the missing systems layer between today's foundation-model capabilities and dependable deployed autonomy. The abstractions are deliberately narrow enough to build: a Belief store, a two-plane scheduler, a verifiable shield, and a lease-based fleet plane constitute a credible minimal kernel, and each admits independent evaluation. As robots become learning systems, their operating systems must become systems for learning — safely, observably, and as fleets.

PAR-OS: An AI-Native Operating System for Autonomous Robots