SISR Overview

Self-Incremental Sovereign Reconstruction (SISR)

Advanced, opt-in. SISR is an extension of daedalus — it is not the core value proposition. A default daedalus build produces a simple, static, self-contained binary with no reconstruction machinery. SISR is documented here so the two models are easy to tell apart.

The two daedalus models

daedalus ships in two shapes. They look alike (same ./app.daedalus), but only one can update itself.

	Classic .daedalus (default)	SISR .daedalus (opt-in)
Build	`daedalus build ./app -o app.daedalus`	`daedalus build ./app -o app.daedalus --self-update`
Contents	launcher + payload (SquashFS)	launcher + payload + embedded SISR engine
Update	rebuild + redistribute	`./app.daedalus update` — self-rebuilds from signed deltas
Toolchain on target	none	still none (engine is embedded)
Behavior	static container	static container by default, updatable on demand
Trust	signature at launch	signature at launch + signed chain for every delta

The single most important property: both shapes run identically by default. SISR is dormant until the user asks for an update. Turning it on never changes what a normal launch does — the embedded engine is only invoked explicitly (invariant I-2 of the SISR spec).

Why SISR exists

A classic .daedalus is immutable. Shipping a fix means:

[dev machine] daedalus build  →  [v1.1 .daedalus]  →  redistribute  →  [target]

For a handful of servers that's acceptable. For fleets behind slow links, or for security patches that must land fast, redistributing the whole binary each time is wasteful. SISR moves the last step of that pipeline onto the target machine itself:

the binary fetches only the changed bytes (deltas / chunks),
it verifies them against a signed chain of trust,
it reassembles itself into the next version, atomically.

The reconstruction flow

[ Binary v1.0 ] ──( ./app.daedalus update )──▶ [ Interrogate remote manifest ]
                                                │
                                                ▼
                                       [ Download deltas / chunks ]
                                                │
                                                ▼
                                   [ Validate Ed25519 signatures + hashes ]
                                                │
                                                ▼
[ Binary v1.1 ] ◀──( Rebuild & atomic swap )───┘

At every arrow, nothing is trusted until verified:

Interrogate — the binary fetches the remote manifest for its channel.
Download — it pulls only the blocks that changed since v1.0 (content-defined chunks, see the delta manifest spec).
Validate — every block is checked against its SHA-256 content hash and the whole update against the signed manifest (Ed25519 chain of trust, anti-rollback index).
Rebuild & swap — the new binary is assembled in a staging location, verified end-to-end, then committed atomically. An interruption leaves v1.0 intact and running.

Three responsibilities, one file

The flow above is driven by the embedded SISR engine, a dormant third responsibility inside the binary (next to the launcher and the payload):

+-----------------------------------------------------------------+
|                         APP.ERE (ELF)                          |
+-----------------------------------------------------------------+
|  1. Entrypoint Launcher  --> Bootstrap + runtime isolation       |
+-----------------------------------------------------------------+
|  2. Embedded SISR Engine --> Verify, fetch & assemble (dormant)  |
+-----------------------------------------------------------------+
|  3. Payload (SquashFS)   --> Application code & assets           |
+-----------------------------------------------------------------+

Launcher — unchanged. Reads the footer, verifies integrity, extracts, execs.
SISR Engine — only engaged by an explicit update trigger. Runs in-process, never shells out, never listens on a port.
Payload — the SquashFS image the engine reconstructs block by block.

What a developer needs to remember

SISR is opt-in at build time and explicit at run time.
The target machine never needs the daedalus CLI, a compiler, or a system runtime — the engine is compiled statically into the binary.
Every update is signed, monotonic (anti-rollback), and atomic. An unsigned, replayed, or tampered update is rejected before any byte is written.
The cryptographic guarantees are identical to the ones daedalus already provides at launch — SISR extends the same trust chain to updates, it does not create a weaker one.

Where to go next

Delta manifest format — how an update is described and verified.
Incremental updates guide — how to build, sign, and deploy an updatable binary.
SISR conceptual specification — the invariants and trust model behind this extension.

← Architecture Rollback & Resilience →