build v3.1.3 · MIT
PK: ∅
SIM-T00:00:00 RATEx1 FPS60 CHAIN LCOBSERVE τ-USE0%
IDLE
Orbital regimes
LEO400-2000 km
MEO2000-35786 km
GEO35786 km
drag · scroll · pinch
Diagnostics
FPS60.0
FRAME16.6 ms
OBJ0
SIM-RATEx1.0
Select a scenario to begin
Six pre-defined orbital scenarios exercise all five Keplerian Decision Window types plus the Cosmos 1408 retrospective.
Inject faults from the left panel to probe degraded modes.
-
Audit entries - SHA-256 chained from genesis - will appear here as the simulation runs.
Each entry's hash = SHA-256(prev_hash ‖ canonical_json). Genesis: 0×0…0. Tail: UNVERIFIED
Framerate
60.0fps
Frame budget
16.6ms
Active objects
0
Sim rate
x1.0
JS heap (used)
-MB
Audit chain depth
0
Active faults
0
Build
SAP-INT v3 · 3.0.0

Manuscript spec values from scenarios.py are bit-identical to the Python reference implementation. Self-test runs all 6 sequentially.

ScenarioKτSATAp_dec C_effE_orbTierExecvs spec
no scenarios run yet

Runtime invariants checked every 60 frames. A failed invariant indicates a system bug or unmodelled corner case and prevents the audit log from being signed off as verified.

InvariantStatusLast check / details

Decision trace shows the rule lineage that produced the current tier. Causal lineage in the audit ledger now carries upstream entry hashes (causes[]) for every component event.

No scenario executed. Run a scenario to populate the decision trace.

Authority lifecycle: OBSERVE → ADVISE → RECOMMEND → EXECUTE_ALLOWED → GATED → SAFEHOLD → RECOVERY. State transitions are audit-logged with reason codes.

OBSERVE ADVISE RECOMMEND EXECUTE_ALLOWED GATED SAFEHOLD RECOVERY
T+ (s)StateReason
No lifecycle transitions yet.

Fault campaign: power-set of 5 named fault classes (2⁵ = 32 combinations) × 6 scenarios = 192 runs. Tabulates which combinations gate which scenarios. Heatmap-style.

No campaign executed yet. Press ▶ Fault campaign (32×6) in the operations panel.

Architecture

SAP-INT v3 is a single-file browser simulation companion to the SAP manuscript. It executes a faithful port of the validated Python reference implementation, augmented with Keplerian-with-J2-secular orbital propagation (Newton-Raphson Kepler solver), noisy-OR sensor fusion (D-S binary-frame reduction), multi-phase PBFT consensus (pre-prepare/prepare/commit + view-change), mutex-serialised SHA-256 hash-chained audit logging with simulation-tick timestamps, fault injection, fault campaign matrix, Monte-Carlo headless runner, BFT property-based test, soak test, and a self-test regression runner. ADARA is threshold-gated into downstream math (margin +0.10 above scenario policy prior). Authority lifecycle FSM and safehold mode model degraded-state recovery.

Scenario Observation, threat, policy, K-type SATA D-S fusion + radiation env ADARA Multi-sensor consistency MAIVA PBFT consensus n=7, f_max=2 FLAME Fail-safe monitor TT&C / fuel / atit. CARA Covariance + P_collision HMAA Human-machine authority alloc. ERAM Tier selection + gate evaluation Decision T1-T4 | exec | gated audited + logged SHA-256 hash-chained audit ledger every component event is canonicalised and appended; tail hash exposed for off-system verification

Assumptions log

  1. SAP formulas exactly mirror manuscript Section 7.1 and the Python reference in space_authority_protocol.py; numerical agreement verified to 5×10⁻⁴.
  2. Keplerian propagation uses GM⊕ = 398 600.4418 km³/s²; orbits are visualised circular for the demo with mean motion n = √(GM/a³) preserving correct period ratios across LEO/MEO/GEO.
  3. Sensor visualisations are not to scale; bus and panel dimensions are exaggerated for affordance.
  4. Dempster-Shafer fusion uses three independent sensors (radar, EO, RF). Real systems may have more sensors and inter-correlated noise - not modelled.
  5. PBFT MAIVA is a multi-phase, multi-view abstraction: pre-prepare / prepare / commit phases per view, view-number increment up to n attempts on prepare-quorum failure, primary-dependent PREPARE gating (byzantine primary either equivocates or stays silent), contested-network failure modes (latency + drops). Real production PBFT additionally requires signed messages, persistent checkpointing, view-change certificates, and threshold signatures.
  6. Fault injection is binary (active / not active). Real fault modes are stochastic and progressive.
  7. SHA-256 hash-chained audit ledger with per-entry ECDSA P-256 signatures (signed over prev_hash || canonical_json || entry_hash); public-key SPKI exported with the chain so an out-of-process verifier can authenticate origin in addition to integrity. Triple-state in-product pill: HASH ✓ SIG ✓ / HASH ✓ SIG ✗ / HASH ✗. Keypair is session-scoped (regenerated on tab reload); production deployments would back the private key with an HSM (PKCS#11 / TPM) and persist the chain to immutable storage.
  8. ADARA deception probability is treated as a per-scenario input in playback to match the manuscript; free play exposes the slider directly.
  9. Time in the SIM-T clock advances in real wall-clock seconds, not propagated mission time.
  10. No real catalog data (TLE, SP-CAT) is fetched; threat / asset orbits are illustrative.

References

  • Oktenli B. Orbital Authority: Governance Architecture for Autonomous Space Operations. AUTHREX research program, 2026.
  • Castro M., Liskov B. Practical Byzantine Fault Tolerance. OSDI 1999.
  • Dempster A. P. A Generalization of Bayesian Inference. J. R. Statist. Soc. B, 1968.
  • Shafer G. A Mathematical Theory of Evidence. Princeton, 1976.
  • UN GA Resolution 76/231, Reducing space threats through norms, rules and principles of responsible behaviours, December 2021.
  • Public software-engineering assurance-level standards (referenced for level mapping; this simulation is research-grade, not flight software).

Engineering safeguards

  • SHA-256 chained audit ledger - tamper-evident within the session.
  • Live invariant assertions - chain integrity, math agreement, BFT bound preservation.
  • Self-test mode - regression-verifies all 6 scenarios against manuscript spec.
  • Deterministic seeded RNG - every run is reproducible.
  • Fault injection panel - adversarial / degraded modes are first-class.
  • Multi-tab analysis pane - separation of audit / diagnostics / verification / docs.