Section 3Product Foundation

Named subsystem map

Names the product subsystems, assigns their responsibilities, and proposes their Rust crate or package boundaries.

Section relationships

Names are deliberately descriptive. No subsystem uses a private codename.

Product subsystemOwnershipProposed crate or package name
Project WorkspaceProject files, references, configuration, and save/load lifecyclebeforemetal-workspace
Model RegistryCanonical model IR, units, frames, entities, topology, and provenancebeforemetal-model
Asset PipelineImport, export, normalization, conversion reports, and compiled assetsbeforemetal-assets
Scenario CompilerValidation, capability negotiation, schedule construction, and compilationbeforemetal-compiler
Simulation KernelAuthoritative time, events, execution order, checkpoints, and couplingbeforemetal-kernel
Mechanics SystemRigid and articulated mechanics backend contract, dynamic-analysis queries, and Rust-native default backend; Rapier is the current candidatebeforemetal-mechanics
Environment SystemGravity, atmosphere, terrain, wind, precipitation, and surface statebeforemetal-environment
Material SystemEngineering material properties, surface interactions, provenance, and validitybeforemetal-materials
Device and Power SystemActuators, transmissions, batteries, power buses, thermal nodes, and faultsbeforemetal-devices
Circuit SystemLumped electrical networks and the contract for optional SPICE-grade analysisbeforemetal-circuits
Thermal SystemLumped temperature and heat-flow networks and detailed thermal-solver contractsbeforemetal-thermal
Sensor SystemTruth sampling, transduction, noise, timing, degradation, and deliverybeforemetal-sensors
Rendering SystemView rendering and synthetic optical or depth sensor generation without owning simulation truthbeforemetal-render
Controller HostNative Rust controllers and optional sandboxed/external controller adaptersbeforemetal-control
Experiment OrchestratorRuns, runtime-action plans, sweeps, randomization, optimization hooks, progress, and metricsbeforemetal-experiment
Result StoreManifests, traces, snapshots, input re-execution, state playback, exports, and comparisonsbeforemetal-data
Validation SystemBenchmarks, user-authored simulation tests, calibration diagnostics, linearization, convergence, uncertainty, and fidelity cardsbeforemetal-validation
Editor and ViewerAuthoring, inspection, visualization, plots, diagnostics, and playbackbeforemetal-ui
Integration GatewayROS 2, Gymnasium, FMI, HIL, and external solver process adaptersbeforemetal-gateway
Extension HostBuilt-in Rust, Wasm, and out-of-process plugin lifecycle and permissionsbeforemetal-extensions
Structural Analysis SystemFuture deformable bodies, stress, strain, damage, and FEA backend contractsbeforemetal-structures
Fluid Analysis SystemFuture aerodynamic, hydrodynamic, and CFD field or solver contractsbeforemetal-fluids
Firmware Execution SystemOptional virtual CPU, peripheral, bus, and firmware-emulator coordinationbeforemetal-firmware

Change rationale (v0.4 analysis and regression ownership): Runtime-action plans belong to the Experiment Orchestrator and are committed against a live world instance by the Simulation Kernel; backend-neutral dynamics queries remain Mechanics System responsibilities; and user-authored regression and derived analysis evidence belong to the Validation System. This assigns the new Beta contracts to existing subsystem boundaries rather than inventing a competing analysis or test subsystem.

Generated from the canonical specification. Edit section metadata or prose in docs/requirements.md; the website rebuilds this page and its relationships automatically.