Section 4Product Foundation
System-level requirements
Establishes cross-cutting requirements for the Rust-owned core, portability, fidelity, observability, and capability handling.
Section relationships
Depends on
Used by
- §5User Workflows
- §6Workspace and Canonical Model
- §8Scenario Compiler
- §9Simulation Kernel and Time
- §18Validation and Fidelity
- §21Extension Host
- §24Security and Safety
- §25Rust, Portability, and Deployment
- §26Public API, Diagnostics, and Versioning
- §27Engineering Process
- §28Documentation
- §29Explicit Non-goals
- §30Portable MVP and Acceptance Gates
- §32Required Normative Designs
| ID | Name | Priority | Requirement | Verification |
|---|---|---|---|---|
| SYS-001 | Rust-owned core | MVP | BeforeMetal SHALL implement all first-party core logic in Rust. | Inspection |
| SYS-002 | Portable default product | MVP | 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. | Test |
| SYS-003 | Optional engineering integrations | Beta | BeforeMetal SHALL execute optional non-Rust engineering tools outside the core simulator process through versioned adapters. | Inspection |
| SYS-004 | UI-independent simulation | MVP | 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. | Test |
| SYS-005 | Explicit fidelity | MVP | Every run SHALL identify the physical models, solver settings, approximations, and validation status used. | Inspection |
| SYS-006 | No silent fidelity loss | MVP | BeforeMetal SHALL report and require acknowledgement of any unsupported or approximated model feature that could affect an experiment result. | Test |
| SYS-007 | Solver independence | MVP | Canonical project data SHALL not depend on one mechanics backend's object types, handles, or native file format. | Inspection |
| SYS-008 | Replaceable subsystems | Beta | Mechanics, sensor, device, environment, and external-domain solvers SHALL be replaceable through capability-scoped contracts. | Test |
| SYS-009 | Offline baseline | MVP | The portable product SHALL support creation, execution, input re-execution, recorded-state playback, and inspection of the reference experiment without network access. | Demonstration |
| SYS-010 | Decision-support scope | MVP | User-facing documentation SHALL state that BeforeMetal supports engineering decisions but does not by itself certify safety, compliance, or manufacturability. | Inspection |
| SYS-011 | Baseline observability | MVP | Every run SHALL expose simulated time, wall time, real-time factor, solver diagnostics, warnings, and termination reason. | Test |
| SYS-012 | Graceful capability failure | MVP | A project requiring an unavailable capability SHALL fail during compilation with actionable diagnostics rather than during an arbitrary simulation step. | Test |
| SYS-013 | Canonical terminology | MVP | Public schemas, APIs, diagnostics, documentation, and UI text SHALL use the canonical vocabulary according to the meanings in this document. | Inspection |
| SYS-014 | Pure-Rust default binary closure | MVP | 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. | Inspection |
| SYS-015 | Conditional capability conformance | MVP | 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. | Inspection |
| SYS-016 | Physical-asset independence | MVP | The Portable MVP SHALL be installable, executable, and acceptable without requiring BeforeMetal or the user to own, build, instrument, or physically test a robot. | Demonstration |
| SYS-017 | Capability-scoped property semantics | MVP | 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. | Inspection |
Change rationale (SYS-016, SYS-017): ADR-0001 separates a simulation-first portable workflow from optional empirical evidence and closes the gap between retaining engineering-property data and proving that an active model consumes it. Physical hardware and team-run testing are no longer release prerequisites, while unsupported property semantics remain explicit rather than silently inactive.
Generated from the canonical specification. Edit section metadata or prose in docs/requirements.md; the website rebuilds this page and its relationships automatically.