Persistent network-owner checkpoints v1

Narrow observable model · 5 September 2026

Result and boundary

Five stable checkpoints from the real persistent-owner loopback harness match a separate Python owner model: healthy rejection, admission plus replay, held completion with one waiting request, timeout cleanup, and late completion. The harness also passes its fourteen existing checks of actual response bytes, locking and recovery.

Each checkpoint records live sessions, verification queue length, outstanding writer, fencing state, last reported claim count, submitted requests and prepared responses by status. A healthy rejection prepares status 0. Admission and replay prepare two status-1 responses. Timeout drops waiting sessions and queue work; a late success updates the observed claim count but prepares no response and does not clear fencing. Prepared responses are not proof of peer receipt; client reads are separately asserted.

The new model describes the current one-outstanding-request network owner, not the larger driver.py proposal with two commit lanes. It accepts abstract completion and timeout events; Rust supplies real sockets, signatures, ledger calls and a completion gate. Counts expose stable state, not every internal scheduling step. Four mutated checkpoint controls change fencing, outstanding submissions, queue cleanup or late responses and are detected by exact comparison.

The first capture exposed a harness timing assumption: a fixed four polling turns could finish before TCP data arrived. The harness now waits for malformed-session closure and waiting-job readiness under a 150-ms deadline. This checks the observed condition without assuming packet-delivery timing. Writer timeout remains 200 ms.

Reproduce

SKEIN_NETWORK_TRACE=1 cargo run --locked --offline --features peer-recovery --example admission_isolated > outputs/network-owner.json
python3 model/network_owner.py outputs/network-owner.json

Checkpoint recording is opt-in and allocates diagnostic JSON outside the production library. Existing resource measurements describe earlier snapshots and are not updated by this experiment. Captured checkpoints and comparison results are retained under docs/results/network-owner-v1*. No old reports are overwritten.

This is one finite schedule with five observations, not exhaustive model checking, full refinement of the larger driver model, or independent interoperability. Actual I/O faults, arbitrary interleavings, queue saturation, fairness and network recovery after process death remain outside this comparison. Next: expand shared schedules for disconnects, queue exhaustion and recovery before adding commit-lane complexity. No public ingress or Fly deployment is enabled.