Deep-Space SI-Core: Autonomy Across Light-Hours - How an onboard SI-Core evolves safely while Earth is hours away

Community Article Published December 29, 2025

Draft v0.1 — Non-normative supplement to SI-Core / SI-NOS / SCP / SIM/SIS

Scenario: A deep-space vessel carries an L3-class SI-Core onboard. Earth runs its own SI-Core on the ground. Round-trip latency is 2–6 hours. Links are intermittent. The ship must govern itself — and still stay governable by Earth.

This note sketches how:

SCP behaves over DTN (Delay/Disruption-Tolerant Networking),
rollback / RML works when you cannot get an answer from Earth in time,
and how a deep-space SI-Core can self-improve without drifting out of spec.

This is all non-normative: it is a storyboard for architecture thinking, not a spec.

1. The deep-space problem in SI-Core terms

Most SI-Core narratives so far assume:

“near-real-time” governance,
always-on links between systems that share a clock,
rollback with human oversight in seconds–minutes.

Deep space breaks all of that:

Latency: 30 minutes–hours one way.
Disruption: blackouts, occultation behind planets, hardware glitches.
Autonomy: the ship must take irreversible decisions (e.g. sacrificially shutting down instruments, dumping fuel) without asking Earth first.
Governance: Earth still needs a coherent audit trail and the ability to steer how the ship learns and self-modifies.

In SI-Core language, the question becomes:

How do you design [OBS][ETH][MEM][ID][EVAL] + RML so that an onboard core is:

locally sovereign (it must act),

globally accountable (Earth can still govern it), and

self-improving without becoming unrecognizable?

2. Two cores, one mission: Earth vs Ship

Think of two SI-Cores:

Earth-Core (EC):
- High compute, high bandwidth to archives.
- Human-in-the-loop governance, policy authorship.
- Offline analysis, simulations, PLB/PLB-M at scale.
Ship-Core (SC):
- L3-class SI-NOS onboard.
- Limited compute, constrained energy.
- Real-time decisions for navigation, health, science, crew.

Between them: a DTN fabric carrying SCP bundles.

Note: Here EC/SC are Earth-Core / Ship-Core abbreviations (unrelated to SCover).

We can roughly partition responsibility:

EC = strategic + constitutional layer
- Defines mission goals, ethics overlays, “constitutional constraints”.
- Reviews long segments of ship history ex post.
- Issues epochs of policies / SIL / GCS estimators.
SC = tactical + operational layer
- Executes jumps, RML, local ethics, scheduling.
- Runs local PLB for parameter-level learning.
- Emits rich [MEM] + SCP logs back to EC.

Key design move:

SC is fully SI-Core-conformant in its own right. EC is another core that:

defines outer bounds of autonomy,

and periodically resynchronizes meaning and law with SC.

2.1 Resource constraints and budgets

A deep-space SI-Core does not live in a datacenter. It runs inside a harsh, power-limited, thermally constrained vehicle.

Non-normative but plausible budgets:

Compute

Ship-Core (SC), onboard:
- Sustained: ~100–500 GFLOPS
- Emergency peak: up to 1–2 TFLOPS (short bursts only)
Earth-Core (EC), ground:
- Effectively unbounded (datacenter-class clusters)

Power

Total spacecraft power: ~2–5 kW (mission-dependent)
Allocated to SC compute: ~200–800 W
Thermal constraints: mostly passive cooling, active cooling is expensive
Power available from solar panels drops with ~1/r² (distance from Sun)

Storage

Onboard non-volatile: ~10–100 TB
Intended retention: ~6–18 months of mission-segment history
Heavy use of SIM/SIS semantic compression to avoid drowning in raw data
Downlink capacity: ~1–100 kbps, strongly distance and geometry-dependent

Memory

Working RAM: ~64–256 GB
SIL / SIR / sirrev caches: ~1–10 GB
Jump log buffer: ~10–50 GB (before rotation/compaction)

These constraints affect how SC is allowed to learn and reason:

PLB-L (local learning) must respect compute and power budgets.
[EVAL] gates resource-intensive actions (e.g. full-fidelity sandbox).
Semantic compression policies trade quality for bandwidth and energy.
Some changes are explicitly disallowed if they would:
- increase average power draw by >5%, or
- increase peak compute usage by >20% for critical subsystems.

In other words: autonomy is always exercised inside an explicit resource budget, not on an infinite cloud.

3. SCP over DTN: semantic bundles, not chats

On Earth, SCP can feel like:

producer → SCP → bus → consumer   (sub-second)

Over DTN, SCP turns into:

Ship-CORE → SCP bundle → DTN store/forward → Earth-CORE  (hours, maybe days)

3.1 DTN-style SCP envelope

A deep-space SCP message is more like a semantic bundle:

{
  "bundle_id": "B-2043-10-05T12:30:00Z-ship-042",
  "from": "ship-core://voyager-next",
  "to": ["earth-core://JPL-SI-HUB"],

  "epoch": {
    "mission": "MISSION-CONST-07",
    "nav": "NAV-POLICY-042",
    "ethics": "ETH-GLOBAL-009"
  },

  "segment_window": {
    "start": "2043-10-05T12:00:00Z",
    "end":   "2043-10-05T13:00:00Z"
  },

  "priority_class": "A",
  "priority": "high",

  "payload": {
    "type": "ship.segment.telemetry/v3",

    "semantic_units_ref": "sim://ship-core/jumps/SEG-2043-10-05T12:00:00Z..12:30:00Z",

    "metrics_spec": "series-aligned",
    "metrics": {
      "cas": 0.996,
      "eai": 0.982,
      "rbl_p95_ms": 320,
      "rir": 0.97,
      "acr": 0.99,
      "eoh": 0.18
    }
  },

  "backing_refs": [
    "sim://ship-core/jumps/SEG-2043-10-05T12:00:00Z..12:30:00Z"
  ],

  "replay_hint": "reconstruct_decisions"
}

DTN nodes:

store bundles until a contact window,
forward them opportunistically,
may also perform local checks (e.g. integrity, minimal policy gates).

SCP over DTN must assume:

no immediate backpressure — you can’t expect Earth to say “stop doing X” in real time,
semantic prioritization — life-support failures > navigation tweaks > science scheduling,
bundle-level idempotency — replays, duplicates, partial reconstructions.

4. Rollback when nobody is listening

RML in deep space has two temporal regimes:

Local RML (ship timescale):
- RML-1/2/3 apply as usual on SC.
- Rollbacks are executed immediately relative to local events.
- Compensators are onboard and must be autonomous.
Global RML (Earth timescale):
- EC can only roll back future behavior, not past physics.
- It can:
  - deprecate epochs of policies,
  - mark segments as defective in [MEM],
  - issue corrective constraints for future jumps.

4.1 Local rollback envelope

On SC, rollback is “normal” SI-Core — but with a deep-space clarification:

A navigation jump drafts an actuator plan and takes a pre-effect snapshot (pre_fx).
If [EVAL] or sanity checks fail before commit, RML-2 aborts/cancels the queued actuation (pre-commit rollback).
If a physical actuation already occurred, SC cannot undo physics; it executes RML-3 compensation and records residual effects explicitly.
All paths attach rollback evidence (what was aborted vs what was compensated) into [MEM] for later EC audit.

Local example:

[2043-10-05T12:07:13.221Z] [JUMP] NAV_ADJUST_042
  rml_level: 2
  planned_delta_v: 0.08 m/s
  phase: PRE_COMMIT
  outcome: FAILED_SANITY_CHECK
  rollback: STARTED

[2043-10-05T12:07:13.945Z] [ROLLBACK] RML2_PRECOMMIT_ABORT
  compensators: ["thruster_abort_precommit", "attitude_restore"]
  status: SUCCESS
  RBL_ms: 724
  RIR_update: 1.0

All of this happens without Earth. It is still fully logged in SC’s [MEM].

4.2 Global rollback: epochs and retroactive governance

EC cannot undo a burn that already happened. But it can:

declare epoch E-17 “unsafe”,
require SC to:
- stop using policies tagged epoch: E-17,
- re-run PLB/PLB-M under new constraints,
- reclassify some historical decisions as “under new understanding: undesirable”.

Mechanism sketch:

Every onboard policy set (SIL + ethics + goal configs) is an epoch:
- MISSION-CONST-07, NAV-POLICY-042, etc.
Every jump carries:
- policy_epoch_id, gcs_model_id, etc.
EC can, after audit:
- broadcast epoch deprecation messages via SCP/DTN.

Example EC directive:

{
  "type": "policy.epoch.deprecation/v1",
  "epoch_id": "NAV-POLICY-042",
  "reason": "post-hoc analysis shows unsafe fuel optimization",
  "actions": [
    { "action": "disable_epoch_for_all_future_jumps" },
    {
      "action": "replay_sandbox_segment",
      "segment": {
        "start": "2043-09-30T00:00:00Z",
        "end":   "2043-10-05T00:00:00Z"
      }
    },
    {
      "action": "report_summary_metrics",
      "metrics": [
        "incidents_avoided_if_PATCH_043_applied"
      ]
    }
  ]
}

SC receives this hours later, but then:

stops using NAV-POLICY-042,
re-runs local sandbox to compare outcomes,
logs both pre- and post-hoc GCS for EC review.

Global rollback is thus:

Rollback not of physics, but of policy trajectories (and of how we interpret past decisions).

5. Self-improvement in a light-hours loop

We want SC to:

fix micro-level patterns quickly,
but not drift away from EC’s macro-level mission and ethics.

So we split learning:

Onboard PLB-L (local):
- can adjust parameters, thresholds, heuristics within a bounded envelope,
- cannot change constitutional constraints,
- must log LearningTrace segments.
Ground PLB-G (global):
- can propose structural changes:
  - new SIL functions,
  - new ethics rules,
  - new GCS estimators.
- sends them as policy epoch updates via SCP/DTN.

5.1 Bounded local learning

Onboard PLB-L is allowed to do things like:

tweak a risk classifier threshold by ±10%,
adjust scheduling priority weights within a narrow range,
refine semantic compression ε-budgets for non-critical channels.

But it must:

never:
- widen constraints on safety goals beyond pre-approved bands,
- bypass [ETH],
- introduce new side-effect types,
always:
- attach a learning_change_id,
- log a small LearningTrace with:
  - before/after parameters,
  - rationale (pattern summary),
  - local sandbox evidence.

Example:

{
  "type": "learning.trace/local/v1",
  "id": "LT-2043-10-04-017",
  "origin": "PLB-L@ship-core",
  "scope": "NAV_LOW_THRUST_TUNING",
  "change": {
    "param": "low_thrust_delta_v_max",
    "before": 0.12,
    "after": 0.10,
    "bounds": [0.08, 0.12]
  },
  "evidence": {
    "patterns_seen": 34,
    "simulated_incident_reduction": 0.21,
    "sandbox_runs": 12
  },
  "ethics_check": "PASSED",
  "epoch": "NAV-POLICY-042"
}

EC can later:

inspect all learning.trace/local,
decide whether to:
- bless them and fold into a new epoch,
- or roll them back / tighten envelopes.

5.2 Human crew as local authority

For crewed missions, there is a third “core”: the human crew. In SI-Core terms, they are not outside the system; they are first-class actors with their own [ID] and authority.

Typical roles:

1. Local human-in-the-loop

Crew can override SC decisions on defined channels.
Overrides are recorded with:
- [ID] origin: crew_override,
- full [OBS] context and rationale (if provided).
Overrides are still subject to [ETH] and [MEM]; they are not invisible.

2. Crew as observers

Crew can inject structured observations:
- “unusual vibration in aft section”
- “visual streaks near port window”
These become semantic units in [OBS], often filling gaps from degraded sensors.

3. Crew as teachers

SC can present PLB-L proposals to crew for approval:
- “Proposed: tighten fuel leak detection threshold by 5%”
Crew can approve, veto, or defer, with all decisions logged as learning governance.

4. Emergency authority

Crew can trigger SAFE-MODE:
- suspend non-essential jumps,
- restrict actions to life-support and safety.
This is recorded as a high-priority event in [MEM] with [ID] attribution.

Interface principles:

Crew should be able to see GCS trade-offs (“this maneuver improves integrity but reduces science yield”).
They should be able to ask “why did SC do X?” and receive a concise EthicsTrace.
They cannot bypass constitutional bounds silently; emergency protocols must be explicit and logged.

Earth-side, EC later:

reviews crew overrides,
updates training and policy envelopes,
and may tighten or relax crew authority for future missions.

6. Example: micrometeoroid storm

A concrete story.

Context:

Ship: Voyager-Next in the outer solar system.
Goals (simplified):
- ship.integrity_maximization
- science_yield_maximization
- earth_link_availability
Latency to Earth: 4h one-way.
A micrometeoroid storm hits.

6.1 Onboard decision log (SC)

[2043-10-05T12:00:03.112Z] [OBS]
  stream: "hull_impact_sensors"
  semantic: "MM_STORM_STATE/v2"
  payload: {
    impact_rate_per_m2: 4.7,
    energy_spectrum: "high",
    predicted_duration_min: 23
  }
  confidence: 0.89

[2043-10-05T12:00:03.220Z] [JUMP] STORM_RESPONSE_001
  goals: ["ship.integrity_maximization", "science_yield_maximization"]
  rml_level: 3
  risk_profile: "HIGH"
  candidates: ["ORIENT_SHIELD", "MINIMAL_TILT", "NO_CHANGE"]
  origin: "ship-core://voyager-next"
  policy_epoch: "STORM-POLICY-003"

[2043-10-05T12:00:03.228Z] [GCS] ESTIMATE
  candidate: "ORIENT_SHIELD"
  gcs: {
    "ship.integrity_maximization": +0.92,
    "science_yield_maximization": -0.35,
    "earth_link_availability": -0.20
  }

[2043-10-05T12:00:03.240Z] [ETH] CHECK
  policy: "[email protected]"
  decision: "ALLOW"
  rationale: "integrity > link > science"

[2043-10-05T12:00:03.260Z] [EXEC] APPLY_ACTION
  action: "ORIENT_SHIELD"
  effects: [
    "attitude_change",
    "instrument_shutdown",
    "antenna_off_axis"
  ]
  effect_ledger_id: "EL-2043-10-05-SEG-101"
  rml_level: 3

[2043-10-05T12:23:42.511Z] [ROLLBACK] PARTIAL_RML3
  trigger: "STORM_STATE_NORMALIZED"
  compensators: [
    "restore_science_instruments",
    "reacquire_earth_link"
  ]
  status: SUCCESS
  RBL_ms: 8123
  residual_effects: [
    "lost_science_window: 21min"
  ]

All of this happens long before Earth sees it.

6.2 Earth-side audit hours later

Four hours later, EC receives a SCP/DTN bundle:

containing the segment above,
plus summary metrics for that storm.

Auditor replay:

re-runs the scenario with MINIMAL_TILT and NO_CHANGE in sandbox,
recomputes GCS trajectories,
checks that:
- ship.integrity_maximization was indeed prioritized,
- residual risk was acceptable,
- lost science yield is within mission trade-off policy.

If EC later refines [email protected]:

it issues v1.1 with improved trade-offs,
SC receives on next contact window,
future storms are governed under new epoch.

6.3 Compound emergency scenarios

Real deep-space incidents rarely come alone. They come in pairs or triplets. A few illustrative composites:

Scenario 1: Storm + Communications failure

A micrometeoroid storm hits.
Antenna alignment is lost; DTN link to Earth drops.
SC must choose:
- protect hull and crew,
- or prioritize antenna repair to restore link.

GCS conflict:

ship.integrity_maximization vs earth_link_availability vs science_yield_maximization.

Resolution pattern:

Constitutional priority: life > ship > link > science.
SC orients for hull protection first.
Antenna repair and science resume only after risk falls below a safe threshold.

Scenario 2: Sensor loss + fuel leak

Hull impact sensors are partially degraded; [OBS] coverage is low.
A fuel leak is detected by pressure sensors; actuator options are limited.
SC must operate under high uncertainty:
- [EVAL] forbids maneuvers that depend on precise hull state.
- RML-3 compensators use wider safety margins and pre-verified patterns.
EC is later informed with explicit “uncertainty metrics” in the segment.

Scenario 3: Compute degradation + navigation critical

Onboard compute fails to ~40% of nominal capacity.
An asteroid field requires a course correction within minutes.
PLB-L is suspended; no structural learning during the incident.
SC uses:
- pre-cached navigation patterns,
- minimal GCS estimation,
- pre-verified RML-2/3 compensators.

The decision framework under compound stress is:

Re-establish constitutional priorities (what absolutely must not fail?).
Shrink the action space to verified safe patterns.
Increase [EVAL] scrutiny for all effectful jumps.
Log uncertainty explicitly in [OBS] and [MEM].
Request EC guidance when (and if) communication returns.

Metric behavior under stress:

CAS may degrade (reproducibility is harder under partial failure) as long as this is logged.
EAI (ethics alignment) should remain high; ethics overlay is not optional.
RIR may temporarily decrease, but should stay above a minimum floor (e.g. 0.80) for critical compensations.

7. SCP patterns unique to DTN

Deep-space SCP needs a few extra patterns.

7.1 Semantic backlog and priority classes

Not all semantic units are equal when bandwidth is scarce.

Typical classes:

Class A — Governance-critical
- jump logs for safety-critical decisions,
- ethics traces, epoch changes,
- anomalies in RBL/RIR/EAI.
Class B — Mission-critical telemetry
- navigation, power, life support.
Class C — Science telemetry
- experiment results, observations.
Class D — Low-stakes / debug

SC must be able to:

downsample or delay C/D,
never intentionally drop A (governance-critical),
if A cannot be fully retained/transmitted due to physical failure (e.g., storage corruption), SC MUST emit:
- a key_trust_checkpoint_digest of what is missing (loss proof),
- an explicit ACR impact annotation for the affected segment,
- and a “degraded history” marker in [MEM],
provide semantic digests when full A detail cannot be sent over DTN (e.g. “MM storms: 12 events, all handled with RIR≥0.97”).

7.2 “Meaning checkpoints”

Because contact windows are rare, SC can create meaning checkpoints:

{
  "type": "meaning.checkpoint/v1",
  "id": "MC-2043-10-05-SEG-100",

  "epoch": {
    "mission": "MISSION-CONST-07",
    "nav": "NAV-POLICY-042",
    "ethics": "ETH-GLOBAL-009"
  },

  "metrics_spec": "series-aligned",
  "metrics": {
    "cas": 0.997,
    "rbl_p95_ms": 460,
    "eai": 0.981,
    "scover": 0.94,
    "acr": 0.99,
    "eoh": 0.18
  },

  "summary": {
    "major_events": [
      "MM_STORM_042",
      "ATTITUDE_RECOVERY_017"
    ]
  }
}

EC can quickly reconstruct:

which meaning regime the ship was operating under,
how healthy the core was,
where to drill deeper.

8. Governance of silence: when nothing comes back

A subtle but important aspect:

Silence itself is an observation.

EC must interpret:

no bundles received for 3 expected windows,
or only minimal “I am alive” beacons.

Patterns:

Silence as degraded [OBS]:
- treat missing segments as “unknown”, not “fine”.
- require broader safety margins in simulations and mission planning.
Silence as trigger for policy:
- if no contact for N days, assume SC has switched to AUTONOMY-FALLBACK mode:
  - stricter ethics constraints,
  - narrower action space,
  - more conservative GCS trade-offs.
Silence as input to PLB-G:
- repeated contact failures may indicate:
  - antenna misalignment from policies,
  - over-aggressive power saving, etc.
- PLB-G can propose new constraints for future missions to avoid such regimes.

9. Metrics and evaluation in deep space

The usual SI metrics still apply, just with a different flavor (example JSON uses lowercase keys: cas/eai/scover/...):

CAS: how reproducible are ship decisions across DET runs, given noisy sensors and changing comms?
SCover (scover): are all safety-critical jumps fully traced, even during blackouts?
EAI: pass ratio of ethics decisions on effectful ops under mission constraints.
EOH: evaluation overhead (e.g., eval_time / jump_time or time-based), especially under resource scarcity.
RBL / RIR: how quickly / reliably can SC roll back internal state after anomalies?
ACR: how complete are ship audit records relative to expected events, given DTN gaps and storage faults?
ETH_uptime (optional): fraction of time the ETH engine is available and enforcing (ALLOW|DENY|ESCALATE) under degraded modes.

EC can maintain dashboards that show, per mission segment:

“How governable was the ship, really?”,
“How close to envelope edges did SC operate?”,
“Where did local learning help, and where did it almost go wrong?”.

9.1 Failure modes and graceful degradation

Deep-space SI-Core must assume that things will fail: sensors, storage, compute, comms. The question is not “how to avoid failure” but “how to keep [OBS][ETH][MEM] minimally viable while it happens.”

Non-exhaustive failure modes:

1. Compute degradation

Partial failure:
- Reduce PLB-L frequency or disable non-critical learning loops.
- Drop to simpler GCS estimators.
- Reserve capacity for navigation, life support, and [ETH].
Critical failure:
- Enter AUTONOMY-FALLBACK mode:
  - freeze learning,
  - restrict action space to pre-verified patterns,
  - tighten safety margins.

2. Sensor degradation

[OBS] coverage drops or becomes noisy.
SC increases uncertainty estimates in semantic units.
[EVAL] raises thresholds for high-risk actions.
Decisions become more conservative; some actions are disallowed entirely.

3. Actuator failure

Some compensators in RML-2/3 are no longer available.
SC shrinks the reachable action space for relevant jumps.
Effects are annotated with “residual risk” and reported to EC when possible.

4. Storage corruption

[MEM] integrity checks fail on segments.
Redundant encoding / checksums allow partial recovery.
SC requests segment reconstruction from EC when link is available.
Until then, affected segments are marked as “degraded history” in audits.

5. DTN link extended outage

All governance is local; EC cannot help in real time.
SC switches to stricter constitutional bounds:
- narrower action options,
- more conservative GCS trade-offs,
- elevated thresholds for irreversible actions.
Periodic low-bandwidth “heartbeat” attempts continue.

Cascading failures can happen (e.g. sensor + compute + comms). The design goal is:

SC always maintains a minimal viable [OBS][ETH][MEM] core,
even under severe resource constraints.

That core may act slowly and conservatively, but it should never act unknowingly.

10. Closing: autonomy without amnesia

Deep-space SI-Core is the stress-test of the whole architecture:

No real-time human safety net.
No guarantee of perfect logs.
Plenty of irreversible physical actions.

The design challenge is:

Build a core that can act like a sovereign when it must — but still explain itself like a citizen when it comes home.

SCP over DTN, bounded local learning, epoch-based governance, and RML split into local vs global all point to the same idea:

Autonomy is a measured loan of authority, not a permanent divorce.
The ship is allowed to improvise within a constitution.
Earth is allowed to rewrite that constitution — slowly, with evidence.

From that perspective, deep space is just:

a particularly harsh environment to test what SI-Core really guarantees,
and a good thought experiment for any system where you cannot always “just call the API” of a central authority and wait for an answer.

Community

IkanRiddle

3 days ago

•

edited about 8 hours ago

🐾

Upload images, audio, and videos by dragging in the text input, pasting, or clicking here.

Tap or paste here to upload images

· Sign up or log in to comment

Upvote