❖ MetaSpace.bio / DOCS
◀ RETURN TO SIMULATOR
MetaSpace.bio: a deterministic integrity layer (simulation)

MetaSpace.bio is a rule-based integrity layer: instead of estimating how likely a sensor reading is, it checks a small set of explicit rules (invariants) on residuals and component health and acts on the result. Every decision can be traced to a rule; the simulation contains no machine learning.

This site runs the idea on a simplified digital twin of Landsat-9 (sunlight and eclipse from a computed orbit, battery, solar wings, star trackers). It is a software simulation at TRL 3-4: there is no hardware, no flight data and no certification.

Reproducible evidence for every claim made here is in the evidence bundle.

What is implemented, and how strong the evidence is
Detector guard: proved against its spec
One function checks five residual channels against thresholds. The Python source was proved with the Z3 SMT solver to match the .bio specification for every float64 input (including NaN): 15 proofs, 8 broken variants rejected. The proof does not say that the thresholds are physically right.
Cost: measured, not guaranteed
One guard evaluation takes about 0.4-0.5 microseconds (median) in CPython on a desktop computer. The tail varies from run to run. This is a software measurement, not a real-time guarantee and not a hardware latency.
Not implemented here
Actuator isolation ("Logic Lock"), FPGA execution, redundant channels with a voter and any flight software are design targets only. Z3 runs offline; no solver runs in the browser or on this server.
Bio-code levels (Neural Sandbox and Navigation Plan)
LVL 01
Node
One 64-bit word per component: id, status and health.

Examples: OLI-2, Star Tracker A, EPS.
LVL 02
Module
One 32-bit word per subsystem group: the mean health of its nodes (a failed node counts as 0), a trend and a risk score.

Modules: payload, power, navigation, communications.
LVL 03
Mission
One 64-bit word: day, feasibility, action and safety margin. The action follows fixed thresholds (nominal, monitoring, reduced imaging, fallback, safe mode, emergency halt).

The module weights and thresholds are modelling assumptions, not mission data.

The runtime checks in the sandbox test this model for internal consistency (bounds, round trips, an independent recomputation of the feasibility). They are not a formal proof.

Invariant checks versus a covariance-based filter

A Kalman filter keeps an estimate and an uncertainty (a covariance). Its confidence falls when measurements stop arriving or get noisy. A rule-based check asks a different question: is this value physically allowed? If not, it acts at once instead of averaging.

The baseline in this simulation is deliberately simple: a linear constant-velocity filter whose confidence comes only from its covariance, without a residual or innovation check, and which sees GPS data only. It therefore does not notice wrong but regular GPS data, a lost solar wing or a dead battery until the GPS stops. A production navigation filter would usually add residual gating, so the comparison shows what invariant checks add to a covariance-only confidence; it is not a benchmark of real filters.

Both controllers are compared on the main page (detection) and on the navigation plan (task decisions judged against the physics model).

# backend/modules/fdir_guard.py (excerpt)
def detect(gps_ins_dist_m, power_residual_w, imu_star_diff_deg, ...):
    if not (abs(gps_ins_dist_m) < GPS_M): fault_code = 1
    elif not (abs(power_residual_w) < PWR_W): fault_code = 2
    elif not (abs(imu_star_diff_deg) < IMU_DEG): fault_code = 3
    ...

> detect(0, 0, 0.6, 0, 0)    # IMU residual 0.6 deg, limit 0.5 deg
> (True, True, 3)  # fault detected, safe mode, code 3 = IMU drift
> detect(0, 0, 0.4, 0, 0)
> (False, False, 0)
What this site does not claim