Space Safety Manual

This manual states the obligations for teams using 0x0 in space-software

assurance work. It does not grant certification or mission approval.

User Obligations

Mission users must:

• select a profile from space/profiles.tsv;
• record the selected target, toolchain, package lockfile, memory profile, and

hardware evidence scope;

• run only bounded gates appropriate to the profile during development;
• run make flight-core-profile-check before making a Flight Core source

profile claim;

• preserve generated evidence bundles and hashes;
• review every review-required Flight Core operation;
• keep test fixtures separate from production evidence;
• obtain physical target evidence before making board claims;
• obtain external approval from the relevant mission or certification

authority.

Forbidden Flight Core Features

Flight Core code must not use hidden allocation, optional GC, implicit host

effects, broad unknown type fallback, unbounded recursion, unbounded dynamic

dispatch, or reflection-like metadata.

The local source gate rejects those cases through

tools/flight-core-profile-check.py and the negative fixtures under

tests/fixtures/flight-core/.

Escape Hatches

The following are allowed only with review evidence:

• MMIO and volatile register access;
• FFI or ABI boundary calls;
• explicit arena allocation;
• manual memory operations;
• CPU-specific operations;
• target-specific interrupt, reset, and BSP hooks.

Each escape hatch needs a review ID, source location, target assumption,

failure mode, test evidence, and reviewer signoff.

Safe State

Applications must define a safe state for invalid commands, timeout, watchdog

failure, unexpected reset, failed packet validation, storage failure, clock

drift, and target-specific fault reports.

Claim Boundary

The repository provides evidence-support tooling. Mission safety is a

project-level result that depends on system design, hazard analysis, physical

evidence, operations, independent review, and external authority approval.