ScienceOL Docs
  • English

      • Resource management roadmap

      The goal is for lab to manage immutable asset packages and independently controlled laboratory instances: acquire a resource, create an instance, operate it, stop it, and reclaim it. The first instance runtime is local OpenSDL kinematic simulation. Model previews, asset packages, and runtime instances have distinct responsibilities.

      Current progress

      Status as of 2026-10-15. OpenSDL resource management, the local asset daemon, and explicit USD component splitting are merged in OpenSDL PR #25 and published in the v0.3.1 release. Hub delivery is merged in Hub PR #3, with receipt redirect fixes merged in PR #7.

      CapabilityStatusEntry point
      Validation, packaging, OCI push/pull, digest verification, offline reuseAvailable in the public CLIInstallation and Hub Quick Start
      Public asset search, versions, and model previewsAvailable in HubOpenSDL Hub
      Local asset daemon, build/import, inventory, tags, removal, and safe GCShipped in v0.3.1Local asset management
      Explicit OpenUSD component split with parent lineageShipped in v0.3.1; requires OpenUSD PythonLocal asset management
      Create, run, stop, restart, inspect, and remove package instancesShipped in v0.3.1Runtime instances
      Docker-style run, ps, start, stop, logs, rm, and images shortcutsShipped in v0.3.1Hub Quick Start
      Separate logs, data, authenticated endpoints, and device actionsImplemented in sourcelab instance logs/devices/send
      Hub admission of an explicit kinematic runtime declarationImplemented and deployed in Test/UATPackage spec.runtime
      One command for Registry, preview, and Hub publicationPlannedNext stage
      Scene composition, locked dependencies, physics runtimes, and resource budgetsPlannedLater stages

      Stage one: assets to instances

      The lab asset and lab instance command groups are implemented. Creation freezes the package digest and world configuration; moving a tag cannot change a retained instance. Stopped and failed instances still occupy their original package. Removal releases that occupation, and GC preserves shared blobs according to actual references.

      Acceptance covers two independent instances, authenticated device calls, stop/restart, tag changes, process crashes, invalid configuration/paths, and package occupation versus GC. The complete local OpenSDL test suite includes a real OCI Registry round trip. The top-level shortcuts reuse the same instance and asset state transitions. They provide a Docker-like control surface while the runtime remains local kinematic simulation and does not provide OS container isolation.

      Stage two: publication and discovery

      Add explicit Hub login and publication configuration, and organize Registry upload, preview upload, and catalog admission into a retryable publication workflow. Keep credentials separate by responsibility and published versions immutable. Failures show completed steps and the point from which work can continue. Search results expose runtime requirements so visual assets are not mistaken for runnable packages.

      Acceptance: publish an isolated test asset, find it, pull its exact digest, and create an instance. Missing authority, preview failures, and admission failures produce explicit outcomes.

      Stage three: reproducible laboratory scenes

      Define typed scene composition and a dependency lockfile that fixes asset digests, device identities, and connections. Validate the full dependency graph before creation. Offline mode explicitly reports missing resources; the selected local runtime continues to own execution.

      Acceptance: the same lockfile creates the same scene from a clean store and a complete offline store. Missing, cyclic, and conflicting dependencies are rejected before startup.

      Stage four: runtimes and operations

      Add adapters such as MuJoCo/Isaac when required, with explicit runtime version, platform, and device availability checks. Then add CPU/memory/GPU budgets, health checks, log rotation, and event diagnostics. A missing runtime or offline device is unavailable; execution never moves automatically to another device or the cloud.

      Kinematic currently provides deterministic device-state evolution. OS container isolation, network/volume management, arbitrary program execution, and full physics simulation are outside the first release. Each needs its own laboratory contract and acceptance criteria; a Docker-like command experience does not imply those capabilities already exist.