Space Requirements Trace

The space requirement trace lives in space/requirements-trace.tsv.

Each row records:

• requirement id;
• profile scope;
• requirement text;
• verification method;
• evidence path;
• open gap, when applicable;
• boundary statement.

S0 Requirements

• REQ-S0-001: profile mapping to current runtime, memory, compiler, package,

and hardware evidence.

• REQ-S0-002: claim boundary separation.
• REQ-S0-003: safety manual obligations and Flight Core restrictions.
• REQ-S0-004: standards tailoring matrix without automatic compliance.
• REQ-S0-005: hazard links to source, tests, evidence, runtime profiles, and

known limitations.

S1 Requirements

• REQ-S1-001: Flight Core source has no undefined behavior under declared

profile assumptions.

• REQ-S1-002: the Flight Core gate fails closed on forbidden source forms.
• REQ-S1-003: unsafe or hardware operations carry review obligations.
• REQ-S1-004: Flight Core APIs are represented in stable machine-readable

rows.

• REQ-S1-005: stack, section, and target memory budgets are accepted release

inputs.

S2 Requirements

• REQ-S2-001: physical target claims fail closed without accepted physical

hardware evidence.

• REQ-S2-002: firmware reproducibility is tied to source, target metadata,

linker policy, and release bundle inputs.

• REQ-S2-003: debug and flash workflows record tool version, command, target

identity, firmware hash, and operator signoff requirements.

• REQ-S2-004: interrupt handlers and RTOS/BSP hooks declare calling

convention, stack, blocking, priority, and fault behavior.

S3 Requirements

• REQ-S3-001: telecommand handlers validate input before state mutation.
• REQ-S3-002: protocol parsers for external input have fuzz evidence.
• REQ-S3-003: FDIR actions are deterministic and traceable.
• REQ-S3-004: time APIs distinguish monotonic, mission elapsed, UTC, GPS,

and simulation time when used by mission code.

• REQ-S3-005: XTCE export is generated from the same schemas used by code

and tests.

S4 Requirements

• REQ-S4-001: simulation time is explicit and is not confused with wall-clock

time.

• REQ-S4-002: recorded telemetry replay produces a comparable, hashable state

timeline.

• REQ-S4-003: distributed twin execution distinguishes deterministic mode

from real-time mode.

• REQ-S4-004: standards export/import records version, schema, source hash,

and limitations.

S5 Requirements

• REQ-S5-001: generated support kits say evidence support and avoid

unsupported certified-status claims.

• REQ-S5-002: tool qualification support records intended use, failure

modes, validation data, replayability, and independent review hooks.

• REQ-S5-003: the sample project generates a complete space-profile evidence

bundle from local inputs.

S6 Requirements

• REQ-S6-001: fault-injection runs are reproducible by deterministic seed.
• REQ-S6-002: long-duration hosted/twin tests collect memory, timing, fault,

and health telemetry.

• REQ-S6-003: mission-grade examples include negative tests and failure-mode

tests.

• REQ-S6-004: physical HIL claims remain tied to accepted physical hardware

evidence.

S7 Requirements

• REQ-S7-001: LTS, security update, deprecation, and migration policies exist

for frozen Flight Core profiles.

• REQ-S7-002: signing key custody, rotation, revocation, and recovery

procedures are documented.

• REQ-S7-003: offline release bundles include compiler, docs, package cache,

SBOM, provenance, evidence schemas, runbooks, and no-network build evidence.

• REQ-S7-004: mission dependency policy requires vendored dependencies,

frozen lockfiles, banned build scripts, no network during flight builds, and

reviewed code generation.

• REQ-S7-005: vulnerability disclosure and advisory workflow is documented

for mission users.

Bundle Use

The space-profile bundle includes these documents as hashed profile documents.

The manifest proves exactly which profile documents accompanied the runtime,

mission IO, replay, and hardware-proof evidence.