Layered view
Run / Project / Registry
│ compile + resolve + validate
▼
ExecutionPlan + Lock
│
▼
FastSim Application ───── Plugin Host
lifecycle / services scoped capabilities
│
▼
UniRoboSim
Provider → Session → World
│
▼
Isaac Lab / MuJoCo / PyBullet / Custom
Compilation boundary. A Run says what this execution selects. A Project says where components may be resolved. Registries map stable URIs to versioned manifests and backend resources. Before physics starts, the compiler validates format, resolves releases, verifies resources, binds plugins, and records provenance in a deeply immutable ExecutionPlan.
A Lock additionally freezes exact versions, variants, resource digests, and the plan digest. Runtime consumes compiled facts and never searches for files or guesses author intent while stepping.
Application runtime and plugin boundary
FastSimApplication is the public asynchronous facade. It owns prepare, start, pause, resume, reset, stop, and close, and exposes scene, frames, geometry, kinematics, control, checkpoint, visualization, and output capabilities.
One authority boundary owns the backend world. CLI, Python, Server, TUI, and plugin requests all pass through the Application rather than mutating physics directly.
Plugin boundary. Plugins are discovered through manifests and Python entry points; only instances explicitly selected by the Run are created. Plugin Host owns lifecycle, while Service Broker grants the minimum services permitted by the compiled binding.
Plugins receive revocable, generation-bound services—not a UniRoboSim World or native backend handle. Installation is not activation, and a declared role does not automatically grant every service.
Simulation and offline data boundary
UniRoboSim standardizes portable contracts for scenes, entities, state, sensors, and physical control. Providers preserve each engine's real capability set. Cross-backend portability means stable application boundaries and capability negotiation, not bitwise-identical physics, rendering, materials, fluids, or sensors.
Offline data boundary. Record and similar plugins produce outputs in an online Run. Sealed FSR data, viewers, analytics, and training-data export belong to the offline plane and never own the live physics world.
Build time and run time
Build time reads Run, Project, Registry indexes, component and plugin manifests, and Scenario data. It validates fields, resolves versions and resources, selects backend variants, binds entities and services, computes control precedence, and produces an immutable ExecutionPlan. Most composition failures can therefore be diagnosed without launching a simulator or allocating a GPU.
Run time consumes the Plan; it does not reinterpret source YAML. FastSimApplication creates the selected Provider, stable services, and plugin instances on one owner loop. UI and server surfaces observe this Application rather than maintaining a second runtime.
Stable service layer. Scene, Frame, and Geometry describe world structure and planning facts. State, Observation, and Camera publish committed data. Control, Kinematics, and planning-related services describe targets and controlled work. Visualization, Event, Metric, lifecycle, and output services expose bounded diagnostics and finalization.
Values carry stable entity and frame identities plus generation/revision context. Native Prim paths, body IDs, array positions, or Python object references remain Provider implementation details.
Three data flows
The construction flow is Run → validate → resolve → bind → ExecutionPlan → Application. The state/control flow publishes a committed world snapshot, lets a source compute outside Core, validates its Chunk at admission, and applies it through the Provider with an Operation result. The data/interface flow transports authorized channels to Record or Server and then into atomically published or remote representations.
Failure ownership. Schema and cross-field errors belong to compilation. Missing releases and digest mismatches belong to Registry/resource resolution. Invalid plugin bindings belong to composition. Prepare/start/close failures belong to runtime hooks or the Provider. Stale work after reset belongs to generation and Operation handling. Backend-only physics defects belong to the Provider's UniRoboSim mapping. Incomplete FSR publication belongs to recording and output transactions.
This ownership prevents a presentation layer from papering over an invalid Plan and prevents plugins from bypassing Core to work around a Provider defect. Continue with Design principles or Run, Plan, and Lock.