18 MVP acceptance gates included0%
02 Requirements index
Every promise has an identifier.
Search by requirement ID, capability, or language. Filter by delivery priority and verification method. Every result links to its canonical section.
765 indexed records33 sections
Delivery ledger
Verified progress, without guesswork.
Only requirements with accepted implementation and verification evidence enter a numerator. Draft designs and private review tools remain visible below without being counted as delivered product behavior.
656 product requirements + 27 acceptance gates0%
The gates that block a Portable MVP release0%
18 MVP + 9 later-profile gates0%
Review status inventory and counting method
Current evidence stages
- Not started
- 658
- Draft design evidence
- 7
- Design approved
- 4
- Implementation in progress
- 13
- Implemented, unverified
- 1
- Verified
- 0
Counting policy
The sparse status overlay is joined to stable IDs from the canonical requirements. Missing IDs default to not started. Only verified counts as complete; there is no subjective weighted percentage.
These cohorts overlap: MVP commitments already include the Portable MVP gates, and the normative inventory includes every requirement and gate. Last reviewed 2026-08-08.
§3Subsystem Map23
SUBSYSTEM-PROJECT-WORKSPACESubsystem
Project Workspace
Project files, references, configuration, and save/load lifecycle
SUBSYSTEM-MODEL-REGISTRYSubsystem
Model Registry
Canonical model IR, units, frames, entities, topology, and provenance
SUBSYSTEM-ASSET-PIPELINESubsystem
Asset Pipeline
Import, export, normalization, conversion reports, and compiled assets
SUBSYSTEM-SCENARIO-COMPILERSubsystem
Scenario Compiler
Validation, capability negotiation, schedule construction, and compilation
SUBSYSTEM-SIMULATION-KERNELSubsystem
Simulation Kernel
Authoritative time, events, execution order, checkpoints, and coupling
SUBSYSTEM-MECHANICS-SYSTEMSubsystem
Mechanics System
Rigid and articulated mechanics backend contract, dynamic-analysis queries, and Rust-native default backend; Rapier is the current candidate
SUBSYSTEM-ENVIRONMENT-SYSTEMSubsystem
Environment System
Gravity, atmosphere, terrain, wind, precipitation, and surface state
SUBSYSTEM-MATERIAL-SYSTEMSubsystem
Material System
Engineering material properties, surface interactions, provenance, and validity
SUBSYSTEM-DEVICE-AND-POWER-SYSTEMSubsystem
Device and Power System
Actuators, transmissions, batteries, power buses, thermal nodes, and faults
SUBSYSTEM-CIRCUIT-SYSTEMSubsystem
Circuit System
Lumped electrical networks and the contract for optional SPICE-grade analysis
SUBSYSTEM-THERMAL-SYSTEMSubsystem
Thermal System
Lumped temperature and heat-flow networks and detailed thermal-solver contracts
SUBSYSTEM-SENSOR-SYSTEMSubsystem
Sensor System
Truth sampling, transduction, noise, timing, degradation, and delivery
SUBSYSTEM-RENDERING-SYSTEMSubsystem
Rendering System
View rendering and synthetic optical or depth sensor generation without owning simulation truth
SUBSYSTEM-CONTROLLER-HOSTSubsystem
Controller Host
Native Rust controllers and optional sandboxed/external controller adapters
SUBSYSTEM-EXPERIMENT-ORCHESTRATORSubsystem
Experiment Orchestrator
Runs, runtime-action plans, sweeps, randomization, optimization hooks, progress, and metrics
SUBSYSTEM-RESULT-STORESubsystem
Result Store
Manifests, traces, snapshots, input re-execution, state playback, exports, and comparisons
SUBSYSTEM-VALIDATION-SYSTEMSubsystem
Validation System
Benchmarks, user-authored simulation tests, calibration diagnostics, linearization, convergence, uncertainty, and fidelity cards
SUBSYSTEM-EDITOR-AND-VIEWERSubsystem
Editor and Viewer
Authoring, inspection, visualization, plots, diagnostics, and playback
SUBSYSTEM-INTEGRATION-GATEWAYSubsystem
Integration Gateway
ROS 2, Gymnasium, FMI, HIL, and external solver process adapters
SUBSYSTEM-EXTENSION-HOSTSubsystem
Extension Host
Built-in Rust, Wasm, and out-of-process plugin lifecycle and permissions
SUBSYSTEM-STRUCTURAL-ANALYSIS-SYSTEMSubsystem
Structural Analysis System
Future deformable bodies, stress, strain, damage, and FEA backend contracts
SUBSYSTEM-FLUID-ANALYSIS-SYSTEMSubsystem
Fluid Analysis System
Future aerodynamic, hydrodynamic, and CFD field or solver contracts
SUBSYSTEM-FIRMWARE-EXECUTION-SYSTEMSubsystem
Firmware Execution System
Optional virtual CPU, peripheral, bus, and firmware-emulator coordination
§4System Requirements17
Rust-owned core
BeforeMetal SHALL implement all first-party core logic in Rust.
Portable default product
The default installation SHALL execute the Portable MVP workflow defined in section 30 without requiring a user-installed third-party C, C++, Fortran, Python, JVM, ROS, vendor, or proprietary engineering runtime.
Optional engineering integrations
BeforeMetal SHALL execute optional non-Rust engineering tools outside the core simulator process through versioned adapters.
UI-independent simulation
Every committed simulation capability SHALL be operable without launching the graphical interface; an optical capability MAY use an offscreen renderer or optional graphics device when its manifest declares that dependency.
Explicit fidelity
Every run SHALL identify the physical models, solver settings, approximations, and validation status used.
No silent fidelity loss
BeforeMetal SHALL report and require acknowledgement of any unsupported or approximated model feature that could affect an experiment result.
Solver independence
Canonical project data SHALL not depend on one mechanics backend's object types, handles, or native file format.
Replaceable subsystems
Mechanics, sensor, device, environment, and external-domain solvers SHALL be replaceable through capability-scoped contracts.
Offline baseline
The portable product SHALL support creation, execution, input re-execution, recorded-state playback, and inspection of the reference experiment without network access.
Decision-support scope
User-facing documentation SHALL state that BeforeMetal supports engineering decisions but does not by itself certify safety, compliance, or manufacturability.
Baseline observability
Every run SHALL expose simulated time, wall time, real-time factor, solver diagnostics, warnings, and termination reason.
Graceful capability failure
A project requiring an unavailable capability SHALL fail during compilation with actionable diagnostics rather than during an arbitrary simulation step.
Canonical terminology
Public schemas, APIs, diagnostics, documentation, and UI text SHALL use the canonical vocabulary according to the meanings in this document.
Pure-Rust default binary closure
Default-enabled BeforeMetal binaries SHALL not link or dynamically load third-party native code except documented operating-system and device-driver interfaces covered by PROC-006.
Conditional capability conformance
A released capability manifest SHALL not claim a Future or External capability unless that release profile explicitly adopts and satisfies every applicable conditional SHALL requirement.
Physical-asset independence
The Portable MVP SHALL be installable, executable, and acceptable without requiring BeforeMetal or the user to own, build, instrument, or physically test a robot.
Capability-scoped property semantics
A machine-readable capability declared by a model or solver that consumes a canonical engineering property SHALL identify the supported property type and version, representation, required committed-state inputs, output semantics, operating limits, and applicable use-case-scoped evidence status.
§5User Workflows21
Project lifecycle
A user SHALL be able to create, open, save, duplicate, and archive a BeforeMetal project.
Robot definition
A user SHALL be able to define a robot from bodies, joints, materials, devices, sensors, and controller interfaces.
World definition
A user SHALL be able to define terrain, obstacles, gravity, atmosphere, wind, precipitation, and surface conditions.
Experiment definition
A user SHALL be able to select a scenario and controller and define parameter values, seeds, stop conditions, metrics, fidelity settings, and execution mode.
Preflight compilation
A user SHALL be able to compile and inspect an experiment before consuming simulation time.
Interactive controls
A user SHALL be able to run, pause, single-step, reset, stop, and change playback speed.
Headless execution
A user SHALL be able to perform the same committed run through a command-line interface.
Design comparison
A user SHALL be able to compare at least two robot or scenario variants using the same mission, metrics, and seeds.
Parameter sweep
A user SHALL be able to execute a finite sweep over named design and environment parameters.
Input re-execution
A user SHALL be able to request input re-execution when the run manifest declares it supported and SHALL receive the declared comparator result rather than an unqualified claim of exactness.
Result export
A user SHALL be able to export metrics and time-series data in documented open formats.
Diagnostic drill-down
A user SHALL be able to navigate from a compile or runtime diagnostic to the responsible entity and property.
Model calibration
A user SHALL be able to fit selected model parameters against imported measurement data while preserving the calibration dataset and method.
Controller portability
A user SHALL be able to run the same controller contract against simulation and an integration adapter without changing controller semantics.
Hardware-in-the-loop session
A user SHALL be able to execute an explicitly armed, wall-clock-paced session with supported physical controller hardware.
Viewport camera navigation
A user SHALL be able to control the viewport camera pose in three-dimensional space to inspect robot and world geometry from different positions and viewing angles.
Recorded-state timeline navigation
A user SHALL be able to seek backward and forward within a run's recorded virtual-time range and start Recorded-State Playback from a selected recorded timestamp.
Robot bring-up workflow
A user SHALL be able to assess an imported or authored robot for simulation readiness and navigate each finding to the responsible entity, property, connection, or required capability.
Synthetic-data workflow
A user SHALL be able to configure, preview, execute, and export a headless synthetic-data capture using declared truth products, sensor products, labels, randomization, seeds, and output schema.
Motion-planning workflow
A user SHALL be able to submit a frame-aware motion-planning request, inspect its constraints and diagnostics, review the returned trajectory, and explicitly validate it against the compiled scenario before execution.
Simulation regression workflow
A user SHALL be able to define, execute headlessly, and inspect a repeatable simulation regression suite whose cases identify their scenario, controller, scheduled inputs, assertions, execution bounds, and expected outcomes.
§6Workspace and Canonical Model37
Stable entity identity
Every canonical entity SHALL have a typed, stable logical identifier that does not depend on display name, collection order, source path, content identity, or backend handle; allocation, retirement, and no-reuse semantics SHALL follow ADR-0003.
SI canonical units
Canonical continuous physical quantities SHALL have SI meaning in persisted and runtime-facing canonical contracts, with the available source lexical value, source units, conversion provenance, and display units retained as metadata.
Dimensional validation
Connections and assignments between physical quantities SHALL be checked for dimensional compatibility.
Canonical coordinate convention
BeforeMetal SHALL use the right-handed convention accepted in ADR-0004: the canonical robot base is +X forward, +Y left, and +Z up; a georeferenced local world uses ENU; a non-georeferenced world declares its horizontal basis, origin, and yaw provenance; and imported conventions are transformed explicitly.
Explicit reference frames
Every spatial quantity SHALL identify or unambiguously inherit its reference frame.
Versioned schema
Every persisted project and compiled model SHALL declare its schema version.
Forward migration
BeforeMetal SHALL provide explicit migrations for every older project schema inside the published compatibility window.
Immutable import source
Original imported assets SHALL be retained or referenced without in-place mutation by normalization or compilation.
Source mapping
Normalized entities and properties SHALL retain a source map to their originating file element where available.
Separate geometry roles
Visual, collision, and inertial representations SHALL be modeled as distinct roles even when they reference the same source geometry.
Analysis geometry role
Aerodynamic, thermal, structural, and other analysis meshes SHALL be distinguishable from visual and collision geometry.
Assembly hierarchy
The canonical model SHALL represent nested assemblies without using hierarchy as physical identity.
Body model
A body SHALL support pose, mass, center of mass, inertia tensor, geometry references, material assignments, and user metadata.
Joint model
A joint SHALL identify its connected bodies, local frames, degrees of freedom, limits, and optional drive and passive properties.
Device model
A device SHALL declare its typed ports, parameters, state variables, sample or update rate, and validity range.
Sensor model
A sensor SHALL declare its attachment frame, truth source, signal chain, timing, output schema, and validity range.
Controller model
A controller SHALL declare its inputs, outputs, execution rate, state, configuration, and execution host.
Fixed parameter representation
A compiled physical parameter SHALL have a fixed value with declared type, units where physical, bounds where known, and provenance.
Property provenance
Engineering parameters SHALL support source, revision, author, calibration status, uncertainty, and applicable conditions.
Validity envelope
Every active model SHALL declare either a quantified operating envelope for its evidence or an explicit unqualified status.
Namespaced extensions
Non-core properties SHALL be stored in versioned namespaces so that unknown extensions can be preserved without being treated as active behavior.
Backend extension isolation
Backend-specific properties SHALL not change canonical semantics unless explicitly selected by the experiment.
Topology validation
The model validator SHALL detect dangling references, invalid joint graphs, duplicate identities, and illegal ownership cycles.
Inertia validation
The model validator SHALL detect non-positive mass, invalid inertia tensors, and implausible inertia relative to geometry using documented rules.
Content addressing
External, normalized, and compiled assets SHALL use the distinct raw-byte, semantic-content, and derived-artifact identity contracts accepted in ADR-0005 for run manifests and cache validation.
Human-reviewable manifest
A project SHALL include a documented, diffable manifest that identifies its primary assets and experiment definitions.
Atomic project save
Saving a project SHALL not leave a valid prior project in a partially overwritten state after interruption.
Unknown-data preservation
Loading and resaving a supported project SHALL preserve unknown namespaced data unless the user explicitly removes it.
Canonical numeric precision
Ordinary canonical continuous scalar, fixed-shape vector, matrix, tensor, and quaternion values SHALL use finite IEEE 754 binary64; source, canonical, and compute representations SHALL remain distinct, and any lower- or higher-precision storage or compute profile SHALL be versioned, capability declared, fidelity-visible, and unable to change canonical meaning silently.
Reusable model definition
A robot, device, material, sensor, or environment model definition SHALL be referenceable by multiple project entities without copying its source definition.
Instance override
A model instance SHALL declare its pose, stable identity, display name, and permitted parameter overrides separately from the referenced definition.
Multi-robot world
A world SHALL support multiple robot instances with distinct identities, frames, controllers, sensors, collisions, and communication namespaces.
Primitive geometry authoring
A user SHALL be able to define dimensioned box, sphere, capsule, and cylinder geometry without importing a mesh.
Named parameter binding
A named design or scenario parameter SHALL be bindable to documented geometry, material, device, sensor, controller, environment, or initial-state properties that accept its type and units.
Parameter distribution
An editable parameter definition SHALL support a documented probability distribution, physical bounds, and optional correlation group that is resolved to a fixed value before each run.
Engineering parameter domain
Every active engineering parameter schema SHALL declare finite-value, physical-domain, and cross-property consistency constraints, and compilation SHALL reject values that violate them.
Typed engineering property contract
Every recognized canonical engineering property SHALL declare a stable type identifier and schema version; value representation and shape; dimensions and units where applicable; frame, basis, or orientation where applicable; relation variables and domain where applicable; and uncertainty, provenance, and validity conditions using explicit known, unknown, not-supplied, or not-applicable states.
§7Asset Pipeline20
URDF import
BeforeMetal SHALL import the supported subset of URDF links, joints, visuals, collisions, inertials, limits, dynamics, and materials.
Import conversion and loss report
Every importer SHALL report each element or physical or material property that is ignored, unsupported, approximated, unit-converted, or semantically remapped.
Basic SDFormat import
BeforeMetal SHALL import a documented subset of SDFormat worlds, models, links, joints, collisions, visuals, terrain, and supported sensors.
Format version pinning
Every imported format SHALL record the declared or inferred format version used during conversion.
Coordinate normalization
Importers SHALL convert units, handedness, axis conventions, poses, and frame semantics into the canonical convention.
Mesh import
BeforeMetal SHALL import documented glTF 2.0, STL, and OBJ subsets for visual and collision geometry.
Collision suitability diagnostics
The Asset Pipeline SHALL warn when collision geometry is non-manifold, degenerate, excessively detailed, or unsupported by the selected backend.
Executable asset safety
Importing an asset SHALL never execute an embedded script, binary plugin, network reference, or command without explicit user authorization.
Path containment
Asset resolution SHALL reject path traversal outside authorized project and cache roots.
Export loss report
Every exporter SHALL produce a machine-readable report of properties that cannot be represented in the destination format.
MJCF interchange
BeforeMetal SHALL support a documented MJCF import or export subset when a MuJoCo compatibility workflow is enabled.
OpenUSD interchange
BeforeMetal SHALL support a documented OpenUSD authoring and import subset without making USD the runtime state store.
CAD ingestion
BeforeMetal SHALL permit CAD conversion through an isolated adapter that emits normalized geometry and a conversion report.
Asset cache
Normalized and compiled assets SHALL be cacheable by source hash, importer version, options, and target capability set.
Reproducible conversion
Identical source assets, importer versions, and options SHALL produce canonically equivalent normalized output.
Robot resource URI resolution
The Asset Pipeline SHALL resolve project-relative paths and explicitly configured package:// and model:// mappings without requiring ROS or network access.
Xacro input policy
The URDF importer SHALL detect unexpanded Xacro constructs, reject them without execution, and provide guidance for supplying pre-expanded URDF or enabling an optional external expander.
Imported property source context
A normalized engineering property SHALL retain any supplied source-property identity, source units, applicable conditions, and provenance.
Reference asset-pack manifest
Each distributed reference asset pack SHALL have a versioned manifest containing immutable content identities, source and revision provenance, license and redistribution terms, canonical conversion reports, required capabilities, and applicable evidence status.
Offline reference asset packs
A documented set of reference robot, sensor, environment, material, and device assets SHALL be installable, inspectable, and usable without network access after the pack has been obtained.
§8Scenario Compiler21
Explicit compilation
Editable project models SHALL be compiled into an immutable execution description before a run starts.
Capability negotiation
The compiler SHALL verify every required feature against the selected solver, device, sensor, controller, and extension capabilities.
Unsupported-feature rejection
A required unsupported capability SHALL be a compilation error unless an explicit documented approximation is selected.
Approximation acknowledgement
A selected approximation SHALL be included in the experiment definition and resulting fidelity card.
Dependency graph
The compiler SHALL construct a directed graph of subsystem inputs, outputs, and scheduling dependencies.
Algebraic-loop detection
The compiler SHALL detect direct-feedthrough cycles and reject them unless an enabled coupling solver explicitly supports the loop.
Rate compatibility
The compiler SHALL validate sample rates, phases, interpolation policies, and macro-step boundaries.
Port compatibility
The compiler SHALL validate unit, type, shape, frame, causality, and cardinality compatibility for every connected port.
Deterministic ordering
Equivalent compiled scenarios SHALL use stable entity and event ordering independent of hash-map or filesystem enumeration.
Initial-state consistency
The compiler SHALL detect invalid initial poses, joint limits, penetrations beyond policy, and missing required state.
Resource estimate
The compiler SHOULD estimate memory, storage, sensor bandwidth, and expected execution profile before a batch starts.
Compilation diagnostics
Every compilation error SHALL identify the entity, property, capability, and at least one corrective action.
Compiled artifact identity
A compiled scenario SHALL have a content identity derived from canonical inputs, compiler version, target capabilities, and options.
Pre-run fidelity preview
Before a run launches, the compiler SHALL produce a fidelity preview listing selected models and effects, required engineering properties, consuming capabilities, transformations, final property dispositions, inactive engineering properties, inactive or unsupported effects, approximations, validity warnings, and evidence status.
Fidelity profile enforcement
Each fidelity profile SHALL declare machine-checkable minimum qualification, convergence, uncertainty, and out-of-envelope policies, and the compiler SHALL enforce them or record an explicitly permitted experiment override.
Checkpoint capability closure
The compiler SHALL derive checkpoint-resume and input-re-execution guarantees from every stateful participant's snapshot, restore, determinism, and external-input capabilities and SHALL reject or explicitly downgrade an unsatisfied request.
Compiled property closure
For every engineering property required by the selected compiled model-and-effect graph, the compiler SHALL assign exactly one terminal disposition: consumed only when a compatible consuming capability resolves; explicitly approximated only when a documented replacement capability is selected under COMP-003 and COMP-004; or rejected with actionable diagnostics when neither path resolves.
Inactive property disclosure
Every authored or imported engineering property reachable by the compiled scenario but not required by its selected model-and-effect graph SHALL be classified and exposed as inactive rather than presented as affecting the run.
Engineering transformation record
Every unit, basis, numeric precision, representation, or model transformation applied to an active engineering value SHALL record its source and target semantics, its rounding and range or subnormal policy when numeric, and whether it is exact or lossy; a material lossy transformation SHALL produce an actionable preflight diagnostic.
Robot readiness report
The compiler SHALL emit a machine-readable readiness report covering topology, frames, inertial properties, joint limits and drives, collision geometry, device and sensor connections, controller interfaces, unresolved references, and unavailable required capabilities.
Runtime-action capability closure
The compiler SHALL validate every declared runtime-action type and version, statically referenced definition or target, payload schema, units, frames, resource bounds, required participant capabilities, and safe-boundary class and SHALL reject an unsupported action plan before execution.
§9Simulation Kernel and Time32
Authoritative virtual time
The Simulation Kernel SHALL own the single authoritative simulation time for each world.
Exact drift-free scheduling
The authoritative clock SHALL use bounded integer ticks under a reduced rational SI-second time base, and periodic task activation, phases, and rate relationships SHALL use exact integer or reduced-rational scheduling so floating-point clock drift does not accumulate over a run.
Multi-rate execution
Mechanics, controllers, devices, sensors, environment models, and metrics SHALL be schedulable at distinct rates.
Stable event order
Events sharing a timestamp SHALL execute in a documented deterministic order.
Fixed-step mechanics
The default mechanics profile SHALL support an explicitly configured fixed timestep and substep count.
Exact single-step
A paused world SHALL advance by exactly one requested kernel or mechanics step without advancing wall-clock-dependent tasks.
Pause semantics
Pausing SHALL stop virtual time while preserving compiled state and queued future events.
Reset semantics
Reset SHALL restore the declared initial world state, time, queues, controller state, device state, sensor state, and random streams.
Checkpoint
The kernel SHALL create a checkpoint containing all state required by its declared checkpoint-resume guarantee.
Restore
Restoring a supported checkpoint SHALL recreate the declared state and future deterministic behavior.
Capture and delivery time
Sampled data SHALL distinguish physical capture time from delivery time.
Delay queue
Latency models SHALL deliver values according to virtual time rather than wall time in deterministic and throughput modes.
Real-time pacing
The kernel SHALL support wall-clock pacing with measured offset, jitter, and deadline misses.
Unpaced throughput
Headless batch execution SHALL be able to advance as fast as resources permit without wall-clock sleeping.
Missed-deadline policy
A real-time integration SHALL declare and enforce a late-data policy such as hold, drop, extrapolate, fault, or stop.
Coupling macro-step
Coupled domains SHALL exchange committed values only at explicit macro-step or intermediate-update boundaries.
Interpolation policy
Every continuous cross-domain input SHALL declare sample-and-hold, linear interpolation, extrapolation, or solver-defined behavior.
Rollback capability
A participant SHALL declare whether it supports checkpoint and rollback; the scheduler SHALL not assume rollback support.
Topology-change boundary
Spawn, deletion, joint breakage, and other topology changes SHALL occur only at documented safe scheduling boundaries.
Rendering independence
Rendering frame rate and visibility SHALL not determine mechanics, control, sensor, or environment task activation.
Random-stream isolation
Each stochastic component SHALL have an independent deterministic stream so adding an unrelated component does not perturb existing streams.
Execution-mode declaration
Every run SHALL declare its execution mode and associated determinism guarantee.
No silent step skipping
A runtime policy SHALL not skip or merge a scheduled mechanics, device, controller, sensor, or environment activation without recording the affected time interval and reason.
Coupling algorithm declaration
Every iteratively coupled domain set SHALL declare its coupling algorithm, macro-step, participant order, relaxation, rollback capability, and maximum iterations.
Coupling convergence
An iterative coupling step SHALL evaluate declared residuals against absolute and relative convergence criteria and report iteration count and final residual.
Coupling nonconvergence policy
A coupled run SHALL apply a configured retry, reduced-step, rollback, warn, or fail policy when convergence is not achieved and SHALL never commit an unconverged step silently.
Coupling refinement evidence
A released coupled profile SHALL document selected-observable and exchanged-energy behavior under macro-step refinement.
Runtime-action ordering
The Simulation Kernel SHALL order accepted runtime actions by requested application time and deterministic sequence and SHALL apply them only at declared safe scheduling boundaries relative to other actions and events.
Runtime-action atomicity
A runtime action SHALL either commit its complete declared mutation at one scheduling boundary or fail without partial state mutation, and its actual application time, order, disposition, and resulting committed-state revision SHALL be exposed.
Entity-lifecycle actions
The General Robotics Beta runtime-action profile SHALL support spawning a content-identified compiled entity definition under a new stable identity and deleting a supported entity, subject to deterministic ownership, dependency, and topology validation.
Constrained state-override actions
The General Robotics Beta runtime-action profile SHALL support setting pose and other capability-declared mutable committed-state fields using explicit units and frames and a declared policy for dependent velocity, constraint, contact, and solver state.
Disturbance and fault actions
The General Robotics Beta runtime-action profile SHALL support scheduled activation, deactivation, or parameterization of compiled disturbances and supported external wrench or fault actions with explicit target, interval, units, frames, bounds, and composition policy.
§10Mechanics45
Double-precision baseline
The default engineering mechanics path SHALL support 64-bit floating-point state and parameters.
Rust-native default backend
The portable distribution SHALL provide a Rust-native mechanics backend that passes the MVP mechanics conformance and qualification suites.
Body modes
The default backend SHALL support dynamic, static, and kinematic rigid bodies.
Mass properties
Mechanics SHALL use explicit mass, center of mass, and positive-definite inertia tensor for dynamic bodies.
External wrench
A device or environment model SHALL be able to apply force and torque to a body at a specified frame and point.
Collision primitives
The default backend SHALL support box, sphere, capsule, and cylinder collision shapes.
Convex collision
The default backend SHALL support convex collision geometry.
Static mesh collision
The default backend SHALL support documented static triangle-mesh and terrain collision use.
Continuous collision detection
Bodies explicitly configured for continuous collision detection SHALL use it for the backend's documented velocity, shape, and timestep envelope.
Fixed joint
Mechanics SHALL support a fixed relative constraint between two bodies or a body and world.
Revolute joint
Mechanics SHALL support a one-axis revolute joint with limits, viscous damping, and drive input.
Continuous joint
Mechanics SHALL support an unlimited one-axis rotational joint.
Prismatic joint
Mechanics SHALL support a one-axis translational joint with limits, viscous damping, and drive input.
Ball joint
Mechanics SHALL support a three-axis rotational joint with documented limit behavior.
Articulated tree
The default backend SHALL simulate a tree-structured articulated robot.
Closed-loop mechanism
At least one mechanics backend SHALL support documented closed kinematic loops or loop-closing constraints.
Joint state
Mechanics SHALL expose joint position, velocity, applied command, limits, and available reaction information.
Joint drive
The default backend SHALL support documented position, velocity, and effort joint-drive modes with explicit command and effort limits.
Contact generation
Mechanics SHALL expose contact point, normal, penetration or separation measure, involved shapes, and available impulse or force estimate.
Surface friction
Contact response SHALL use explicit surface or material-pair friction parameters and a documented combination rule.
Restitution
Contact response SHALL support a documented coefficient-of-restitution model and combination rule.
Wet-friction contact update
The default mechanics contract SHALL accept committed material-pair friction updates derived from surface wetness at documented scheduling boundaries.
Compliant contact
At least one engineering profile SHALL support a calibrated compliant-contact model for documented applications.
Advanced friction
An engineering backend MAY support separate static and dynamic friction, Stribeck behavior, anisotropy, rolling resistance, and torsional resistance.
Collision filtering
A model SHALL be able to enable or suppress collision by explicit groups and pair rules.
Scene queries
The mechanics contract SHALL support ray casts, shape casts, and overlap queries required by sensors and tools.
Contact events
The mechanics backend SHALL produce deterministic contact-begin, current-contact, and contact-end observations under a documented policy.
Solver convergence diagnostics
Each default-backend step SHALL expose actual iteration counts, at least one documented convergence or constraint-error residual, joint error, maximum penetration, active-constraint count, iteration-limit hits, stabilization settings, and the applied unconverged-step warning or failure policy.
Energy diagnostics
The default mechanics backend SHALL expose kinetic and potential energy diagnostics sufficient for the approved analytical and reference-rover benchmarks.
Backend snapshot contract
The selected default mechanics backend SHALL participate in complete kernel checkpoint and restore.
Mechanics capability report
A backend SHALL report supported shapes, joints, contacts, precision, determinism, snapshot, and diagnostic capabilities.
Second-backend conformance
Any second production mechanics backend SHALL pass the shared mechanics capability and benchmark suite before release.
Deformable body backend
BeforeMetal MAY support beams, shells, cables, or volumetric deformables through a capability-scoped backend.
Granular and soil backend
BeforeMetal MAY support granular media and deformable terrain through a capability-scoped backend.
Structural failure
BeforeMetal MAY support calibrated yield, damage, breakage, fatigue, and fracture models with explicit validity limits.
Derived mass properties
BeforeMetal SHALL derive mass, center of mass, and inertia from supported closed geometry and assigned density when requested, while retaining any explicit user override.
Compound rigid body
A rigid body SHALL support multiple collision shapes and their local transforms without requiring artificial fixed joints.
Force contribution diagnostics
A user SHALL be able to inspect supported force and torque contributions by source, including gravity, contact, devices, and environment loads.
General contact modification
At least one Engineering-profile mechanics backend SHALL expose capability-checked contact modification based on material, direction, temperature, speed, pressure, or other committed state.
Evidence-declared wheel-terrain model
The reference rover SHALL use a documented wheel-terrain model covering longitudinal and lateral slip, rolling resistance, normal load, speed, wetness, parameter and evidence provenance, qualification status, and validity limits for the accepted mission envelope.
Dynamic-analysis coordinate contract
Every mechanics analysis request and result SHALL identify its source compiled scenario, committed state, and virtual time; ordered generalized position, tangent-velocity, acceleration, and force coordinates; canonical entity and degree-of-freedom mappings; units; frames or bases; and sign convention.
Generalized mass matrix
At least one portable General Robotics Beta mechanics profile SHALL expose a backend-neutral generalized mass-matrix query for a declared state and declared constraint and contact treatment using the MECH-041 coordinate contract.
Bias and gravity decomposition
At least one portable General Robotics Beta mechanics profile SHALL separately expose velocity-dependent inertial-bias and gravity generalized-force terms under a declared equation convention and SHALL identify whether passive, actuator, contact, constraint, and external-load terms are excluded or reported separately.
Generalized-force mapping
At least one portable General Robotics Beta mechanics profile SHALL map named body wrenches and joint loads to generalized forces and SHALL report included device, environment, contact, and constraint contributions separately by source where supported.
Inverse dynamics
At least one portable General Robotics Beta mechanics profile SHALL compute required generalized effort from a declared state, requested generalized acceleration, and supported external loads and SHALL report equation convention, contact and constraint treatment, residual and status, and unavailable contributions.
§11Environment40
Environment field contract
An environment field SHALL return a typed, unit-bearing value for a specified position and virtual time and SHALL declare its spatial and temporal domain.
Deterministic field sampling
A deterministic environment configuration SHALL return equivalent samples for equivalent position, time, configuration, and seed.
Uniform gravity
A world SHALL support a configurable uniform gravity vector.
Spatial gravity
A world MAY support position- and time-dependent gravity fields.
Atmosphere state
A world SHALL support air density, pressure, temperature, and humidity as explicit environment properties.
Uniform wind
A world SHALL support a configurable uniform wind-velocity vector.
Wind gust
A world SHALL support deterministic or seeded time-varying wind gusts.
Spatial wind
A world SHALL support a sampled three-dimensional wind field with interpolation metadata.
Turbulence model
A world SHOULD support at least one documented stochastic turbulence model with parameter provenance.
Aerodynamic load approximation
The Environment System SHALL compute a documented aerodynamic wrench from local air-relative velocity, sampled wind and air density, reference area, coefficient frame, coefficients, and center of pressure and SHALL apply it at a declared body frame and point.
Aerodynamic surface model
A model SHALL support surface-specific drag and lift parameters over a documented validity envelope.
Rotor aerodynamic model
BeforeMetal MAY support blade-element, momentum, wake, or externally coupled rotor models.
Precipitation rate
A world SHALL represent rain using a typed precipitation-rate field.
Surface wetness
In the reference weather workflow, surface wetness SHALL evolve from precipitation flux through a bounded exposure, accumulation, and drying model; direct wetness input SHALL be recorded as an explicit approximation.
Wet contact effect
The active contact model SHALL derive material-pair friction from surface wetness using a documented relationship and validity range.
Visibility effect
Precipitation and atmosphere models SHALL be able to expose visibility or attenuation inputs to supported sensors and rendering.
Sensor weather query
A sensor SHALL query environment properties through the same committed field state used by other subsystems.
Weather timeline
An experiment SHALL support scheduled changes in supported weather parameters.
Weather randomization
Weather parameters and field seeds SHALL be eligible for declared experiment distributions.
Terrain geometry
A world SHALL support static plane, mesh, and documented height-field terrain representations.
Terrain material regions
Terrain SHALL support spatial regions with distinct engineering surface materials.
Terrain slope and obstacle support
The reference rover world SHALL support slopes, steps, and rigid obstacles.
Surface temperature
Terrain and exposed bodies SHALL be able to query or carry a simplified surface-temperature state.
Thermal convection input
Atmosphere and wind fields SHALL expose inputs required by supported convective-cooling approximations.
Magnetic field
A world SHALL support a configurable magnetic-field vector for magnetometer simulation.
Illumination state
A world SHALL expose illumination state required by camera and light-sensitive sensor models.
Water and puddles
BeforeMetal MAY support standing water, buoyancy, added mass, drag, and free-surface effects through explicit fidelity levels.
Ingress and corrosion
BeforeMetal MAY support calibrated moisture ingress, corrosion, and environment-driven failure models.
External CFD field
BeforeMetal SHALL permit a precomputed or live external flow field to be sampled through an optional adapter.
Environment capability report
Every environment model SHALL report its outputs, rates, stochastic behavior, validity range, and required inputs.
Precipitation occlusion
Geometry SHALL be able to shield surfaces and supported sensors from precipitation under a documented exposure model.
Rain mechanical load
Configured exposed surfaces SHALL support a documented aggregate momentum-transfer model for rainfall.
Fog and aerosol field
A world SHALL support a concentration or extinction field for documented fog, dust, smoke, or aerosol sensor effects.
Snow and ice state
A surface MAY carry snow or ice accumulation, traction, thermal, and melting state through explicit models.
Vacuum and planetary atmosphere
A world MAY select vacuum, rarefied, or non-Earth atmosphere properties without changing canonical unit and field contracts.
Radiative environment
A world MAY expose solar, infrared, and other declared radiative fluxes to supported thermal, material, and sensor models.
Environment provenance
Imported terrain, weather, and field data SHALL retain source, timestamp or epoch where applicable, spatial reference, resolution, and transformation metadata.
World georeference
A world SHALL support a declared geodetic reference, origin, and mapping to the canonical local frame.
Weather dataset import
BeforeMetal SHALL import time-series or gridded weather data through a documented schema with unit, time, and spatial validation.
Field sampling policy
Every sampled environment field SHALL declare resolution, interpolation, extrapolation, missing-data, boundary, and out-of-domain behavior.
§12Materials23
Visual and engineering separation
Visual appearance SHALL be stored separately from engineering material behavior.
Stable material identity
An engineering material SHALL have a stable identifier and revision independent of its display name.
Density
A bulk material SHALL support density with units, source, uncertainty, and applicable conditions.
Surface friction
A surface material SHALL support the friction parameters required by the selected contact model.
Restitution
A surface material SHALL support restitution with applicable impact conditions and provenance.
Aerodynamic coefficients
A material or aerodynamic surface SHALL support documented drag and optional lift coefficients without conflating them with visual properties.
Material-pair behavior
Contact behavior SHALL be resolvable from the ordered or unordered pair of interacting surface materials under a documented rule.
State-dependent property relation
An active condition- or state-dependent property relation SHALL declare its independent variables, units, and validity domain and, when represented by sampled or tabulated data, its interpolation and extrapolation policy.
Consistent elastic properties
An elastic material SHALL declare its symmetry class and independent elastic parameters; redundant moduli SHALL be derived or checked within a declared consistency tolerance.
Thermal properties
An engineering material SHALL support heat capacity, thermal conductivity, emissivity, and temperature limits when required by an enabled model.
Consistent electrical properties
An engineering material SHALL support an independent conductivity or resistivity representation, derive or consistency-check its reciprocal, and declare dielectric and temperature-coefficient data when required by an enabled model.
Strength and inelastic properties
An engineering material MAY support yield, ultimate strength, hardening, ductility or formability, creep, viscoelasticity, fatigue, fracture, plasticity, and damage data.
Uncertainty
Every engineering property SHALL be able to carry an uncertainty or explicitly state that uncertainty is unknown.
Provenance
Every published catalog property SHALL identify its source, source revision, extraction method, and curator.
Validity conditions
A property SHALL be able to declare temperature, rate, orientation, treatment, and other conditions that bound its applicability.
Catalog revisioning
Material catalog updates SHALL create a new revision without silently changing completed run manifests.
User material
A user SHALL be able to define a project-local engineering material without modifying the built-in catalog.
Calibrated surface pair
A user SHALL be able to calibrate a material-pair interaction while retaining raw observations and the uncalibrated source values.
Out-of-envelope warning
Use of a material property outside its declared validity conditions SHALL be included in run diagnostics and the fidelity card.
Solver-consumed property namespace
Constitutive, transport, resistive or dissipative, surface or interfacial, and other solver-consumed material-model data SHALL be versioned, namespaced, and capability checked rather than treated as universal material constants.
Wet-friction relation
A surface-material pair used with evolving wetness SHALL define a dry-to-wet friction relation, provenance, and validity range.
Multiphysics property namespace envelope
Canonical material definitions SHALL reserve versioned namespaces for inertial, contact, constitutive, transport, resistive or dissipative, thermal, electrical, magnetic, optical or radiative, and chemical or degradation property-model families without implying standardized family semantics or active solver support.
Declared property evaluation inputs
A state-dependent engineering property relation SHALL evaluate only from its declared committed-state inputs and declared internal history or state where applicable.
§13Devices, Power, Circuits, Thermal, and Firmware53
Typed device ports
Every device port SHALL declare quantity type, units, direction, frame where applicable, rate, causality, and cardinality.
Device state lifecycle
A device SHALL support initialization, step or activation, reset, snapshot where declared, restore where declared, and shutdown.
Actuator command contract
An actuator SHALL accept a timestamped command through a declared command mode and bounds.
Actuator saturation
An actuator SHALL support documented magnitude, rate, and state-dependent saturation.
Actuator latency
An actuator SHALL support deterministic or seeded command delay through virtual time.
Actuator deadband
An actuator SHOULD support documented deadband and hysteresis where applicable.
Reference motor model
The portable product SHALL provide the brushed-DC or behavioral-BLDC motor family selected by TBD-REFERENCE-MOTOR, relating voltage, current, speed, torque, losses, inertia, and limits.
Motor family coverage
The portable product SHALL provide both a parameterized brushed-DC motor model and a documented system-level behavioral BLDC motor model.
Torque-speed envelope
A motor SHALL enforce a documented torque-speed operating envelope.
Motor current limits
A motor model SHALL expose and enforce configured continuous and peak current limits under a documented policy.
Gear ratio
A transmission SHALL transform speed and torque according to an explicit ratio and efficiency model.
Transmission efficiency
A transmission SHALL support direction- and operating-point-dependent efficiency or a documented constant approximation.
Backlash
A transmission SHOULD support a documented backlash model.
Compliance
A transmission or actuator SHOULD support a documented stiffness and damping model.
Brake model
A device SHALL be able to apply passive or commanded braking subject to limits.
Servo abstraction
The portable product SHALL support a configurable servo composed from controller, motor, transmission, limits, and sensing elements.
Battery state of charge
A battery SHALL track state of charge and delivered or absorbed charge over virtual time.
Battery voltage
A battery SHALL provide open-circuit voltage as a function of state under a documented approximation.
Battery internal resistance
A battery SHALL model terminal-voltage drop and heat generation from a documented internal-resistance model.
Battery current limits
A battery SHALL expose and enforce charge and discharge current limits under a documented policy.
Battery energy accounting
A run SHALL report energy delivered, recovered, dissipated, and remaining under the active power model.
Power bus
Devices SHALL be connectable to a power bus that resolves supported voltage, current, and power flows.
Converter efficiency
Regulators, inverters, and converters SHALL support operating-point-dependent or documented fixed efficiency and limits.
Power balance diagnostic
The Device and Power System SHALL report violations of supported energy or power-balance checks.
Simplified thermal node
A device SHALL be able to participate in a lumped thermal network with heat capacity, sources, sinks, and limits.
Device fault injection
An experiment SHALL be able to schedule supported open, stuck, degraded, noisy, limited, overheated, or disconnected device faults.
Fault observability
Every injected fault SHALL appear in the run manifest and event timeline.
Component catalog
BeforeMetal SHALL support revisioned reusable device models with provenance, uncertainty, and validity envelopes.
Manufacturer model distinction
Catalog metadata SHALL distinguish manufacturer data, inferred data, calibrated data, and assumed data.
Circuit topology
The Circuit System SHALL represent electrical nodes, branches, component connections, reference nodes, and declared initial conditions when the native circuit capability is scheduled.
SPICE adapter
BeforeMetal SHALL permit selected circuits to be simulated by an optional external SPICE-compatible adapter.
Firmware-defined device
A device MAY exchange peripheral and bus state with an optional virtual firmware platform.
Device capability report
A device model SHALL report command modes, states, ports, limits, rates, snapshot support, stochastic behavior, and validity range.
Electrical primitives
The native Circuit System SHALL support resistors, capacitors, inductors, independent voltage and current sources, controlled switches, diodes, wiring, and system-level loads when that capability is scheduled.
DC network solution
The native Circuit System SHALL solve supported DC operating-point networks and report convergence or failure when that capability is scheduled.
Transient network solution
The native Circuit System SHALL advance supported time-domain electrical networks under the Simulation Kernel's declared coupling policy when that capability is scheduled.
Reference electromechanical coupling
The reference motor, battery, power bus, and mechanics models SHALL exchange voltage, current, torque, speed, loss, and back-EMF state on documented scheduling boundaries.
Thermal network
The native Thermal System SHALL represent lumped thermal capacitances, conductances, heat sources, boundary conditions, and temperature limits when that capability is scheduled.
Cross-domain energy accounting
The reference mechanical and electrical models SHALL report transferred, stored, recovered, and dissipated energy using one declared sign convention; enabled thermal models SHALL use the same convention.
Wiring model
A wiring element SHALL support resistance, current limit, connector or branch identity, and injected open or short faults.
Digital logic
The Circuit System SHALL support event-driven Boolean and finite-width digital signals with declared voltage-threshold abstraction when that capability is scheduled.
Robot communication buses
BeforeMetal SHALL provide typed UART, SPI, I2C, and CAN bus abstractions without requiring instruction-level firmware emulation.
Bus timing and faults
A communication bus SHALL model configured rate, arbitration where applicable, latency, queueing, corruption, dropout, and disconnection behavior.
Compute resource abstraction
A compute device SHALL support task or inference latency, deadline, utilization, power, temperature, and failure state without claiming processor-cycle fidelity.
Firmware target manifest
A firmware-emulation adapter SHALL report supported instruction sets, boards, peripherals, timers, interrupts, and bus interfaces before execution.
Firmware clock synchronization
A firmware-emulation adapter SHALL map virtual CPU time, timers, interrupts, and peripheral events to the Simulation Kernel's declared time contract.
Hydraulic actuation
BeforeMetal MAY support lumped hydraulic sources, valves, lines, cylinders, compliance, leakage, and limits through a capability-scoped model.
Pneumatic actuation
BeforeMetal MAY support lumped pneumatic sources, valves, lines, cylinders, compressibility, leakage, and limits through a capability-scoped model.
Communication link
A logical wired or wireless data link SHALL support bandwidth, latency, jitter, queue, dropout, range policy, and connection-state models.
Aging and wear
A device MAY support calibrated cycle, time, temperature, load, or environment-dependent degradation with explicit state and validity limits.
Temperature-dependent device limits
A device with thermal limits SHALL derive derating, shutdown, or failure behavior from committed Thermal System state under a documented policy.
Portable power execution
The Portable MVP SHALL use a documented motor-battery-bus coupling phase and SHALL reject power configurations outside the supported reference topology or requiring an unavailable general circuit solver.
Reference DC algebraic solve
Each reference power update SHALL solve the supported battery internal-resistance, wiring-resistance, and motor back-EMF relationship consistently at one virtual time and SHALL report saturation, nonexistence, or numerical failure.
§14Sensors39
Sensor pipeline
Every sensor SHALL implement or explicitly bypass the stages truth, sampling, environmental interaction, calibration, noise, quantization, saturation, latency, dropout, and delivery.
Truth separation
Ideal truth and sensor-modeled delivered measurement SHALL be addressable as distinct channels with different access permissions.
Independent clock
Every sensor SHALL declare sample rate, phase, and integration or exposure interval where applicable.
Capture timestamp
Every measurement SHALL identify its capture time or capture interval.
Delivery timestamp
Every delivered measurement SHALL identify or permit derivation of its delivery time.
Sensor frame
Every spatial sensor output SHALL identify the frame in which its value is expressed.
Units and shape
Every sensor output SHALL declare units, scalar type, dimensions, and bounds where defined.
Calibration revision
A measurement SHALL identify the calibration revision used to produce it.
Noise model
A sensor SHALL support a documented seeded noise model or explicitly declare ideal output.
Bias and drift
Supported sensors SHALL be able to model constant bias and time-correlated drift.
Quantization
A sensor SHALL be able to quantize measurements to a configured resolution.
Saturation
A sensor SHALL be able to saturate measurements at configured operating limits.
Latency and jitter
A sensor SHALL support fixed or seeded latency and jitter distributions in virtual time.
Dropout
A sensor SHALL support deterministic or seeded measurement and packet dropout.
Misalignment
A sensor SHALL support calibrated translation and rotation misalignment from its nominal frame.
Quality metadata
A measurement SHOULD expose covariance or quality flags when the active model can estimate them.
Encoder
BeforeMetal SHALL provide a joint or shaft encoder with configurable resolution, rate, noise, bias, and latency.
IMU
BeforeMetal SHALL provide accelerometer and gyroscope measurements with correct frame, gravity/specific-force semantics, rate, bias, drift, noise, saturation, and latency.
Range sensor
BeforeMetal SHALL provide a ray- or shape-query range sensor with configurable field, range, resolution, noise, dropout, and latency.
Joint-state sensor
BeforeMetal SHALL expose joint position and velocity after the configured sensor signal chain separately from privileged mechanics truth.
Contact sensor
BeforeMetal SHALL provide a configurable contact-presence or contact-load measurement based on mechanics contact data.
Force-torque sensor
BeforeMetal SHALL support a six-axis force-torque sensor with frame, range, noise, bias, latency, and optional compliance.
GNSS or navigation sensor
BeforeMetal SHALL support a configurable global-position measurement and quality model when a world georeference is defined.
Magnetometer
BeforeMetal SHALL support magnetometer measurements using world field, sensor frame, bias, noise, saturation, and disturbances where modeled.
Camera
BeforeMetal SHALL support timestamped color and depth image capture with declared projection, exposure, resolution, distortion support, and latency.
LiDAR
BeforeMetal SHALL support timestamped scan geometry, per-ray timing where enabled, range limits, noise, dropout, and weather degradation.
Rolling shutter
A camera MAY support row-dependent capture timing and platform motion during exposure.
Radar and sonar
BeforeMetal MAY support radar and sonar through explicit phenomenological or wave-based fidelity models.
Weather degradation
A sensor model SHALL declare every supported environment dependency, and each enabled degradation stage SHALL consume the corresponding committed environment state.
Independent randomness
A sensor's stochastic stream SHALL not change because another sensor is added, removed, or reordered.
Sensor capability report
Every sensor SHALL report truth dependencies, signal stages, rates, output schema, stochastic behavior, and validity envelope.
Electrical measurement
BeforeMetal SHALL provide voltage, current, and power measurements with configurable range, resolution, rate, noise, bias, and latency.
Temperature measurement
BeforeMetal SHALL provide component or environment temperature measurements through the standard sensor signal chain.
Atmospheric measurement
BeforeMetal SHALL provide pressure, humidity, and supported gas or air-property measurements through the standard sensor signal chain.
Tactile array
BeforeMetal MAY provide spatially distributed contact pressure or force measurements when the selected contact backend exposes sufficient information.
Rain-degraded range sensing
The reference range sensor SHALL apply a named, parameterized, and benchmarked precipitation or visibility effect that measurably changes its delivered range, noise, or dropout behavior.
Fidelity-required sensor stages
Each fidelity profile SHALL declare mandatory and permitted-to-bypass sensor pipeline stages for every selected sensor, and the compiler SHALL reject a configuration that bypasses a mandatory stage.
Stable annotation identity
Every semantic or instance annotation SHALL reference a stable entity identity and a versioned label taxonomy rather than deriving identity from display color, render order, or collection order.
Synthetic ground-truth products
BeforeMetal SHALL provide synchronized depth, semantic segmentation, instance segmentation, two-dimensional bounding-box, three-dimensional bounding-box, and object-pose truth products with declared frames, units, capture times, visibility or occlusion semantics, and generating capabilities.
§15Controllers and ML47
Trusted native Rust controller
The portable product SHALL execute first-party or explicitly trusted, content-hashed Rust controller artifacts through a documented in-process contract.
Controller lifecycle
A controller SHALL support configure, initialize, reset, observe, act, snapshot where declared, restore where declared, and shutdown.
Timestamped observation
Controller observations SHALL identify the virtual time and source timing of their data.
Timestamped action
Controller actions SHALL identify their intended application time or use a documented next-activation policy.
Controller rate
A controller SHALL declare its activation rate and phase.
Controller state
Stateful controllers SHALL declare whether their state participates in checkpoint and restore.
Native controller failure
A native controller panic or invalid output SHALL terminate or degrade the run according to an explicit experiment policy.
Action bounds
Controller outputs SHALL be validated against port type, unit, shape, finite-value, and configured bounds before application.
Multiple controllers
BeforeMetal SHALL support multiple independently scheduled controllers with explicit ownership or arbitration of command ports.
Safety limiter
An experiment SHALL be able to apply a deterministic command-limiting layer between controller output and actuator input.
Wasm controller
The portable product SHALL support a sandboxed Wasm controller profile with declared resource and host capabilities.
Process controller protocol
BeforeMetal SHALL expose a versioned external process protocol for initialization, reset, observations, actions, step coordination, termination, and errors.
Python controller adapter
BeforeMetal SHALL provide or permit an optional Python SDK over the process controller protocol.
ROS 2 controller adapter
BeforeMetal SHALL permit a ROS 2 bridge to exchange clock, state, sensor, command, transform, and diagnostic data.
ONNX inference boundary
BeforeMetal SHALL validate ONNX model inputs, outputs, types, shapes, layouts, and supported operators before execution; in-process execution SHALL use only a pure-Rust implementation, while ONNX Runtime and vendor execution providers SHALL run in an optional sidecar.
Controller resource measurement
BeforeMetal SHALL measure controller execution time, deadline misses, and supported memory or process resource data.
Native controller trust gate
Project-supplied native controller code SHALL remain unbuilt and unexecuted until the user explicitly trusts its identity for the project or workspace.
Isolated controller deadline
A Wasm or process controller SHALL have a configured response deadline and timeout policy enforceable without relying on cooperative in-process preemption.
External activation identity
Every external controller observation and action SHALL carry world, episode, and activation identities in addition to simulation time.
External action acceptance
A process controller SHALL accept at most one action per activation and SHALL enforce configured duplicate, stale, future, late, timeout, and invalid-action policies.
External disconnect and backpressure
A process controller SHALL declare disconnect, reconnect, input-queue, output-queue, and backpressure behavior before activation.
Forward-kinematics query
BeforeMetal SHALL expose a backend-neutral query for named body and frame poses, spatial velocities, and supported Jacobians with explicit joint ordering, coordinates, units, frames, virtual time, and source state identity.
Inverse-kinematics query
BeforeMetal SHALL expose a backend-neutral inverse-kinematics query with named frames, start state, target constraints, joint limits, tolerances, solution status, and actionable infeasibility diagnostics.
Planning-scene snapshot
A planning participant SHALL receive an immutable, timestamped snapshot identifying robot state, collision geometry, allowed-collision policy, static and supported dynamic obstacles, frames, and source compiled scenario.
Canonical motion trajectory
A motion trajectory SHALL declare named joints or frames, units, timestamps or timing law, interpolation and continuity semantics, limits, provenance, and feasibility status independently of any planner's native representation.
Motion-planner protocol
BeforeMetal SHALL expose a versioned planner protocol that accepts a planning-scene snapshot, start and goal conditions, constraints, seed, and resource budget and returns status, candidate trajectories, planner identity and settings, termination reason, and diagnostics.
Plan execution gate
A candidate motion trajectory SHALL not command the simulation until it has been explicitly selected and checked against the current compiled scenario, state identity, joint and actuator limits, timing constraints, and supported collision policy.
Controller-restart action
A runtime action SHALL be able to restart a supported controller at a safe boundary under an explicit policy for controller state, pending observations and actions, held outputs, random streams, initialization, and restart failure.
State and control derivatives
At least one portable General Robotics Beta profile SHALL expose continuous-dynamics or discrete-transition state and control Jacobians at a named operating point with ordered coordinates, units, frames, source identities, timestep or integrator semantics, derivative method, perturbation and tolerance settings, active mode, residuals, conditioning, and declared handling of one-sided, undefined, or unavailable derivatives.
Canonical linearization artifact
BeforeMetal SHALL produce a versioned, content-identified linearization artifact binding its source compiled scenario, operating point, continuous- or discrete-time semantics, ordered state, control, and output coordinates, matrices, affine or equilibrium residual, sampling or integration settings, derivative identity, active mode, and declared local validity bounds.
Nonsmooth derivative boundary
A derivative or linearization request at contact onset, saturation, mode transition, hybrid event, or another condition outside the selected capability's declared smoothness envelope SHALL return a structured unavailable or one-sided diagnostic rather than an unqualified matrix.
Native environment transition API
The native API SHALL provide reset(seed, options) -> (observation, info) and step(action) -> (observation, reward, terminated, truncated, info) transitions with typed schemas.
Observation schema
An ML observation SHALL declare names, types, shapes, units, frames, bounds, and sample timing.
Action schema
An ML action SHALL declare names, types, shapes, units, target ports, bounds, and application timing.
Seeded reset
Resetting the same compiled scenario with the same seed and options SHALL reproduce all declared stochastic initialization.
Domain randomization
An experiment SHALL support seeded randomization of declared robot, device, sensor, material, and environment parameters.
Randomization record
Every sampled parameter SHALL be recorded in the episode or run manifest.
Termination distinction
The native API SHALL distinguish task termination from administrative truncation.
Reward decomposition
A task SHALL expose named reward or score components rather than only one opaque scalar.
Batched environments
BeforeMetal SHALL support multiple independent headless worlds through a batched control interface.
Gymnasium wrapper
BeforeMetal SHALL provide or permit an optional Gymnasium-compatible wrapper over the native environment API.
Multi-agent wrapper
BeforeMetal MAY provide a multi-agent API with per-agent observations, actions, rewards, and lifecycle.
Training-framework boundary
BeforeMetal SHALL not require or implement a specific ML training framework in the portable core.
Batched transition semantics
A batched environment API SHALL provide stable environment identities and ordering, per-environment reset, and explicit partial-failure behavior.
Policy asset manifest
An inference policy asset SHALL record content hash, input and output tensors, normalization, backend identity, operator coverage, numerical mode, and applicable controller configuration.
Episode dataset export
BeforeMetal SHALL export synchronized observations, actions, rewards, termination state, causal timestamps, realized parameters, and selected truth through a versioned dataset schema.
Inference timing model
Online policy evaluation SHALL support measured or configured inference latency and deadline behavior in simulation time.
§16Experiment Orchestrator24
Immutable run specification
A launched run SHALL reference an immutable compiled scenario, controller identity, seed, initial state, metric set, and stop conditions.
Run identity
Every run SHALL receive a stable unique identity before execution begins.
Stop conditions
An experiment SHALL support virtual-time, mission, safety, failure, convergence, and explicit user stop conditions where applicable.
Early termination
A metric or guard SHALL be able to terminate a run with a named reason at a safe scheduling boundary.
Named metrics
An experiment SHALL select metrics by stable identity and version.
Reference rover metrics
The reference experiment SHALL report mission success, elapsed time, trajectory tracking or declared reference-comparison measures, stability, slip indicators, torque, current, energy, and termination reason.
Finite parameter sweep
The orchestrator SHALL generate and execute the Cartesian product or explicit list of selected parameter values.
Random sampling
The orchestrator SHALL generate repeatable samples from declared parameter distributions.
Correlated sampling
The orchestrator SHALL support documented correlation among selected parameters.
Repetitions
An experiment SHALL support repeated runs with explicit seed policy.
Variant comparison
A result set SHALL compare metrics across robot, controller, and scenario variants without requiring identical internal backend state.
Independent-world parallelism
The orchestrator SHALL execute independent worlds concurrently subject to deterministic mode and resource policies.
Progress and cancellation
A batch SHALL expose progress and support graceful cancellation without marking incomplete runs as complete.
Resume batch
A batch SHALL resume pending runs without repeating verified completed runs unless explicitly requested.
Resource budget
An experiment SHALL support configured CPU, memory, GPU, storage, virtual-time, and wall-time budgets where measurable.
Monte Carlo summary
A stochastic experiment SHALL report sample count, seed policy, distributions, confidence summaries, and failed-run handling.
Sensitivity analysis
BeforeMetal SHOULD support local or global sensitivity analysis for selected parameters and metrics.
Parameter calibration
BeforeMetal SHALL support calibration of selected parameters against a declared calibration dataset and objective.
Held-out separation
Calibration workflows SHALL prevent designated validation observations from being used by the fitter.
Optimization hook
BeforeMetal MAY expose experiment evaluation to an external design-optimization algorithm.
Pareto comparison
BeforeMetal MAY report Pareto-efficient designs for multiple selected objectives and constraints.
Runtime-action plan
An experiment SHALL support a versioned plan of stable-identity runtime-action requests whose type and version, origin, target or compiled definition, requested virtual time or trigger, typed payload, bounds, and invalid, late, or failure policy are fixed before the run.
Calibration result record
Every completed calibration SHALL record parameter identities, bounds, initial and final values, residual definitions and weights, time alignment or delays, dataset identities, optimizer identity and settings, seed where applicable, termination and convergence status, final residuals, and uncertainty method and result.
Practical identifiability diagnostics
A multi-parameter calibration SHALL provide a local practical-identifiability analysis using a declared rank-revealing method and SHALL report parameter scaling, sensitivity source, observation weights, sample points, rank criterion, spectrum or conditioning, correlated or near-null directions, and an explicit unidentifiable result where applicable.
§17Result Store24
Run manifest
Every run SHALL produce a manifest containing project and asset hashes; compiled scenario identity; software, solver, controller, extension, adapter, FMU, and ML-runtime identities; protocol versions; granted permissions and sandbox modes; RNG algorithm and stream layout; options; seeds; platform; execution mode; fidelity; calibration identities; and termination state.
Incomplete-run state
An interrupted or failed run SHALL remain identifiable as incomplete and SHALL not be reported as a successful result.
Structured event timeline
A run SHALL record selected contacts, limits, faults, sensor deliveries, controller activations, warnings, checkpoints, and termination events with virtual timestamps.
Selectable telemetry
A user SHALL select state and metric channels to record at declared rates.
Open time-series export
Selected scalar telemetry SHALL be exportable as unit-annotated CSV, and run summaries and manifests SHALL be exportable as documented JSON.
Snapshot storage
Supported checkpoints SHALL be storable with version, backend, and integrity metadata.
Re-execution inputs
A run declaring input re-execution support SHALL retain all non-derivable inputs, events, seeds, and state required by its declared comparator.
Re-execution verification
Input re-execution SHALL report the compared channels, comparator, tolerances, build and platform scope, known nondeterministic participants, and first detected divergence.
Compression
Time-series, sensor, event, and snapshot data SHALL support configurable compression with integrity checks.
High-volume sensor data
Image, point-cloud, and other bulk data SHALL be stored without forcing serialization into scalar event records.
Schema versioning
Every persisted manifest, trace, event, telemetry, and snapshot schema SHALL be versioned.
Integrity check
Persisted run artifacts SHALL support detection of truncation or content corruption.
Run comparison
BeforeMetal SHALL produce a report of configuration, software, seed, fidelity, and selected metric differences between two runs.
Result-set summary
A batch SHALL produce aggregate status and metric summaries while retaining per-run results.
Data retention policy
A workspace SHALL support explicit retention or deletion policy for derived caches, traces, snapshots, and bulk sensor data.
MCAP export
BeforeMetal SHALL permit export of supported message streams and attachments to MCAP through an optional adapter.
Parquet export
BeforeMetal SHOULD support Parquet export for tabular experiment and time-series analysis.
Reproduction bundle
BeforeMetal SHALL create a bundle or manifest that identifies all distributable inputs required to reproduce a run.
Causal journal
Independently of user-selected telemetry, a re-executable run SHALL record every state-affecting input, runtime-action request and disposition when present, asynchronous order, arbitration decision, limiter result, dropped or late decision, sidecar output, and capture, admission, delivery, decision, and application time with deterministic sequence numbers.
Reproduction mode declaration
A run SHALL separately declare support and criteria for input re-execution, checkpoint resume, and recorded-state playback.
Dependency-aware retention
Deleting an artifact required by a reproduction mode SHALL require confirmation and SHALL update the affected run's manifest and status so that mode is no longer reported as available.
Synthetic dataset writer contract
BeforeMetal SHALL expose a versioned writer contract for bulk synthetic datasets that preserves canonical record semantics independently of exporter-specific directory, archive, or object-store layouts and reports every lossy conversion.
Synthetic dataset manifest
Every exported synthetic dataset SHALL identify its schema and writer, source runs, compiled scenarios, assets, annotation taxonomy, selected truth and sensor channels, frames, capture timing, seeds, realized randomization, software identities, completeness, and integrity metadata.
Regression evidence record
Each simulation regression result SHALL identify the case and suite revisions, expected-baseline content identities, compiled scenario and run identities, build, platform, capabilities, execution mode, seeds, runtime-action dispositions, comparator configuration, expected and actual values, first mismatch where applicable, termination state, diagnostics, and artifact integrity.
§18Validation and Fidelity36
Fidelity card
Every completed run SHALL include a fidelity card listing active models and effects, solver settings, engineering-property transformations and final dispositions, inactive engineering properties, inactive or unsupported effects, approximations, parameter evidence, validity warnings, and applicable evidence references or their explicit absence.
Per-capability qualification
Qualification status SHALL be assigned to a model capability and use case rather than to BeforeMetal as one undifferentiated product.
Qualification vocabulary
BeforeMetal SHALL define and use documented statuses for unqualified, analytically or numerically verified, reference-benchmarked, calibrated, compared with independent reference data, and physically validated models where applicable.
Observable-specific comparison
Any validation or independent-reference comparison SHALL report error or a pass criterion for named observables, operating conditions, and identified evidence sources rather than one universal accuracy percentage.
Analytical benchmark suite
The Validation System SHALL include the versioned analytical cases and tolerances approved under TBD-VAL-ANALYTICAL for free fall, projectile motion, pendulum motion, energy behavior, and supported actuator equations.
Contact benchmark suite
The Validation System SHALL include the versioned contact cases and tolerances approved under TBD-VAL-CONTACT for restitution, incline stick-slip, stacking, penetration, friction behavior, and repeatability.
Joint benchmark suite
The Validation System SHALL include the versioned joint cases and tolerances approved under TBD-VAL-JOINT for kinematics, limits, drives, constraint drift, and articulated chains.
Device benchmark suite
The Validation System SHALL include the versioned device cases and tolerances approved under TBD-VAL-DEVICE for motors, transmissions, batteries, power balance, saturation, and latency.
Sensor benchmark suite
The Validation System SHALL include the versioned sensor cases and tolerances approved under TBD-VAL-SENSOR for timing, frames, bias, drift, noise, quantization, saturation, latency, and dropout.
Weather benchmark suite
The Validation System SHALL include the versioned cases and tolerances approved under TBD-VAL-WEATHER for fields, wind load, wet friction, and the reference range-sensor weather effect.
Timestep convergence
Each released mechanics profile SHALL satisfy the observable, timestep range, procedure, and convergence criteria approved under TBD-VAL-CONVERGENCE.
General solver-parameter sensitivity
Each released engineering solver profile beyond the MVP reference configurations covered by ACCEPT-009 SHALL document sensitivity to relevant tolerance and iteration settings.
Mesh convergence
Mesh-based structural, fluid, or field models SHALL include documented spatial convergence evidence before being marked validated.
Cross-backend comparison
Equivalent scenarios SHALL be runnable across compatible backends and compared by named observables and tolerances.
Cross-backend is not truth
User-facing reports SHALL state that agreement between simulators is not physical validation.
Calibration dataset
A calibrated model SHALL identify the immutable observations used for parameter fitting.
Independent evaluation dataset
A model claimed as physically validated or compared with independent reference data SHALL identify, with provenance, the evaluation observations or reference cases not used during calibration, tuning, or acceptance-rule selection.
Calibration-evaluation separation
When the reference workflow uses calibration and evaluation datasets, it SHALL prevent designated evaluation observations from contributing to fitting, tuning, or acceptance-rule selection unless the dataset designation is explicitly revised before that use.
Uncertainty propagation
A validation report SHALL account for declared parameter and measurement uncertainty when comparing predicted and observed quantities.
Confidence reporting
Stochastic result summaries SHALL state sample count, interval method, confidence or credibility level, and failed-sample handling.
Validity-envelope enforcement
A run outside a model's declared validity envelope SHALL emit a named warning or compilation error according to policy.
Validation provenance
A validation or independent-reference result SHALL record model revision, software revision, settings, compute hardware where applicable, evidence-source identity, publisher or owner, dataset revision, license or access terms, procedure, and author.
Validation regression gate
A change that moves a committed benchmark outside its approved envelope SHALL block release unless the envelope and rationale are versioned.
Independent decision-ranking validation
A release claiming externally validated design ranking SHALL test whether BeforeMetal ranks selected alternatives consistently with a versioned independent comparative dataset that was not used to select, tune, or threshold the ranking rule.
Reference evidence sources
For every MVP qualification claim, the product definition SHALL identify an applicable versioned analytical, published, manufacturer, community, or independently collected evidence source and its provenance or explicitly declare the affected capability unqualified.
Invalid numeric state
A run SHALL detect and terminate with diagnostics on required NaN, infinity, non-physical mass state, or unrecoverable solver failure.
Energy and constraint budget
A mechanics validation report SHOULD include documented energy drift, constraint error, penetration, and impulse or force budgets where meaningful.
Community model status
Community-contributed models SHALL display their evidence status and SHALL not inherit built-in validation claims automatically.
External solver evidence
An external solver adapter SHALL expose enough identity and configuration data to associate its results with applicable vendor or BeforeMetal validation evidence.
Fidelity comparison
A user SHALL be able to compare Preview, Engineering, Validation, or extension-defined fidelity configurations without assuming their results are interchangeable.
Fidelity conformance status
A run that overrides a selected profile's minimum qualification, convergence, uncertainty, or validity policy SHALL be marked nonconforming and SHALL not be presented as satisfying that profile.
Evidence source classification
Every qualification or validation reference SHALL record both the claim class it can support and its evidence source class: analytical derivation, standard benchmark, published experiment, manufacturer or vendor source, community dataset, independent reference result, cross-solver comparison, or project-specific measurement.
Declarative simulation regression case
A user-authored simulation regression case SHALL reference an experiment revision, execution mode, seed or declared seed-and-repetition plan, optional runtime-action plan, stop conditions, and declarative assertions over termination, diagnostics, events, metrics, committed state, or traces with explicit units, frames, comparators, tolerances, time windows, and statistical criteria where applicable.
Headless regression-suite execution
BeforeMetal SHALL execute a finite user-authored regression suite without a UI, create a fresh world instance for each case, use stable case selection and ordering, fail the suite when any required case fails or remains incomplete, and emit a machine-readable suite summary.
Regression baseline versioning
Every expected regression baseline SHALL have a content identity, and changing an accepted baseline SHALL create a new version with explicit approval and rationale while preserving prior results and evidence.
Dynamic-analysis qualification
Every released General Robotics Beta dynamic-analysis profile SHALL pass the analytical or reference cases and criteria approved under TBD-VAL-DYNAMIC-ANALYSIS for generalized mass, bias, gravity, force mapping, inverse-dynamics consistency, derivatives, local linear prediction, and practical-identifiability diagnostics.
§19Editor and Viewer25
Optional UI
The Editor and Viewer SHALL be optional for headless execution and SHALL not own authoritative simulation state.
Project browser
The UI SHALL display projects, robots, worlds, experiments, runs, and referenced assets in a navigable hierarchy.
Three-dimensional viewport
The UI SHALL display visual geometry, transforms, cameras, and robot motion for the reference projects.
Entity selection
A user SHALL be able to select a visible or hierarchical entity and inspect its canonical identity and properties.
Unit-aware property display
Every displayed physical numeric property SHALL show its unit and preserve canonical meaning during display-unit conversion.
Simulation controls
The UI SHALL provide run, pause, single-step, reset, stop, and playback controls with current virtual time and execution mode.
Time and performance display
The UI SHALL display virtual time, wall time, real-time factor, frame rate, and selected subsystem timings.
Debug geometry
The UI SHALL visualize selected collision shapes, contact points and normals, joint frames, centers of mass, inertia orientation, sensor frames, and force vectors.
Diagnostic panel
Compile and runtime diagnostics SHALL be filterable by severity and SHALL navigate to the responsible object where possible.
Telemetry plot
The UI SHALL plot selected scalar time-series channels with units and aligned virtual time.
Run comparison view
The UI SHALL compare selected metrics and time-series data from at least two runs.
Fidelity card view
The UI SHALL display the pre-run fidelity preview and completed-run fidelity card.
Conversion report view
The UI SHALL display import and export losses grouped by source asset and severity.
Environment visualization
The UI SHALL visualize selected wind, precipitation, visibility, wetness, temperature, and terrain-material fields without affecting simulation state.
Interactive transform editing
A user SHALL be able to edit permitted transforms with snapping, numeric input, frames, units, and validation.
Experiment editor
A user SHALL be able to edit parameter sweeps, distributions, seeds, stop conditions, metrics, and execution settings graphically.
Device connection view
The UI SHALL visualize and validate power, signal, controller, and physical device-port connections.
Undo and redo
Authoring changes SHALL support bounded undo and redo without changing completed run artifacts.
Read-only live inspection
A user SHALL be able to inspect selected committed state while running without mutating the simulation.
Playback separation
Recorded-State Playback SHALL not require, invoke, or advance any simulation solver or backend.
User-selectable unit conversion
A user SHALL be able to convert a displayed physical quantity among documented dimensionally compatible SI and non-SI engineering units without changing its canonical SI meaning.
Robot bring-up workbench
The UI SHALL combine the canonical hierarchy, readiness report, conversion diagnostics, frames, inertial properties, joint limits and drives, collision geometry, device connections, and sensor fields of view into a navigable robot bring-up view.
Synthetic-data authoring and preview
The UI SHALL let a user configure labels and capture products and preview aligned sensor output and ground-truth annotations without changing authoritative simulation state.
Motion-planning inspection
The UI SHALL display a planning request's start and goal states, constraints, collision environment, returned candidate trajectories, feasibility status, and diagnostics before the user selects a trajectory for execution.
Frame-history inspector
A user SHALL be able to query and display the transform chain, source identities, authority, and update times between two supported frames at a selected virtual time.
§20Integration Gateway39
Optional integration boundary
Disabling every Integration Gateway adapter SHALL leave the complete portable MVP workflow functional.
No foreign types in core
External library types, allocators, exceptions, and ownership rules SHALL not appear in public Model Registry or Simulation Kernel interfaces.
Protocol version handshake
Every process adapter SHALL negotiate protocol version, capabilities, limits, and compatibility before a run.
Process health
The gateway SHALL detect adapter exit, timeout, malformed output, version mismatch, and declared resource exhaustion.
Adapter failure isolation
A failed external adapter SHALL not corrupt the portable host process or completed run artifacts.
Bulk-data path
Local image, point-cloud, and tensor transfer SHOULD support bounded-copy shared memory or an equivalent bulk-data mechanism.
Backpressure
Streaming adapters SHALL declare and enforce queue, drop, block, or fault policy under backpressure.
External time contract
Every time-participating adapter SHALL declare time ownership, step policy, accepted rates, latency, direct feedthrough, event, checkpoint, and rollback capabilities.
ROS 2 clock
A ROS 2 adapter SHALL publish committed simulation time and SHALL not make ROS wall time authoritative over deterministic simulation time.
ROS 2 messages
A ROS 2 adapter SHALL map supported state, command, transform, sensor, and diagnostic ports to documented standard or namespaced messages.
ROS 2 QoS
Every ROS 2 endpoint SHALL provide a documented default QoS profile and permit supported overrides.
ROS 2 simulation management
A ROS 2 adapter SHOULD implement applicable standard simulation feature discovery, state, reset, step, spawn, delete, and query interfaces.
ros2_control bridge
BeforeMetal MAY expose supported device ports as a simulated ros2_control hardware system.
ROS 2 process isolation
The default ROS 2 integration SHALL be replaceable or removable without modifying the Simulation Kernel.
FMI Co-Simulation
An FMI adapter SHALL support a documented FMI 3 Co-Simulation subset and SHALL expose unsupported features before execution.
FMI state capability
An imported FMU SHALL declare whether get/set state, early return, events, intermediate update, and directional derivatives are supported.
FMI Scheduled Execution
BeforeMetal MAY support FMI Scheduled Execution for externally scheduled control and firmware partitions.
FMI Model Exchange
BeforeMetal MAY support FMI Model Exchange only after qualifying a compatible ODE/DAE integration layer.
HIL wall-clock profile
HIL SHALL run in a separately selected wall-clock-paced execution profile with deadline and clock-offset metrics.
HIL actuator interception
Physical-output integrations SHALL default to intercepting or disabling actuator energy commands until explicitly armed.
HIL safety interlock
A physical-output integration SHALL require configured limits, watchdog, disarm behavior, and emergency-stop path.
Firmware emulator adapter
BeforeMetal SHALL permit virtual MCU or computer emulators to exchange timestamped bus, peripheral, sensor, and command data.
External mechanics adapter
An external mechanics adapter SHALL map compiled entities and state without becoming the canonical project store.
External result provenance
Every external adapter SHALL contribute binary or service identity, configuration, platform, and license metadata to the run manifest.
Explicit adapter activation
Every external adapter SHALL remain inactive until explicitly selected by a trusted workspace or run configuration.
Supervised FMU host
A binary FMU SHALL execute only in a supervised sidecar process and SHALL never load into the core simulator process.
Safe FMU extraction
The FMI adapter SHALL extract an FMU archive into a private isolated location while enforcing path, link, entry-count, and expanded-size limits.
FMU identity and platform
Before execution, the FMI adapter SHALL hash the FMU, validate its model description, and select only a binary matching a supported host platform.
FMU execution permissions
First execution of an untrusted FMU SHALL require approval, use network-off default, and receive explicit filesystem and resource grants.
Protocol input bounds
Every process adapter SHALL negotiate and enforce message, collection, nesting, queue, and shared-memory capacity limits before accepting run data.
Shared-memory session binding
A shared-memory region SHALL be bound to one negotiated adapter session, identity, size, access mode, and lifetime before either peer accesses its payload.
ROS 2 graph and QoS inspection
A ROS 2 adapter SHALL expose participating nodes, topics, services, actions, publishers, subscribers, types, namespaces, and effective QoS and SHALL diagnose incompatible endpoints before or during a run.
ROS 2 launch and lifecycle supervision
A ROS 2 integration SHALL be able to supervise declared launch, lifecycle, restart, shutdown, and failure behavior in isolated processes while recording package, executable, content, arguments, environment, process, and lifecycle identities.
ROS 2 configuration journal
ROS 2 parameters, remappings, namespaces, QoS overrides, and permitted runtime changes that can affect a run SHALL be captured in its manifest or causal journal with source and virtual-time context.
ROS bag import
A ROS 2 adapter SHALL import a documented rosbag2 or MCAP subset for replay, controller regression, or evidence comparison while preserving type, schema, QoS, source timestamps, receive ordering, provenance, and bounded-input diagnostics.
ROS 2 frame diagnostics
A ROS 2 adapter SHALL map supported transform data to canonical frame identities and diagnose missing parents, conflicting authorities, cycles, stale transforms, and extrapolation outside available history.
ROS 2 trace correlation
Supported ROS 2 messages, callbacks, controller activations, and simulation events SHALL carry or permit reconstruction of correlation identities and capture, delivery, decision, and application timing in the run trace.
ROS 2 rover conformance fixture
The ROS 2 integration SHALL pass a versioned reference rover fixture covering clock, transforms, odometry, commands, range data, diagnostics, simulation management, and supported ros2_control behavior.
ROS 2 manipulator conformance fixture
The ROS 2 integration SHALL pass a versioned reference manipulator fixture covering joint state, transforms, planning-scene synchronization, trajectory commands, diagnostics, and supported MoveIt-compatible behavior.
§21Extension Host14
Built-in Rust extension
BeforeMetal SHALL provide versioned Rust traits for first-party hot-path extension points compiled as part of a portable product build.
No unstable Rust dylib contract
BeforeMetal SHALL not use the native Rust ABI as the long-lived third-party dynamic-plugin contract.
Extension manifest
Every third-party extension SHALL declare identity, version, API range, type, capabilities, dependencies, permissions, determinism, thread safety, resource expectations, and snapshot support.
Lifecycle contract
An extension SHALL use a documented describe, configure, initialize, activate, step or callback, reset, snapshot where declared, restore where declared, and shutdown lifecycle.
Capability-scoped access
An extension SHALL receive only the world state and services authorized by its declared capability.
Wasm component extension
BeforeMetal SHALL support a sandboxed Wasm profile for suitable controllers, metrics, importers, sensors, and environment models.
Process extension
BeforeMetal SHALL support an isolated process-extension profile for polyglot, proprietary, or crash-prone integrations.
External native extension isolation
A third-party extension containing non-Rust native code SHALL execute outside the core simulator process and SHALL not be required by the portable distribution.
Error containment
Extension errors SHALL be converted into structured diagnostics and SHALL not unwind or throw across the host boundary.
Resource limits
Sandboxed and process extensions SHALL support configured memory, CPU, time, output, filesystem, network, and device limits where enforceable.
Determinism declaration
An extension SHALL declare its determinism class and sources of nondeterminism.
Extension conformance suite
A public extension type SHALL ship with an executable conformance suite and reference example.
Extension upgrade compatibility
Incompatible extension API versions SHALL fail during discovery with an actionable diagnostic.
Asset-embedded extension safety
A plugin reference contained in an imported asset SHALL remain inert until explicitly trusted and mapped to an installed extension.
§22Performance and Scalability14
Reference benchmark definition
BeforeMetal SHALL publish the exact reference scene, mission, machine configuration, software configuration, and measurement procedure used for performance claims.
Interactive real-time factor
The portable product SHALL meet TBD-PERF-RTF for the reference rover with the MVP sensor set.
Headless throughput
The portable product SHALL meet TBD-PERF-HEADLESS simulated seconds or control steps per wall second for the reference workload.
Startup time
The portable product SHALL meet TBD-PERF-START from process launch to compiled reference scenario readiness on reference hardware.
Reference memory
The portable product SHALL remain within TBD-PERF-MEM peak resident memory for the reference scenario.
Telemetry overhead
Default metrics and tracing SHALL remain within TBD-PERF-TRACE overhead relative to an equivalent unrecorded run.
CPU-only headless
The reference headless workload SHALL run without initializing a graphics device.
Rendering decoupling
Reducing, disabling, or increasing viewer frame rate SHALL not change committed non-render sensor and mechanics results under deterministic mode.
Independent-world scaling
Batched independent worlds SHALL meet TBD-PERF-SCALE efficiency across the approved core-count range.
Memory per environment
A batched workload SHALL report and meet TBD-PERF-ENV-MEM incremental memory per equivalent environment.
Bulk sensor bandwidth
The supported image and point-cloud workload SHALL meet TBD-PERF-SENSOR throughput without unbounded queue growth.
Profiling visibility
BeforeMetal SHALL report wall time by kernel, mechanics, environment, devices, sensors, controller, rendering, and data output.
Performance regression gate
A committed benchmark regression beyond TBD-PERF-REGRESSION SHALL require explicit recorded approval.
Determinism-performance separation
Performance documentation SHALL not imply that strict reproducibility and maximum-throughput modes have identical cost or guarantees.
§23Reliability and Recovery12
Structured failure
Every anticipated compile, load, run, save, controller, and backend failure SHALL produce a structured error and preserve prior valid project state.
No false completion
A failed, cancelled, or interrupted run SHALL never be marked complete.
Endurance
The reference scenario SHALL complete TBD-REL-ENDURANCE without crash, invalid state, or unbounded memory growth.
Repeatable reset
Repeated reset and rerun cycles SHALL satisfy the selected reproducibility criterion without cumulative state leakage.
Corrupt-input handling
Corrupt, truncated, oversized, cyclic, or unsupported project and asset inputs SHALL fail with bounded resource use and actionable diagnostics.
Save interruption recovery
An interrupted save SHALL leave either the previous valid project or the new valid project recoverable.
Cache invalidation
A compiled or asset cache SHALL not be reused when an identity-bearing input, version, capability, or option changes.
Checkpoint compatibility
A checkpoint SHALL declare its compatible software, schema, and backend versions and SHALL fail safely when incompatible.
Adapter restart policy
A process adapter SHALL declare whether restart and state recovery are supported; BeforeMetal SHALL not assume transparent recovery.
Resource exhaustion
Resource exhaustion SHALL terminate or degrade work according to a named policy without corrupting completed artifacts.
Warning escalation
An experiment SHALL be able to treat selected warning codes as compile or run errors.
Issue reproduction report
BeforeMetal SHALL create a redacted diagnostic report containing versions, manifest identity, logs, warnings, and reproduction instructions.
§24Security and Safety20
No implicit network access
The portable product SHALL make no outbound network connection unless the user enables a networked capability.
Untrusted asset parsing
Asset parsers SHALL enforce configured limits for size, nesting, references, decompression, geometry counts, and processing time.
Path traversal protection
Project, archive, cache, and importer paths SHALL not escape authorized roots through traversal, links, or crafted archive entries.
No asset code execution
Data import SHALL not execute asset-provided code, plugins, macros, or commands by default.
Secret redaction
Logs, manifests, reproduction bundles, and diagnostics SHALL redact configured secrets and credentials.
Dependency inventory
Every release SHALL publish or embed a software bill of materials with versions and licenses.
Vulnerability policy
Release candidates SHALL pass the approved dependency vulnerability policy with documented exceptions.
Unsafe-code policy
First-party core crates SHALL forbid unsafe Rust unless an exception is isolated, documented, reviewed, and tested.
External permission manifest
Every external extension SHALL declare requested filesystem, network, process, environment, shared-memory, GPU, and physical-device access.
Sandbox default
Untrusted extensions SHALL run in a Wasm sandbox or restricted process rather than in the host address space.
HIL safe default
HIL integrations SHALL default to disarmed physical outputs and SHALL require explicit user action to arm.
Physical limits
HIL output SHALL enforce configured command, rate, energy, temperature, and communication-watchdog limits where applicable.
Signed releases
Official release artifacts and official extension packages SHALL be cryptographically signed.
Network authentication
A remotely accessible gateway SHALL authenticate peers and protect message integrity using an approved configuration.
External executable policy
Extensions, adapters, FMU hosts, controller processes, firmware emulators, and external solvers SHALL be governed by one default-deny executable policy.
Explicit permission grants
An external executable SHALL receive only permissions explicitly granted by the user or administrator, and grants SHALL be stored outside project-controlled data.
Permission expansion approval
Installing or upgrading an external executable SHALL require renewed approval before any filesystem, network, process, environment, shared-memory, GPU, or device permission expands.
Sandbox fail-closed
An untrusted external executable requiring unavailable sandbox enforcement SHALL remain inactive unless the user makes a separately recorded trust decision permitted by policy.
Hostile protocol inputs
Every external message, shared-memory descriptor, archive, and handle SHALL be treated as untrusted and validated against negotiated type, size, count, depth, lifetime, ownership, and capacity limits.
No remote listener by default
The portable product SHALL not open a non-loopback listening socket unless the user explicitly enables a remote capability.
§25Rust, Portability, and Deployment12
Rust-only default dependency graph
The default-enabled dependency graph SHALL compile the portable product without compiling, linking, loading, or bundling third-party native simulation code.
Native-adapter isolation
Optional native engineering dependencies SHALL be confined to clearly named, separately packaged adapter executables and disabled by default.
Supported platform matrix
BeforeMetal SHALL publish and test the operating-system and architecture matrix identified by TBD-PORT-MATRIX.
CPU baseline
Every non-render MVP capability SHALL run on a supported CPU-only system.
Optional GPU
GPU acceleration SHALL be optional for the reference headless workflow.
Portable project paths
Persisted project references SHALL support project-relative or content-addressed paths and SHALL not require creator-machine absolute paths.
Offline examples
Bundled MVP examples SHALL run after installation without network access.
Determinism declaration by platform
BeforeMetal SHALL state whether a run guarantee is same-build, same-platform, cross-platform, or statistical.
Feature manifest
A build SHALL expose enabled compile-time and runtime capabilities in diagnostics and run manifests.
Reproducible dependency resolution
Release builds SHALL use committed dependency locks and pinned external adapter identities.
Reduced WebAssembly profile
BeforeMetal MAY support a documented reduced-capability browser or Wasm profile after native gates are met.
External tool discoverability
Missing optional tools SHALL be reported with installation and compatibility guidance without preventing unrelated portable workflows.
§26Public API, Diagnostics, and Versioning14
Native Rust API
BeforeMetal SHALL expose documented Rust APIs for project loading, compilation, execution, state queries, experiments, and results required by the reference workflow.
CLI coverage
Every MVP workflow SHALL be executable through a documented non-interactive command or configuration.
Stable identifiers
Public diagnostic codes, capability identifiers, metric identifiers, and persisted schema fields SHALL use stable names within their compatibility window.
Semantic versioning policy
Public crates, schemas, protocols, and extension APIs SHALL follow a documented versioning and compatibility policy.
Schema migration diagnostics
A migration SHALL report source version, target version, transformations, losses, warnings, and backup location.
Structured diagnostics
A diagnostic SHALL include stable code, severity, subsystem, message, responsible object or source location, context, and corrective guidance where known.
Machine-readable output
CLI diagnostics, compile reports, fidelity cards, and run summaries SHALL be available in a documented machine-readable form.
Structured logging
Logs SHALL include wall timestamp, virtual timestamp where applicable, severity, subsystem, run, world, entity, and message fields.
Metrics namespace
Built-in and extension metrics SHALL use versioned namespaced identifiers and declared units.
Read-only state query
Tools and metrics SHALL query committed state through read-only interfaces that do not depend on renderer state.
Deprecation policy
A supported public API or schema removal SHALL follow TBD-API-DEPRECATION and include migration guidance.
Capability discovery
APIs and adapters SHALL expose actual supported capabilities rather than requiring clients to infer them from version numbers.
Runtime-action request and receipt
Public APIs SHALL expose a versioned runtime-action request-and-receipt contract containing stable request identity, action type and version, origin and authorization context, world instance and target identities, requested virtual time or trigger, typed unit- and frame-aware payload, late, invalid, and failure policy, and accepted, rejected, applied, or failed disposition with structured diagnostics; the contract SHALL contain no backend-native handle.
Simulation regression CLI
BeforeMetal SHALL expose a non-interactive command for selecting and executing user-authored simulation regression cases, emitting the machine-readable regression result and distinct nonzero process statuses for assertion failure, execution error, and invalid configuration.
§27Engineering Process13
Architecture decisions
Major irreversible or cross-cutting design decisions SHALL be recorded in versioned architecture decision records.
Requirement traceability
Each committed MVP feature SHALL reference one or more requirement IDs and associated verification evidence.
Continuous integration
Main-branch changes SHALL pass formatting, linting, unit, integration, numerical, import, security, and applicable benchmark gates.
Platform CI
The supported platform matrix SHALL be exercised at the frequency documented by the release policy.
Dependency review
New mandatory dependencies SHALL document purpose, license, maintenance status, native-code use, safety implications, and replacement strategy.
Native system-interface exception
Linking a non-Rust operating-system or device-driver interface into a portable binary SHALL require an architecture decision naming the platform need, API boundary, safety review, owner, tests, and replacement analysis; project-supplied code SHALL never qualify for this exception.
Fuzzed portable inputs
Project, archive, URDF, SDFormat, and committed mesh parsers SHALL have continuous fuzzing or equivalent adversarial-input evidence before release.
Benchmark fixtures
Numerical and performance benchmark inputs and expected criteria SHALL be versioned with the source.
Migration fixtures
Every supported project-schema migration SHALL have an automated fixture covering success and expected diagnostics.
Release manifest
Every release SHALL publish checksums, compatibility matrix, dependency inventory, known limitations, and validation changes.
Upstream-first fixes
A required third-party fix SHOULD be contributed upstream before BeforeMetal adopts a long-lived fork.
Temporary fork policy
A temporary fork SHALL have a named owner, blocking rationale, benchmark coverage, rebase plan, upstream status, and exit criterion.
Fuzzed protocol boundaries
Process protocols, shared-memory descriptors, extension inputs, and remote request parsers SHALL have bounded-input tests and continuous fuzzing or equivalent adversarial evidence.
§28Documentation14
Installation guide
Documentation SHALL cover installation and removal for every supported portable platform.
Quickstart
A new user SHALL be able to run, inspect, modify, sweep, compare, export, input-re-execute, and play back the reference rover experiment by following one guide.
Model semantics
Every built-in physics, environment, material, device, and sensor model SHALL document equations or algorithm, parameters, units, assumptions, limitations, and validity envelope.
Capability matrix
Documentation SHALL list supported, approximated, unsupported, backend-specific, and future capabilities.
Format coverage
Every importer and exporter SHALL document supported elements, versions, conversions, extensions, and known losses.
Determinism guide
Documentation SHALL distinguish input re-execution, checkpoint resume, and recorded-state playback and explain how settings, platform, parallelism, and adapters affect each guarantee.
Solver evidence-status report
Each released built-in solver profile SHALL link to current verification and evidence-status reports that include applicable validation references or an explicit unqualified status.
API reference
Public Rust APIs, CLI commands, schemas, diagnostics, metrics, and configuration fields SHALL have reference documentation.
Controller guide
Documentation SHALL include a complete native Rust controller example with timing, state, errors, and reproducibility behavior.
ML evaluation guide
Documentation SHALL include domain randomization, batched evaluation, seeding, termination, and result interpretation.
ROS 2 guide
Documentation SHALL include adapter installation, version compatibility, clock, QoS, frames, controllers, and limitations.
Extension SDK guide
Documentation SHALL include one complete Wasm or process extension, conformance execution, packaging, permissions, and compatibility handling.
Known limitations
Release documentation SHALL state known physical, numerical, platform, import, performance, and security limitations.
Glossary
Documentation SHALL define every canonical term used by project files, reports, UI, and public APIs.
§29Explicit Non-goals21
NOGOAL-001Non-goal
Perfect reality
BeforeMetal will not claim exact, universal, or context-free physical truth.
NOGOAL-002Non-goal
Simulation is not universal physical proof
BeforeMetal will not claim that simulation alone replaces physical evidence when a use case, safety case, certification program, regulatory process, or separately qualified accuracy claim requires it.
NOGOAL-003Non-goal
Certification authority
BeforeMetal will not be represented as safety or regulatory certification evidence without a separate qualification program.
NOGOAL-004Non-goal
Full CAD replacement
BeforeMetal will not provide general solid modeling, drafting, tolerancing, manufacturing drawings, or CAM.
NOGOAL-005Non-goal
Full EDA replacement
BeforeMetal will not provide complete schematic capture, PCB layout, signal-integrity, or manufacturing tooling.
NOGOAL-006Non-goal
Native CFD
BeforeMetal will not build a general production CFD solver into the portable product.
NOGOAL-007Non-goal
Native nonlinear FEA
BeforeMetal will not build a general production nonlinear FEA solver into the portable product.
NOGOAL-008Non-goal
Native production SPICE
BeforeMetal will not require a production-compatible transistor-level SPICE solver in the portable product.
NOGOAL-009Non-goal
Individual rain droplets
MVP and beta rain will not require droplet-resolved impact, film, splash, drainage, or fluid-structure simulation.
NOGOAL-010Non-goal
Photorealism gate
Photorealistic rendering will not be an MVP or beta acceptance condition.
NOGOAL-011Non-goal
ML training framework
BeforeMetal will not replace PyTorch, JAX, distributed trainers, or experiment-tracking platforms.
NOGOAL-012Non-goal
Universal backend parity
BeforeMetal will not promise identical trajectories or capabilities across distinct mechanics or multiphysics backends.
NOGOAL-013Non-goal
Universal bitwise determinism
BeforeMetal SHALL guarantee bit-for-bit repeatability only for explicitly qualified configurations. It will not claim identical binary results across every platform, GPU path, extension, or external solver.
NOGOAL-014Non-goal
Hard real-time desktop
A normal desktop process will not be described as a qualified hard-real-time HIL system.
NOGOAL-015Non-goal
Multi-tenant cloud platform
Hosted accounts, billing, multi-tenant isolation, and global distributed orchestration are outside MVP and beta.
NOGOAL-016Non-goal
Unqualified component truth
Community, manufacturer, or assumed models will not be presented as physically validated or independently evidence-qualified without applicable traceable evidence.
NOGOAL-017Non-goal
Extension is not implementation
A generic backend, adapter, or extension point will not be described as support for a physical capability until an implementation and its evidence exist.
NOGOAL-018Non-goal
Universal model catalog
BeforeMetal will not claim to ship validated models for every robot, component, material, circuit, or environment; project-specific modeling, evidence selection, or calibration may remain necessary for a claimed use case.
NOGOAL-019Non-goal
Property storage is not simulation
BeforeMetal will not claim that a constitutive, transport, resistive, dissipative, interfacial, or other engineering property affects a run merely because the property is stored; active support requires a consuming model or solver capability and an explicit compiled disposition.
NOGOAL-020Non-goal
Universal multiphysics completeness
BeforeMetal will not claim that one model, solver, backend, or release resolves every relevant physical domain, scale, coupling, or failure mechanism at production fidelity.
NOGOAL-021Non-goal
Universal arbitrary precision
The portable product will not require arbitrary-precision arithmetic for every physical value; higher-precision, interval, decimal, or other specialist numeric profiles remain explicit versioned capabilities unless a later qualified product profile adopts them.
§30Portable MVP and Acceptance Gates27
Reference benchmark approved
The product definition SHALL name the distributable rover model, mission, environment, design variables, observables, success criteria, evidence-qualification procedure, and policy for disclosing unavailable independent evidence.
Pure-Rust installation
A clean supported machine SHALL install and execute the complete reference workflow without mandatory non-Rust native solver libraries.
Import-to-result workflow
A clean installation SHALL import the reference robot and world, compile, run, inspect, export, input-re-execute, and play back a result.
Design comparison workflow
A user SHALL compare at least two modeled hardware configurations using identical mission, seeds, metrics, and fidelity settings.
Controller comparison workflow
A user SHALL compare at least two native Rust controller configurations using identical robot and environment conditions.
Weather workflow
The reference experiment SHALL compare at least dry, wet, calm, and gust conditions using documented approximations.
Fault workflow
The reference experiment SHALL exercise at least one sensor and one actuator or power fault with visible causal diagnostics.
Analytical qualification
All approved MVP analytical, mechanics, device, sensor, timing, and import benchmarks SHALL pass their approved criteria.
Numerical convergence
The reference observables SHALL satisfy their approved timestep and solver-setting convergence criteria.
Reproducibility
The reference deterministic runs SHALL satisfy TBD-REPRO-CRITERION.
Performance
The reference workflows SHALL satisfy all resolved MVP performance budgets.
Endurance
The reference endurance workload SHALL satisfy TBD-REL-ENDURANCE.
Reference evidence status
Every reference capability SHALL publish its applicable evidence source classes or their absence and its qualification status, including an explicit unqualified status when no applicable independent evidence exists.
Independent decision-ranking evidence
A release claiming externally validated design ranking SHALL rank the agreed alternatives consistently with a versioned independent comparative dataset that was not used to select, tune, or threshold the ranking rule.
Actionable limitation report
The completed reference run SHALL identify engineering-property transformations and dispositions, inactive engineering properties, inactive or unsupported effects, material approximations, unavailable evidence, and out-of-envelope conditions in one fidelity card.
Independent quickstart
A user unfamiliar with the codebase SHALL complete the quickstart without direct developer intervention.
Security baseline
The release candidate SHALL have no unaccepted critical or high-severity vulnerability under the approved policy.
Beta extension gate
An external contributor SHALL implement and package one conforming extension without modifying core crates.
Backend-independence gate
A second mechanics implementation or purpose-built conformance backend SHALL compile the shared reference model and pass the contract suite without introducing its native types into canonical project data.
Beta co-simulation gate
The FMI adapter SHALL pass applicable standard reference tests and BeforeMetal multi-rate coupling tests.
MVP decision closure
Every TBD-* value referenced by an MVP requirement SHALL be approved or the dependent requirement SHALL be explicitly reprioritized before MVP implementation is declared complete.
Independent pilot workflow
TBD-PILOT-COUNT independent roboticists or teams SHALL complete the reference design-decision workflow within TBD-PILOT-TIME and TBD-PILOT-HELP, with the selected decision and product limitations recorded.
Physical-asset-independent workflow
A clean supported machine SHALL complete the reference import, compile, run, inspect, export, input-re-execution, playback, sweep, and comparison workflow without a physical robot, measurement hardware, or user-conducted physical test.
Portable runtime-action gate
A clean portable installation SHALL execute a versioned fixture covering accepted and rejected entity-lifecycle, constrained state-override, disturbance or fault, and controller-restart actions and SHALL verify deterministic ordering, atomic failure, request receipts, and causal-journal evidence without an external runtime.
User regression gate
A clean portable installation SHALL execute TBD-BETA-REGRESSION-SUITE headlessly, emit the specified machine-readable summary and process statuses, pass the accepted cases, and detect the versioned intentional divergence.
Dynamic-analysis gate
The portable General Robotics Beta profile SHALL pass the reference cases and criteria approved under TBD-VAL-DYNAMIC-ANALYSIS.
Beta decision closure
Every TBD-* value referenced by a Beta requirement or acceptance gate SHALL be approved or the dependent requirement SHALL be explicitly reprioritized before General Robotics Beta is declared complete.
§31Open Decisions and Metrics38
TBD-REFERENCE-ROVEROpen decision
Reference digital rover definition
Select a versioned, redistributable or reproducibly obtainable rover model with documented geometry, mass properties, drivetrain, sensors, controller interfaces, provenance, and license; a physical counterpart is optional.
TBD-REFERENCE-MISSIONOpen decision
Reference digital mission
Select a versioned digital outdoor mission with slope, stopping, turning, payload, dry/wet surface, and wind cases; optional independent datasets may map to a documented subset of conditions.
TBD-REFERENCE-MOTOROpen decision
Reference drivetrain motor family
Select brushed DC or behavioral BLDC using the reference model and available analytical, published, manufacturer, community, or independent evidence before fixing the MVP motor equations.
TBD-DESIGN-VARIABLESOpen decision
Modeled pilot design choices
Gear ratio, motor, battery, payload, wheel or tire parameters, controller gains, and sensor quality.
TBD-OBSERVABLESOpen decision
Required reference observables
Simulation outputs and optional evidence-comparison observables: pose/trajectory, speed, slip onset, stopping distance, stability margin, torque, current, voltage, energy, and temperature where modeled.
TBD-EVIDENCE-CORPUSOpen decision
Reference qualification evidence
Select the mandatory analytical and digital benchmark sources plus any applicable optional standard, published, manufacturer, community, independent-reference, or physical sources; record provenance, licenses or access terms, conditions, supported claim classes, and the explicit absence of unavailable evidence classes.
TBD-PORT-MATRIXOpen decision
Supported MVP systems
Candidate: Linux x86-64 and macOS arm64; Windows x86-64 in beta.
TBD-PERF-HARDWAREOpen decision
Performance reference machine
Name exact CPU, core count, memory, OS, compiler, power profile, and optional GPU.
TBD-PERF-RTFOpen decision
Reference interactive real-time factor
Candidate: at least 1.0x with the MVP sensor set.
TBD-PERF-HEADLESSOpen decision
Reference headless throughput
Define simulated seconds and controller steps per wall second.
TBD-PERF-STARTOpen decision
Startup budget
Candidate: under 3 seconds after warm filesystem cache.
TBD-PERF-MEMOpen decision
Reference memory budget
Candidate: under 2 GiB peak resident memory.
TBD-PERF-TRACEOpen decision
Default telemetry overhead
Candidate: no more than 10%.
TBD-PERF-SCALEOpen decision
Independent-world scaling
Define efficiency at 1, 2, 4, 8, and 16 workers.
TBD-PERF-ENV-MEMOpen decision
Memory per additional world
Measure after model and immutable asset sharing design is known.
TBD-PERF-SENSOROpen decision
Bulk sensor throughput
Define after MVP camera and LiDAR scope is fixed; not an MVP gate if those sensors remain beta.
TBD-PERF-REGRESSIONOpen decision
Automatic performance gate
Candidate: 5% regression in stable benchmark medians.
TBD-PILOT-COUNTOpen decision
Independent pilot participation
Select the number and robot-domain mix of independent roboticists or teams required for Beta acceptance.
TBD-PILOT-TIMEOpen decision
Pilot completion budget
Define the maximum elapsed effort from installation through a documented design comparison.
TBD-PILOT-HELPOpen decision
Pilot assistance budget
Define permitted documentation, support interactions, and developer intervention for an accepted pilot.
TBD-REL-ENDURANCEOpen decision
Endurance workload
Candidate: 10 million kernel steps and repeated reset cycles without invalid state or growth.
TBD-REPRO-CRITERIONOpen decision
Portable reproducibility
Candidate: bitwise on the same release binary and platform; tolerance-based across approved platforms.
TBD-TRAJECTORY-ERROROpen decision
Optional trajectory-evidence criterion
Before any trajectory-accuracy claim, define evidence provenance, conditions, alignment, metric, and envelope; otherwise mark the capability unqualified.
TBD-ELECTRICAL-ERROROpen decision
Optional electrical-evidence criterion
Before any current, voltage, or energy-accuracy claim, define evidence provenance, conditions, measures, and envelopes; otherwise mark the capability unqualified.
TBD-STABILITY-ERROROpen decision
Optional stability-evidence criterion
Before any stability-accuracy claim, define tip-over, slip-onset, and stopping-distance events, evidence, conditions, measures, and envelopes separately; otherwise mark the capability unqualified.
TBD-VAL-ANALYTICALOpen decision
Analytical benchmark criteria
Approve versioned analytic cases, compared observables, tolerances, precision, and pass aggregation before implementation.
TBD-VAL-CONTACTOpen decision
Contact benchmark criteria
Approve versioned restitution, incline, stack, penetration, friction, and repeatability cases with per-observable tolerances.
TBD-VAL-JOINTOpen decision
Joint benchmark criteria
Approve versioned kinematic, limit, drive, drift, and articulated-chain cases with per-observable tolerances.
TBD-VAL-DEVICEOpen decision
Device benchmark criteria
Approve versioned motor, transmission, battery, power, saturation, and latency cases with per-observable tolerances.
TBD-VAL-SENSOROpen decision
Sensor benchmark criteria
Approve deterministic and statistical procedures, sample counts, seeds, and tolerances for each MVP sensor stage.
TBD-VAL-WEATHEROpen decision
Weather benchmark criteria
Approve field, wind-load, wet-friction, and rain-degraded range-sensor cases with per-observable tolerances.
TBD-VAL-CONVERGENCEOpen decision
Convergence criteria
Approve observables, timestep sequence, solver settings, expected order or plateau rule, and pass statistic.
TBD-IMPORT-CORPUSOpen decision
Asset compatibility corpus
Select representative URDF and SDFormat assets and required element coverage.
TBD-SCENE-SCALEOpen decision
Supported MVP scene size
Define bodies, joints, colliders, contacts, sensors, telemetry channels, and trace rate.
TBD-API-DEPRECATIONOpen decision
API and schema deprecation window
Candidate: two minor releases or six months, whichever is longer.
TBD-HIL-SAFETYOpen decision
HIL qualification criteria
Define supported hardware, latency, jitter, watchdog, E-stop, and output-energy limits before implementation.
TBD-BETA-REGRESSION-SUITEOpen decision
General Robotics Beta user-regression fixture
Approve versioned rover and manipulator cases, declarative assertion classes, expected-baseline identities, stochastic seed and repetition policy, pass aggregation, machine-report expectations, and an intentional divergence that the suite must detect.
TBD-VAL-DYNAMIC-ANALYSISOpen decision
Dynamic-analysis qualification criteria
Approve reference mechanisms, coordinate conventions, smooth and constrained regimes, compared mass, force, inverse-dynamics, derivative, linear-prediction, and identifiability quantities, perturbation sequences, tolerances, conditioning thresholds, and pass aggregation.