Launch is a midpoint.

Stage contract

• Owns: execution controller + Nodus runner
• Before: generation.start_requested for a reserved lease
• After: customer-visible running only after verified runner heartbeat
• Transport: Kafka command + bidirectional gRPC/mTLS (runner ↔ gateway)
• Durable ack: desired-generation record persisted; runner proves identity before process start

A provider reporting “VM created” is not sufficient to advance customer-visible state.

Reconciliation model

The execution controller continuously compares desired and observed state:

Desired:  stage generation N is running under lease L
Observed: provider runtime, runner identity, heartbeat,
          progress, checkpoint state
Action:   provision | start | stop | fence | recover

That makes controller restarts and duplicate messages safe. An API request never waits for a workload to finish. Desired state is durable; observed state is derived from supplier and runtime signals; every action is safe to repeat. Correctness never depends on in-memory task ownership.

Provisioning flow

lease reserved
  → adapter provisions runtime
  → controller injects short-lived generation credentials
  → Nodus runner authenticates
  → runner heartbeat establishes generation ownership
  → user process starts

Runners are immutable, signed, versioned artifacts. They receive short-lived, generation-scoped credentials; run in a least-privilege sandbox; emit structured telemetry; and are denied broad customer storage access. The customer process is isolated from Nodus control credentials wherever the runtime permits it.

Runner responsibilities

• Pull image and materialize authorized inputs
• Launch the customer process
• Emit heartbeats, progress, logs, resource telemetry
• Request / coordinate safe checkpoints
• Publish signed lifecycle events
• Enforce generation-scoped output permissions
• Report observed usage for settlement

Continuity during the run

The controller and runner honor the envelope’s continuity mode:

• checkpointed: coordinate verified manifests; reclaim → restore gen N+1
• restartable: track shard / job cursor; reclaim → requeue unfinished units
• ephemeral: no durable progress required; interrupt ends or retries from origin per policy

The promise “when capacity disappears, execution keeps moving” applies when the chosen mode has a defined recovery path. Checkpointing is concurrent with execution, not a post-run stage.

Budget and cancellation

The controller tracks observed versus predicted spend. It can warn, stop launching new stages, request a checkpoint, or cancel according to policy. A resumable workload receives a checkpoint request before termination whenever the underlying capacity permits it.

Operational requirements

• Correlation ID through API, route, lease, runner, checkpoint, and invoice records
• Heartbeat timeout policy with jitter; a missed heartbeat does not immediately imply data loss
• Tenant-aware log/metric retention, redaction, and cost controls
• Controller actions rate-limited and backpressured so a supplier incident cannot trigger an uncontrolled recovery storm

Multi-stage DAGs are first-class later: each stage gets its own envelope, route, lease, generation, and optional final-manifest outputs for downstream inputs. Upstream stages never re-run after a downstream reclaim.

What ships next

Runner protocol and operator-assisted recovery are the near gate for “no double-writer under reclaim.” Automatic signed reclaim recovery, then multi-stage framework adapters, come after. Local provision remains a pilot toggle; wholesale live provisioning is the production path once supplier float and keys are in place.

Previous: 004 · Bidding. Next: 006 · Checkpointing.