Isolated admission writer v1

Experimental loopback integration · 5 September 2026

Result

Twelve checks pass with the network pump and ledger owner on separate threads. Normal admission receives a response after completion; replay adds no record. A later admission commits while its completion notification is held by a test gate. The network pump still closes a malformed connection and holds one waiting request in its bounded verification queue. No early response is visible to the held client.

The writer's 200-ms deadline fences submissions, closes waiting sessions and clears the queue. A new connection is refused. A second handoff is rejected both while the first is outstanding and after its late completion. The ledger's OS lock remains exclusive while the worker owns it. Releasing the gate delivers one late success, which is suppressed without automatically clearing the fence.

After joining the owner, clean reopen finds both committed admissions. Replaying the unacknowledged claim adds zero bytes. Total journal growth is 442 bytes for two records; three submitted operations include the earlier replay. Final session and queue counts are zero.

Ownership and bounds

One persistent thread owns the ledger for its lifetime. Request and completion channels each have capacity one; an explicit outstanding-request flag prevents a second submission even after the worker has removed the first from its channel. The network loop uses nonblocking submission and completion polling. It never waits for a commit, starts a replacement writer, or reopens the active ledger.

Four fixed session slots and the four-job preverification queue retain existing framing/output caps. While the owner is busy, further jobs remain unverified in that queue. This bounds work but does not guarantee newcomer or evidence service. Decoded requests, descriptor clones, channel storage and thread stacks add costs beyond the array capacities reported by the preceding experiment. RAM is unmeasured.

Deadline checking precedes completion processing. A completion observed after the deadline is conservatively suppressed even if the operation finished earlier. Every ledger error also fences this experimental owner; distinguishing ordinary policy refusal from uncertain I/O failure remains future work. Recovery here is explicit clean shutdown and reopen, not an automatic production recovery loop.

Failure model and reproduction

cargo run --locked --offline --features peer-recovery --example admission_isolated

The executable uses finite loopback clients and fixed signed fixtures at policy time 100. The optional gate delays notification after a real ledger operation; it neither suspends nor cancels OS fsync. The network path is separated from the owner, but actual stuck-filesystem behavior and process failure remain untested here. Shutdown joins the owner and can wait indefinitely if its OS call never returns. No timeout grants permission to run a second writer.

The unsigned 34-byte experimental response and missing authentication/descriptor transport remain unchanged. Timed CPU budgets and reserved commit lanes are absent. This is a research harness, not a public admission service.

Results are retained in docs/results/admission-isolated-v1.json, with source and binary hashes in the accompanying manifest. Next: measure allocation and process costs of the bounded pipeline, then refine error classification and recovery against the existing model before adding scheduling features. Independent review, complete wire profiles and real filesystem-stall evidence remain open. No Fly deployment is enabled by this experiment.