Manager-Based API

UniLab uses a community-compatible manager API on its Torch runtime. Manager modules, term configs, function/class terms, lifecycle ordering, and reset semantics follow the pinned mjlab 1.6.0 source. Numeric execution uses Torch tensors while preserving UniLab’s TorchEnvState, Hydra owner YAML, SimBackend, registry, and IPC contracts.

The current tensor-runtime decision is ADR-0011. The superseded compatibility matrix and mechanical migration example remain in ADR-0006 as historical context.

Invariants

  • Community manager semantics and a general structure take priority over local optimizations that would create a UniLab-only term API.

  • Manager carriers, term returns, environment IDs, and entity views use Torch tensors. Production managers and envs source rejects NumPy imports and Torch↔NumPy conversions. The cold NPZ MotionLoader is the only task-runtime NumPy leaf, while base owners consume legacy NumPy formats only inside explicit adapter/reset-host boundaries.

  • SceneEntityCfg resolves through a base-owned scene/entity facade on the cold path. The facade uses only the public SimBackend contract, and hot paths reuse cached IDs and views.

  • Named-sensor observation terms bind a backend-owned view through EntityScene.bind_sensor_data(...) during construction; their hot path only reads that view and never re-resolves sensor names or XML/model metadata.

  • ManagerBasedRlEnv owns backend materialization exactly once: manager construction completes, then SimBackend.materialize() and startup events run before any reset or step.

  • Explicitly empty configuration may use a Null manager. A requested capability that is unavailable fails at the nearest boundary; it is never skipped, zero-filled, or routed back to a legacy environment.

  • Hot paths avoid obvious repeated parsing, per-environment Python loops, copies, and temporary allocations. Further optimization requires benchmark evidence and must not add disproportionate structural complexity.

Only surfaces backed by registration, configuration, and tests may be called Compatible. NumPy/env/config adapters are Adapted; capabilities without a formal backend contract are Unsupported and fail closed.