Space Known Limitations

0x0 has local evidence-generation and assurance-support mechanisms, but these

limitations remain explicit.

Certification

The repository is not certified. It provides evidence-support tooling,

traceability documents, and deterministic bundles. External certification or

mission approval must be supplied by a qualified authority.

Physical Hardware

Emulated hardware evidence is accepted for emulator-backed claims. Physical

board claims require make physical-hardware-evidence-check with real lab

artifacts: firmware image, secure-boot manifest, physical log, monitor trace,

recovery trace, flashing receipt, HIL campaign, operator signoff, and active

root-key custody.

S2 target/BSP claim rows are implemented by

make space-physical-bsp-check. That gate records the first selected physical

board identity and target-specific debug/flash workflows, but it still reports

zero physical claims until real lab evidence is supplied.

Flight Core Enforcement

S1 defines and enforces the local Flight Core source profile with

make flight-core-profile-check. The gate checks the positive source corpus,

negative forbidden-feature fixtures, memory budgets, unsafe operation review

rows, and traceability rows. This is local evidence for the declared profile,

not physical target certification.

Space Protocols

S3 protocol conformance is implemented locally by

make space-protocol-conformance-check. The gate validates CCSDS, CFDP, TM/TC,

FDIR, time-kind, XTCE, fuzz, and crypto review evidence for current package

surfaces. Mission-specific protocol tailoring, ground-system import, key

custody, and external assurance review remain deployment evidence.

Digital Twin

S4 digital twin evidence is implemented locally by

make space-digital-twin-check. The gate validates deterministic snapshots,

recorded telemetry/command replay streams, explicit execution modes, and an

XTCE-compatible standards bridge. Ground-system acceptance, operational shadow

feeds, physical HIL, and long-duration mission validation remain

deployment-specific evidence.

Certification Support Kit

S5 certification support kit evidence is implemented locally by

make space-certification-kit-check. The gate validates evidence-support plan

templates, Flight Core coding-standard rows, tool operational requirements,

trace exports, coverage ingestion, target behavior reports, and a generated

sample space-profile bundle.

This is support evidence only. External certification, mission approval,

mission-specific tool qualification, and physical target acceptance remain

project authority decisions backed by project artifacts.

Mission Validation

S6 mission validation is implemented locally by

make space-mission-validation-check. The gate validates campaign definitions,

deterministic fault-injection seeds, 72-hour hosted/twin telemetry evidence,

negative tests, RTEMS/cFS/OSAL mission-conditional rows, and fail-closed

physical/HIL boundaries.

Local bounded gates are not a substitute for deployment long-duration

validation. Physical board soak and HIL remain physical-gated until physical

hardware evidence intake accepts real lab artifacts.

Mission Operations

S7 mission ecosystem operations are implemented locally by

make space-mission-ops-check. The gate validates LTS, security update,

deprecation, migration, signing key custody, offline release, dependency, and

advisory policies, plus offline bundle evidence, compatibility windows,

training rows, and source-owned SBOM/provenance records.

Mission programs still own their actual branch hosting, key custody operations,

distribution channels, and mission-user advisory publication.