Concept

Simulation-first execution

Changing a real network is the most consequential thing a state tool can do. RAHN's answer is a layered boundary: every plan executes in simulation by default, and real execution is opt-in, isolated, and gated — in that order, enforced structurally rather than by convention.

The layers

  1. Simulation default. The default backend produces an execution plan and simulates it — descriptions of what would happen, touching nothing. The simulation backend cannot reach the host by construction.
  2. Verification gate. The execution path is structurally unreachable without a verification result. This is a type-level and flow-level property of the code, not a warning message.
  3. Explicit opt-in. Real execution requires --execute --yes-i-know — a deliberate, unskippable acknowledgment.
  4. Isolation. Real changes run only through isolated Linux network namespaces: host-side operations are limited to ip netns add/del rahn-*, and all link/interface mutations happen inside ip netns exec rahn-* (ADR 0012). Non-Linux platforms refuse execution at runtime.

The backend abstraction

Since v0.7 (ADR 0016), backends sit behind an ExecutionBackend trait with capability negotiation: the simulation backend and the linux-ns backend implement the same interface, and unsupported capabilities are refused explicitly. rahn apply --backend selects the target.

Honest limits of the boundary

The model-reality gap is the deepest limitation: RAHN models a subset of network meaning, and it must never execute against a real network it cannot observe. The Linux execution path is validated by CI only — no independent host-safety review has been performed yet (that review is an open contribution opportunity). Both facts are recorded in the limitations baseline. v1.0 marks architectural stability, not production readiness.

Where to go next