Ingress progress contract v1

Status: informative chronological experiment log, not a new normative wire requirement. Early sections describe historical runtime stages; later sections record their successors and the current integration decision. Admission permission still neither guarantees retention nor entitles a sender to attention.

Observed boundary

src/admission_ingress.rs accepts TCP connections and allocates one of four session workers before calling receive_descriptor. The transport validates framing and the group MAC inside that worker with a two-second deadline (src/admission_transport.rs). When all workers are occupied, later connections are dropped before authentication. The two-item queue and 32-attempt admission budget apply only after this boundary. They cannot protect access to it.

The new unauthenticated_full_pool_blocks_then_releases_admission test holds four incomplete handshakes open, observes all four active sessions, submits a valid fifth request, waits for server timeouts without disconnecting attackers, and then submits a fresh valid request. It checks unchanged journal bytes and zero authentication/admission attempts before release, four receive timeouts, one overload drop, then exactly one successful admission. The native run released all sessions after 2,010 ms; preauth-slot-boundary-v1.log preserves raw output. This shows a local mechanism consistent with Fly connection loss, not attribution of every proxy/network error in the cloud reports.

Properties and assumptions

• Bounded pre-authentication state: at most four active session workers; no admission debit or journal mutation for incomplete handshakes. Tested locally.
• Eventual slot release: all four incomplete handshakes time out while client sockets remain open. The test ceiling is five seconds from first connection, allowing scheduling tolerance around the two-second transport deadline.
• Recovery after pressure stops: the next valid request succeeds after observed slot release, without owner fencing. Tested locally; separate finite Fly runs provide recovery evidence under their documented conditions.
• Honest progress under replenishment: at least one valid response per honest client within a specified window despite explicitly bounded competing traffic. This is an open target; the implementation offers no such guarantee.

The recovery test assumes a scheduled, healthy process, functioning sockets and disk, current descriptor/epoch, remaining connection and admission budgets, and no new connection winning the released slot. Its five-second test ceiling is not a protocol latency promise. Finite-run exhaustion intentionally ends service. A malicious invitation holder can also consume authenticated budgets; protection against unauthenticated handshakes does not solve that separate problem.

Why unconditional progress is not a credible requirement

An attacker able to occupy every bounded pre-authentication slot can keep an honest caller outside the authentication boundary. Shorter timeouts reduce holding cost but do not prevent immediate replacement. More slots move the resource bound. A reserve cannot distinguish an honest identity before that identity is verified. Shared invitation MACs establish group membership, not independent participants; source IPs behind proxies or NAT are not reliable participant identities.

Any future progress claim must specify adversary connection rate/concurrency, what layer observes it, network/CPU/disk bounds, scheduling policy, credential assumptions, available budgets, and the maximum honest service delay. Without a scarcity, routing or scheduling assumption, sustained availability remains best effort. Do not translate a finite recovery pass into a fairness guarantee.

Next experiment and decision gate

First instrument a local staged handshake workload to separate time spent before the client hello, after the server nonce, receiving authenticated payload, and waiting for the ledger. Reuse aggregate counters and fixed budgets; avoid an unbounded per-client tracking map. Include complete-but-unauthenticated hellos, slow payloads, bad MACs, high-latency valid clients and exhausted run budgets.

Then compare the unchanged control with one candidate that limits pre-authentication holding time separately from authenticated payload/ledger time. Keep connection volume, arrival schedule and runtime capacity fixed. Measure honest responses and errors unconditionally, per-client longest service gap, handshake rejection stage, CPU, memory and post-pressure recovery. A faster timeout is not acceptable merely because it rejects distant legitimate clients faster. Only promote a candidate if the declared threat/latency envelope and its counterexamples remain explicit; otherwise preserve the control and report the failed hypothesis.

IPFS and optional archive adapters do not change this ingress boundary and remain deferred. External independent review is still required before wider deployment.

Validation record

The expanded Linux/amd64 suite passed 47 release tests under one CPU / 256 MiB (preauth-linux-v1.json and log). The test image admission binary matches the deployed SHA-256 exactly; only test coverage changed. Native formatting and Clippy checks passed. No new Fly deployment was needed for this diagnosis.

Initial-hello deadline experiment: rejected candidate

scripts/test_handshake_deadlines.py creates a disposable source copy, retaining the normal two-second transport deadline while comparing initial-hello budgets of 2,000 ms and 500 ms. It uses the actual frame/MAC code and six cases per budget: fast exchange, incomplete hello, complete hello followed by silence, legitimate 750 ms hello delay, legitimate 750 ms payload delay, and invalid MAC. Production source and the deployed image remain unchanged.

All 12 expected outcomes passed (hello-deadline-v1.json and log). Silent initial hellos timed out in 2,002 ms under the control and 502 ms under the candidate. But a complete nonce hello followed by silence occupied the receiver for 2,002 ms and 2,001 ms respectively. The client hello is not an authentication proof: the server cannot verify group membership until the request payload and MAC arrive. An attacker needs no credential to wait at the second stage.

Both budgets accepted the fast exchange and delayed payload and rejected the bad MAC. Only the control accepted the legitimate delayed hello (759 ms); the candidate cut it off after 502 ms. These are injected application delays on native loopback, not a WAN latency distribution. The eight-byte authenticated test payload exercises transport framing only and is not a valid descriptor or ledger admission.

Decision: do not promote the shorter initial-hello deadline. It rejects some legitimate callers while leaving an easy unauthenticated path to the full holding budget. The test suite passing means the diagnosis is reproduced, not that the candidate meets a progress target. IP-based fairness or a capacity increase does not follow from this result.

Next evaluate a small bounded authentication exchange before accepting the larger payload, or an incremental receiver that avoids dedicating a worker while waiting for authentication. Compare their wire compatibility, extra round trips, CPU, memory, replay handling and high-latency client outcomes before selecting either. Both remain finite-resource mechanisms; neither creates unconditional availability against arbitrary arrival rates. Preserve existing wire behavior until a concrete candidate and its assumptions are tested.

Early authentication versus incremental receiving

The next isolated prototype adds a four-byte frame length and a 32-byte MAC after the server challenge and before the descriptor payload. The proof covers an experimental domain, role 3, Thread constant and both connection nonces using the existing HMAC construction. It cannot be reused with another challenge, role or domain. Payload and response MACs remain independently required. A client can send proof then payload without waiting for a new server acknowledgement: 36 extra client bytes and a MAC computation/verification, with no additional protocol round trip. This is an algorithmic observation, not a WAN benchmark.

Eight expected native loopback outcomes passed in a disposable source copy: valid proof, 750 ms delayed proof, absent proof, corrupt proof, wrong role, proof bound to another server nonce, wrong domain and corrupt payload. Invalid proof cases were rejected before a deliberately withheld payload arrived. The delayed proof succeeded after 760 ms. The missing proof still occupied the receiver for 2,002 ms. early-auth-v1.json and its log retain the evidence. The nonce-mismatch test models a proof from another challenge; it is not a multi-process replay campaign. Payload bytes exercise transport, not admission.

Early-proof option: the parser can reject nonmembers before allocating and waiting for a large payload, provided the small proof frame is bounded separately. This requires an explicit new wire profile and compatible clients. It does not prevent missing-proof slot occupancy or malicious group members from submitting large payloads. The experiment did not integrate a production scheduler or prove process-memory savings. Its receive/exchange modifications are disposable test code, not a supported endpoint or a drop-in protocol upgrade.

Incremental-receiver option: existing examples/loopback/input.rs reads at most once per scheduler turn into a fixed 884-byte fixture buffer, and examples/admission_concurrent.rs retains four socket slots without dedicating a worker to each wait. This reuses demonstrated scheduling ideas without changing wire bytes in principle. The existing example does not implement the current nonce/MAC descriptor handshake; adapting all read/write stages and deadlines is still work. Its synchronous ledger can stall the pump. Four occupied slots still exclude the fifth caller, even without four worker threads. Increasing the pending pool would change capacity, not establish fairness.

Decision: retain both as resource-isolation ideas, promote neither as an availability fix. Early proof addresses pre-authentication payload allocation; incremental receiving addresses waiting-worker cost. They are complementary, not competing proofs of honest progress. Before a runtime change, specify one resource objective, measure it against the current control, and keep the adversarial arrival assumptions explicit. Do not add a general adapter framework, new currency or unbounded identity map to solve this local scheduling boundary.

Measured objective: frame allocation before authentication

The objective for this comparison is narrow: prevent a caller without a valid group proof from causing the descriptor-sized read_frame allocation. It is not a new honest-progress, total-memory or throughput objective.

scripts/test_preauth_allocations.py instruments requested Vec lengths inside src/peer.rs::read_frame in a disposable source copy. Thread-local records exclude client-side allocations. It records the frame count at successful proof verification (or at full payload authentication for the control), then compares five cases for each profile: legal maximum length with no body, invalid authentication, valid maximum transport payload, a member's truncated payload and an oversized prefix. All ten expected cases passed; see preauth-allocation-v1.json and log.

• Current control: a legal maximum prefix alone requests a 66,018-byte frame buffer before payload bytes or MAC arrive. Including the earlier 32-byte hello, summed pre-authentication frame requests are 66,050 bytes.
• Early-proof candidate: a large prefix in place of the proof is rejected before allocating that body. Invalid proofs request at most a 32-byte frame. Valid proof paths request two 32-byte frames (64 bytes summed) before authentication.
• Legitimate maximum payload: both profiles accept the 65,986-byte transport payload; the candidate requests its 66,018-byte payload/MAC buffer after proof. This zero-filled transport test does not claim valid descriptor admission.
• Credential-holder limit: a valid proof followed by a legal maximum prefix still causes the larger allocation, even if the body is withheld. The resource boundary separates nonmembers from members; it is not Sybil resistance.
• Oversized length: both profiles reject it before allocating the claimed body.

Requested frame lengths exclude allocation metadata, capacity rounding, MAC preimages, payload copies, stacks, kernel buffers and process RSS. Summed requests are not peak live memory. Four maximum waiting frame buffers would total 264,072 requested bytes by arithmetic; this run did not measure four simultaneous live allocations or process savings. It would be misleading to advertise a comparable percentage reduction in total node RAM.

Decision: the candidate meets this specific frame-allocation objective. It remains experimental: it does not solve slot starvation, and the current control already bounds these buffers. Before adding a wire profile, measure honest-path CPU, byte and latency overhead and validate version negotiation and malformed-proof compatibility. A bounded saving alone does not justify silently changing the existing transport. The runtime, release/readiness v8 and deployed image remain unchanged; optional archive adapters remain unrelated to this ingress decision.

Honest-path cost and profile compatibility

The release-mode loopback comparison in early-auth-overhead-v2.json passes 12 timing batches and all four old/new client/server combinations. Each batch uses ten warmups followed by 50 fresh TCP connections, with current-first and candidate-first orders at payload sizes 8, 1,024 and 65,986 bytes. Responses are MAC- and digest-checked. Zero-filled payloads exercise transport, not descriptor admission. Reproduce with python3 scripts/test_early_auth_overhead.py --output docs/results/early-auth-overhead-NEW (use a fresh prefix).

• Matching current profiles and matching experimental profiles succeed. Both mixed combinations fail. Domain authentication prevents silent fallback; automatic version negotiation is not implemented or tested.
• The proof adds exactly 36 client framing bytes (four-byte length plus 32-byte MAC). Server framing remains 138 bytes for this response. These are derived protocol byte counts, excluding TCP, IP and TLS overhead.
• For the maximum payload, current/candidate batch medians are 186/194 microseconds in current-first order and 182/191 microseconds in candidate-first order. Their p95 values are 267/300 and 193/237 microseconds, respectively.
• Small-payload batch medians span 86–177 microseconds for current and 88–163 for candidate. Order effects and scheduler variation prevent a credible general latency or speedup claim from this small single-host sample.

These are native macOS arm64 wall-clock measurements including connect and response verification, with TCP_NODELAY enabled and frame coalescing disabled. They do not measure CPU consumption, WAN latency, TLS, concurrency or admission storage work. The proof follows the existing server hello and can precede the payload without another protocol round trip; this is a message-sequence property, not a measured WAN result.

The first run's Rust tests passed, but its JSON collector omitted results prefixed by the test harness. Preserve early-auth-overhead-v1.json as a failed collection and its complete raw log. The corrected collector produced the separate v2 run; v1's inherited scope description is also superseded by v2.

Decision: keep early proof experimental. It establishes a useful allocation boundary at a small fixed wire cost, but breaks profile compatibility and leaves slot availability unchanged. Integration needs a justified CPU/resource benefit and an explicit version rollout contract. Do not change the deployed handshake solely on this measurement. Release/readiness v8 remains unchanged.

Version rollout boundary

docs/EARLY_PROOF_ROLLOUT_V1.md defines the proposed opt-in rollout contract: separate configured endpoints, distinct authenticated domains, no automatic downgrade, unchanged admission/journal formats and explicit rollback. It is not an activated wire standard. The existing four-worker profile bounds the affected buffers already, so integration needs measured operational benefit, not just a cheap extra HMAC.

CPU measurement and integration decision

early-auth-cpu-v1.json records 32 release-mode batches across four alternating orders. The test uses POSIX process CPU time, with 1,000 warmups and 100,000 iterations per small-payload batch (10,000 for maximum payloads). Each operation calls the existing Session seal/verify implementation, including HMAC key construction and temporary allocations. It runs in a disposable copy; no socket is opened and no runtime dependency is added.

• Proof-only signing plus verification costs 349.9–350.9 ns per iteration on this macOS arm64 host; the empty-loop control costs 0.9–1.1 ns.
• An 8-byte payload costs 370.7–378.6 ns without proof and 725.1–754.5 ns with it.
• A 1,024-byte payload costs 1,032.0–1,045.8 ns without and 1,392.3–1,415.6 ns with it.
• A 65,986-byte payload costs 45.06–45.22 microseconds without and 45.44–45.53 microseconds with it.

These measure combined client signing and server verification in one process, not either endpoint's total CPU. They exclude nonce generation, socket/framing I/O, TLS, response work, descriptor checks and storage. Fixed synthetic nonces and payloads are benchmark inputs, not a proposed nonce-generation policy. The results are host-specific batch averages, not latency percentiles or throughput promises. Reproduce with python3 scripts/test_early_auth_cpu.py --output docs/results/early-auth-cpu-NEW.

Decision: defer integration. The extra cryptographic work is small in absolute terms but approximately doubles the tiny-payload pair's cryptographic work. The allocation saving is bounded already by the four-worker control. A separate wire profile adds migration work and does not solve occupied-session exclusion. Keep these results and the rollout contract as evidence; return to bounded ingress scheduling and explicit honest-progress assumptions rather than promoting an availability claim. No new Fly image, endpoint or protocol version is activated.

Bounded idle-eviction counterexample

model/ingress_slots.py compares four drop-new slots with four slots that evict the least recently active session when its idle time reaches 250 ms. Both retain an absolute 2,000 ms lifetime. This is an abstract deterministic model: it does not implement sockets, frame validation, CPU scheduling, cryptography or the ledger. The runtime remains unchanged. Only the modeled active slots are bounded; offline workload and result records are not proposed runtime state.

Sixteen cases combine two policies, two honest completion delays (20/750 ms), and four fixed arrival schedules. Four silent attackers initially occupy the pool. Eight honest requests arrive 500 ms apart starting at 300 ms. Replenishment sends four new attacker connections every 500 ms through 4,000 ms; churn uses 100 ms. The trickle case adds abstract observed activity every 100 ms to retained attacker sessions. Observed activity is deliberately not treated as authenticated progress. At equal timestamps completion/expiry occurs first, then attacker arrivals precede honest arrivals. Each policy sees the same hashed arrival workload.

Results in ingress-slot-model-v2.json, expressed as completed honest requests:

• Initial silent burst: drop-new completes 4/8 and idle eviction 8/8 at either delay.
• Replenishment, 20 ms honest delay: drop-new completes 0/8, eviction 8/8.
• Replenishment, 750 ms honest delay: drop-new completes 0/8, eviction only 1/8; slower honest sessions are themselves evicted.
• Trickle activity or 100 ms churn: both policies complete 0/8 at either delay.
• Every case stays within four active slots and completes a recovery request at 6,500 ms, after all attacker sessions must have expired.

The completion observation window is 0–5,000 ms; raw outcomes include each honest request's drop, eviction or completion. Four regression tests check bounded slots, post-expiry recovery, the slow-client eviction counterexample, trickle starvation and matching workload identities. Reproduce with python3 -m unittest discover -s model -p test_ingress_slots.py and python3 model/ingress_slots.py --output docs/results/ingress-slot-model-NEW.json (join wrapped command lines).

The preliminary v1 report remains retained: its 4,000 ms observation endpoint was too early for late honest completions, and its 5,500 ms recovery probe preceded the last possible expiry. V2 corrects those measurement windows; it does not change policy behavior or the eight honest attempts. Neither report is network evidence.

Decision: do not promote idle eviction as an honest-progress mechanism. Its success requires a quiet interval long enough for the honest exchange; the model provides direct counterexamples when that assumption fails. Activity-based preference can reward unauthenticated trickling. Larger pools or incremental I/O can improve resource use but cannot supply an honest-identity distinction.

The next implementation experiment should therefore target a narrower property: advance each retained transport session by bounded nonblocking work while preserving its absolute deadline and existing wire bytes. Keep the same four-slot control, and measure waiting-worker cost separately from honest completion. Any subsequent availability claim still needs bounded arrival pressure and reachable admission capacity; do not introduce per-IP identity assumptions behind the proxy.

Incremental current-wire prototype

scripts/test_incremental_transport.py appends a test-only server pump to a disposable source copy. Its stages are client hello, server hello output, payload, reply output and done. The existing client, session domain, nonce binding, payload MAC and response binding are reused. No production transport source is changed.

Each turn issues at most one read or write, requesting at most 4,096 bytes. Partial headers/bodies/output retain offsets; WouldBlock and Interrupted yield. The absolute two-second deadline is checked before each turn and never reset. Complete-frame HMAC and digest work remains synchronous and bounded by the existing descriptor size limit. This is a byte/syscall bound, not a hard CPU-time bound. Maximum payload allocation still occurs before MAC verification.

The loopback test retains two sessions in a single server pump: one silent socket and one current client. It checks 8-, 1,024- and 65,986-byte authenticated payloads. A separate fragmented-I/O test checks single-byte progress, yielding, the per-turn syscall/byte bounds, valid/invalid MAC outcomes and an already-expired deadline that performs no I/O. Test response status is synthetic: these are transport payloads, not accepted descriptors or ledger mutations.

No per-session server worker is created. The client runs in a test thread; the server polls with a 100-microsecond sleep. This is not an OS-readiness scheduler, a measured CPU/RSS improvement, a full four-slot pressure test or an end-to-end admission driver. Endpoint allowlist checks, production slot ownership, admission queueing, journal work and shutdown/error accounting remain integration work. The pump must not be exposed as a standalone public server.

The initial sandboxed run (incremental-transport-v1) passed the in-memory test but could not bind a loopback listener. Its report/log are retained. The separately authorized socket run is recorded as v2. Use a fresh output prefix to reproduce: python3 scripts/test_incremental_transport.py --output docs/results/incremental-transport-NEW.

V2 passes all four reported cases. The current clients complete in 6, 7 and 22 pump turns respectively (about 0.83, 0.84 and 2.88 ms on this host). Poll sleeps and OS scheduling affect those times; they are not a comparison against the worker control. This establishes prototype wire compatibility and cooperative progress with one silent neighbor, not fairness at a full pool.

Next gate: exercise a fixed four-slot owner, output backpressure, malformed length/EOF handling and actual deadline release/recovery. Compare resource costs against the worker control before production integration. Keep the experiment finite; return to networked admission/retention after that decision.

Four-slot gate and resource decision

The extended isolated fixture (incremental-owner-v1.json) passes six reported cases. Its fixed four-element slot array rejects a fifth connection, releases all four silent sockets after 2,001 ms and serves a fresh current-client request in a released slot. This is test ownership logic, not the production ingress driver. A deterministic writer alternates WouldBlock, Interrupted and one-byte writes: all 70 reply-frame bytes arrive unchanged after 210 calls, without deadline reset. Malformed/partial headers and EOF terminate locally without body allocation. These complement the prior current-client and invalid-MAC checks.

incremental-resources-v1.json compares four silent sockets through their actual two-second deadlines in both worker-first and pump-first order. The control calls the unchanged blocking receiver in four threads. The candidate polls the same number of sockets with a one-millisecond sleep and no per-session worker. POSIX process CPU measurements on this native Mac are:

• Workers: 792 and 535 microseconds CPU over 2,001 and 2,000 ms wall time.
• Polling pump: 20,395 and 19,263 microseconds CPU over 2,002 ms wall time.
• The pump made 1,590 and 1,595 scheduler turns. Its inline struct is 208 bytes; this excludes heap buffers, sockets and stacks and is not a process RAM result.

These are four idle batches, not loaded throughput or Linux/Fly measurements. They include control thread startup/join and candidate polling. The test process CPU includes all its threads. No RSS improvement has been measured. Scripts test_incremental_owner.py and test_incremental_resources.py under scripts/ accept fresh --output prefixes to reproduce the reports.

Decision: preserve the current worker runtime. Incremental current-wire handling is feasible, but this sleep-polling implementation spends more idle CPU and retains the same full-pool exclusion boundary. Do not integrate it on thread count alone. If measured concurrent workloads later justify an event loop, use OS readiness notification and repeat resource/recovery validation. Close this exploratory gate and return to networked scoped admission and retention. No deployment change is needed for these results; release/readiness v8 remains unchanged.

Return to admission and discovery integration

The next track now has a native test-only bridge in examples/admitted_discovery.rs: bounded submission decoding, durable verified admission, bounded Beacon retention and existing cosine queries. Its regression passes lineage/capacity refusal, replay, invalid signatures, retrieval filtering, expiry and rollback checks. Full protocol identities and sponsor provenance remain intact. The deployed rendezvous store is unchanged; this is not yet a networked retention service. Details and the process-boundary integration gate are recorded in docs/RENDEZVOUS_V1.md.

The bridge now also passes a finite child-process loopback test: three admissions compete for two retention entries, replay consumes no additional claim, malformed submission leaves the index intact, and matching/nonmatching queries produce separate outcomes. It uses a bounded local JSON harness around existing submission bytes, not the deployed HMAC/TLS transport. The first socket-mode failure and the passing v2 log are preserved. See docs/RENDEZVOUS_V1.md for scope and reproduction.

A fresh-process recovery test now confirms that an empty expired discovery cache does not remove established Thread history. The saved signed dependency chain and admission ledger reopen, unauthorized writing remains refused, and a legitimate post-restart event references the earlier head. This is clean save/reopen evidence, not crash-during-write or automatic discovery refill. See the rendezvous integration record and examples/admitted_discovery_recovery.rs.

Admitted discovery lifecycle milestone

The isolated lifecycle now includes cold-cache resubmission without additional admission debits, changed retention order and query-only expiry across process restart. A failing regression exposed the earlier query prototypes' volatile clock; the current refill example durably observes time before serving queries. The release-suite runner is scripts/test_admitted_discovery_milestone.py; the contract and limits are in docs/ADMITTED_DISCOVERY_MILESTONE_V1.md. This is the integration milestone for the examples, not a deployed admission/retention endpoint. Next work connects the validated semantics to an explicit authenticated endpoint and measures query clock persistence before any new finite Fly cohort.

Endpoint wire-boundary milestone

The experimental endpoint now has a concrete bounded request/response codec and an isolated authenticated query exchange under a distinct domain. Codec tests and the loopback gate pass, including old-client refusal and wrong-request-tag rejection. Responses in that transport test are synthetic; ledger/cache/TLS owner integration remains next. docs/ADMITTED_DISCOVERY_ENDPOINT_V1.md specifies the layout and limits.

Measured native clock observation costs about 8 ms when advancing and tens of nanoseconds when repeating the same second. Retain the existing equal-second coalescing and durable-before-results contract. These are local operation timings, not Fly volume or query-throughput measurements. No new deployment is activated.

Authenticated owner milestone

The experimental endpoint now runs real admission and queries through a serial cache/ledger owner behind nonce/HMAC framing. Nine authenticated requests verify retention refusal, replay, real retrieval, malformed-input refusal and clock-write failure fencing. Reopen/refill, rollback and budget checks pass. The five combined owner/codec tests also pass in a local Linux/amd64 container at one CPU/256 MiB.

Advancing clock observations take about 1.9–2.0 ms median in local container storage; this is not Fly-volume evidence. The test image is local-only. Production and readiness v8 are unchanged. Bounded concurrent dispatch and late completion handling remain the next runtime-integration gate; the endpoint contract records exact scope.

Bounded owner dispatch milestone

One active operation, two pending bodies and capacity-one channels now wrap the experimental real owner. Six modes pass: ordered completion, active timeout, shutdown while notification is held, wrong completion identity, queued expiry and storage failure. Late results are suppressed, queued work is cancelled on fencing, and replay after reopening adds no debit. The gate holds notification after a real operation, not an actual stalled fsync. Shutdown joins that same owner and can still wait indefinitely on a genuinely stuck OS operation.

The complete owner/codec/dispatch suite passes in native release and local Linux/amd64 at one CPU/256 MiB. Simultaneous authenticated session-to-dispatch routing remains the next integration step; these tests do not change the deployed driver, prove fairness or establish new public readiness. Details and test limits are recorded in the endpoint contract.

Connected authenticated-path milestone

The session fixture now routes overlapping authenticated clients through the actual bounded dispatcher and owner. Twelve sessions cover normal replies, overflow, active-timeout cancellation and client disconnect. Surviving replies bind to each caller's exact claim/descriptor; cancelled routes receive unavailable and late success is never reassigned. The original socket deadline limits queued work.

All seven combined tests pass natively and in local Linux/amd64 at one CPU/256 MiB. This remains a fixed connection-count harness with fixture time and controlled handshake order. The next step is a single opt-in runtime implementation with real configuration/time and process lifecycle validation, not another new wire feature. No deployment or readiness-v8 change is claimed from these tests.

Opt-in runtime ready for Fly staging

skein-admitted-discovery now implements the connected path with real receiver time, configuration, finite session/owner budgets and process shutdown. Native lifecycle checks, 32 library tests and constrained Linux process tests pass. The minimal Linux binary is 869,368 bytes and the image runs as UID 10001. The new artifact is pinned in docs/results/admitted-runtime-build-v1.json.

The approved image reached Fly, where two finite attempts failed at startup: listener validation incorrectly rejected the wildcard TLS-proxy bind. Both machines were destroyed; historical configuration remains unchanged and stopped. The corrected listener preserves private-origin checks and passes both private and TLS-proxy lifecycle tests natively and on constrained Linux. Its binary is 869,496 bytes; docs/results/admitted-runtime-build-v2.json pins the correction.

The corrected image subsequently passed the finite public TLS cohort: three signed admissions and retrieval, replay, forged-input and wrong-credential refusal with successful subsequent queries, then cold-cache restart/refill without journal growth. Report admitted-fly-lifecycle-v3.json and milestone manifest admitted-fly-milestone-v1.json retain the evidence. Both finite processes stopped; the temporary machine was destroyed and historical configurations stayed unchanged. Lifetime shutdown sets the reported fence flag; no overload or late results occurred.

This is invitation-authenticated lifecycle evidence, not unrestricted public admission or a pressure benchmark. Next comes scoped retention-policy integration and adversarial/newcomer testing over the network profile. Historical readiness v8 remains tied to its old image and source pins. See docs/ADMITTED_RUNTIME_V1.md.

Separate retention capacities after Fly

The working runtime now reserves separate non-borrowing open-cost and sponsorship lanes, keeping beneficiary and issuer concentration caps. Signed-claim tests with 24 arrivals preserve four entries per class in an eight-entry cache in either class order. Correlated sponsorship retains one sponsored entry; four open-cost entries remain available. Replay, retrieval, expiry and clock rollback checks pass. This change is not part of the previously tested Fly image.

Public testing is the next direction, including no-invitation admission when the explicit profile is ready. First measure the shared admission journal and process attempt budgets: class retention cannot repair exhaustion at an earlier stage. Open-cost evidence does not identify honest newcomers. Details and evidence are in docs/ADMITTED_RUNTIME_V1.md.

Unrestricted public admission tested on Fly

The separate public profile requires no invitation, client allowlist or group secret. Verified TLS protects the connection; signed scoped claims and proof verification still govern admission. The finite Fly test admitted/retrieved three independently signed open-cost descriptors, refused forged input and exhausted the 32-attempt submission budget. A subsequent valid submission was refused while queries still returned all retained descriptors. This is an observed admission availability limit, not an anti-DoS guarantee.

Cold-cache process restart/refill preserved journal bytes and claim count. The first process routed 37 requests and the second three, with no overload or late replies. Both ended at their finite deadlines; the temporary machine was destroyed and historical configuration remained unchanged and stopped. The Linux runtime is 862,776 bytes and runs as UID 10001.

docs/results/public-admission-milestone-v1.json pins the successful result and build. docs/PUBLIC_ADMISSION_V1.md defines the wire and deployment boundary. Next: measure sustained admission progress under competing traffic with renewable, bounded budgets and idle-connection pressure. No claim of honest-newcomer fairness or sustained unrestricted service follows from this finite controlled-client run.

Renewable budgets: recovery, with a fairness counterexample

The working runtime now uses separate monotonic-clock submission/query budgets: 32 initial attempts, one replenished per second, capacity 32. This removes permanent process-lifetime admission refusal after a stopped burst while retaining finite work bounds. The native public process recovered after 31 malformed submissions, continued queries, released four idle connections at their deadlines, and admitted fresh claims without restarting. All 35 library tests and three process profiles pass; targeted Clippy passes.

The competing-arrival test deliberately retains a failure: an attacker always arriving first consumes every replenished slot. Renewable budgets alone provide no honest-sender fairness. The unchanged journal can still fill, and ongoing idle traffic can recapture workers. This candidate has not been deployed to Fly. Evidence is pinned in docs/results/renewable-budget-milestone-v1.json; the public admission guide distinguishes this candidate from the previous Fly image.

The renewable-budget candidate also passes all three constrained Linux process profiles. Its 863,160-byte binary and source are pinned in docs/results/renewable-admission-build-v1.json. A finite public TLS competition runner subsequently ran on Fly after exact-image approval. Results follow.

Renewable admission succeeds over public TLS

The finite no-invitation Fly run passed stopped-burst recovery and restart/refill. During eight seconds of competition, malformed requests consumed six replenished attempts and valid replay succeeded twice; the remaining 90 requests were budget refused. Both clients had zero transport errors or unavailable replies. A fresh claim succeeded after the competition stopped. This is observed progress in one run, not guaranteed fairness or fresh-newcomer availability during competition.

The first process routed 142 requests and retained five claims; restart/refill used three requests and preserved journal bytes and claim count. No overload or late replies occurred. The temporary machine was destroyed, leaving historical configuration unchanged and stopped. Evidence: docs/results/renewable-admission-fly-milestone-v1.json. The attacker-first starvation counterexample remains relevant. Next compare fresh valid competitors and ongoing idle pressure across repeated timing schedules.

Fresh claims reveal sustained admission failure

Six repeated timing schedules now use distinct signed claims rather than replay. Under malformed traffic, Fly retained 2 of 12 fresh claims and budget-refused 10. Under four reconnecting idle clients, it retained 1 of 12; 10 failed at transport and one was budget-refused. All three query probes under idle pressure failed at transport. The native run admitted none of the 24 claims during pressure.

Every distinct post-pressure recovery claim succeeded on both runs. Fly restart/ refill preserved journal bytes and the 10-claim count; the temporary machine was destroyed and historical configuration stayed unchanged and stopped. Thus the experiment completed, but admission availability under pressure failed. docs/results/admission-pressure-milestone-v1.json records that distinction.

Next compare bounded frame assembly ahead of scarce workers against this control, including idle CPU and memory costs; separately bound cheap malformed-envelope rejection before verification credits. Neither measure should be described as fairness against valid Sybil claims. Details: docs/ADMISSION_PRESSURE_V1.md.

Native candidate improves admission under measured pressure

Public frames now assemble in a bounded 16-slot stage before taking one of four response workers. Idle sockets allocate no body buffer until length/prefix checks pass; the original two-second deadline never renews. Constant-size envelope checks also reject short malformed submissions before consuming verification credit. Parsing, signatures and proofs remain budgeted. The wire format is unchanged.

The six-schedule native comparison retained 8/12 fresh claims under malformed traffic and 8/12 under four idle clients, with all six queries and recovery controls passing. The eight remaining refusals were budget limits. The prior native control retained none during pressure and lost idle-pressure queries. All 37 library tests, three process profiles and Clippy pass. Native two-second idle batches averaged 18.6 ms child CPU with zero clients and 27.0 ms with four.

This combined candidate has not been validated on Linux/Fly. Sixteen incomplete frames can still saturate its new stage; maximum requested assembly body storage is about 1.01 MiB, separate from worker/owner storage. Evidence is pinned in docs/results/staged-ingress-native-milestone-v1.json. Next validate the measured benefit and resource cost on Linux/public TLS, then test saturation of the new bound.

The staged candidate now passes all four constrained Linux process tests, including 16-slot saturation, excess-connection closure and query recovery after slots are released. The 870,008-byte binary runs as UID 10001. Small no-client Linux samples showed 20–30 ms CPU over two seconds for both profiles and about 20–24 KiB higher RSS for staged ingress; these are coarse idle measurements, not loaded benchmarks. docs/results/staged-ingress-build-v1.json pins the candidate. Its finite Fly runner completed after exact-image upload authorization.

Staged ingress validated on public TLS

After artifact approval, the candidate retained 20/24 fresh claims on Fly: 9/12 under malformed traffic and 11/12 under four idle clients. All six query probes and recovery controls succeeded. Four claims were budget-refused, with no fresh client transport errors. The previous Fly control retained 3/24 and lost idle query probes. This is one timing-dependent run of the combined candidate, not a general fairness result.

The first process accepted 173 connections, routed 149 and retained 27 claims. Its 24 failed sessions came from idle clients; overload and late counts were zero. Restart/refill preserved journal bytes and claim count. The temporary machine was destroyed, leaving historical configuration unchanged and stopped. Evidence: docs/results/staged-ingress-fly-milestone-v1.json. Next test structurally valid forged signatures, valid open-cost Sybils and loaded resource costs; the known 16-frame saturation and full-journal limits remain.

Verification pressure remains after cheap ingress rejection

The unchanged staged image was tested with structurally valid forged signatures and a pool of independent valid open-cost identities. Fly retained 3/12 fresh competitors under forged traffic and 1/12 under valid-Sybil traffic; native runs retained none during either mode. No forgery was admitted. Valid attacker traffic added 10 distinct journal records on Fly. All query/recovery probes succeeded.

Fly restart/refill preserved journal bytes and 21 claims; the temporary machine was destroyed with historical configuration unchanged and stopped. A separate native eight-record journal filled with valid attacker claims, then refused a ninth valid sender while preserving queries and replay. These are availability limits under one-bit test work, not signature or storage-integrity failures. Evidence: docs/results/crypto-admission-pressure-milestone-v1.json. Next separate exact-replay and unique forged-envelope workloads, then calibrate work costs and journal epoch pressure before choosing further mechanisms.

Work does not bind signature variants

The native repeated-versus-unique forgery experiment blocked all 12 fresh competing claims in each mode, while preserving queries and recovery. A release verifier experiment confirms that changing signature bytes leaves the current solved work ID unchanged. Increasing difficulty charges for the original claim but not for each forged variant. Valid checks cost about 39–41 microseconds in these native samples; forgery rejection about 19–20, excluding disk/network.

No signature bypass occurred and the runtime/wire stayed unchanged. Exact-envelope caching could help replayed bytes but does not address unique variants. Next test a bounded outer work commitment over the complete signed envelope before changing the protocol. Claim identity/idempotence must remain intact; valid-Sybil and journal saturation remain separate. See docs/ADMISSION_WORK_BINDING_V1.md and docs/results/admission-forgery-cost-milestone-v1.json.

Isolated signed-envelope work prototype

The experiment now commits work to the complete signed envelope and a receiver context, with domain separation and bounded hashing. It rejects signature/descriptor mutations and consumed or expired challenges; paid work never bypasses signature verification. Independently solved replica work preserves the original admission claim identity. Bounds, clock rollback, malformed envelopes and replica replay assertions pass; targeted Clippy passes.

Native verification averaged about 0.47 microseconds for an 894-byte envelope and 21 microseconds for maximum-size bytes. Those costs exclude network, issuance, disk and subsequent signatures. No production wire/runtime change or Fly run is claimed. Next integrate a bounded challenge/frame state machine without tying up verification workers. docs/ENVELOPE_WORK_PROTOTYPE_V1.md states the assumptions; docs/results/envelope-work-prototype-milestone-v1.json pins the evidence.

Bounded challenge/frame state machine

The isolated model now connects fresh OS-random challenges, incremental bounded frames and a two-job ready queue. It permits 16 pending challenges and 1,000 issued challenges, with two-second absolute deadlines and no renewal from partial input. Fragmentation, expiry/clock rollback, disconnect, queue overflow, allocation caps and single-use checks pass, as does targeted Clippy.

Replayed work and two signature-mutation sequences caused zero signature attempts; 12 freshly paid forged envelopes reached verification and were all rejected. Four idle clients leave room for honest work; sixteen block new challenges. A full ready queue also refuses completed work. These counterexamples remain explicit. This is a logical-time state-machine experiment, not real transport or a fairness result. Next connect an isolated socket harness and measure real deadline/resource behavior. Evidence: docs/results/challenge-state-milestone-v1.json; details: docs/CHALLENGE_STATE_V1.md. Production/Fly profiles are unchanged.

Isolated challenge sockets

The experimental outer-work gate now runs over loopback TCP with bounded nonblocking reads/writes, 16 total connections, two queued jobs and one active verifier. Real solve time counts against the original two-second deadline. Tests cover fragmented input, partial-frame expiry, idle saturation, disconnect recovery and four concurrent clients submitting 32 paid signature forgeries. Honest replay requests recover afterward; no invalid signature is accepted.

A paid proof can still be refused when the ready queue fills. This is expected bounded-resource behavior, not an entitlement to verification. The initial test assumed otherwise; its failed log is preserved and stage accounting corrected. Evidence is pinned in challenge-socket-milestone-v1.json. Combined client/server CPU and RSS measurements are only a small fixture baseline. Receiver-only sustained load, actual write backpressure and fresh-claim competition remain the next gate. The public wire profile and deployed runtime have not changed.

Separate receiver resource measurements

A separate-process loopback experiment now tests fresh claims under paced attack. All 24 honest claims succeeded in the baseline and under either 800 unpaid mutations or 800 freshly paid signature forgeries. Unpaid mutations reached no signature verification; paid forgeries reached it 796 times and all failed, with four queue refusals. Both fresh recovery requests succeeded in each workload, including after 16 clients left their challenges unread until expiry.

Receiver CPU was 0.09/0.11/0.18 seconds across the respective ten-second process lifetimes; peak RSS was approximately 2.1 MB. These exclude client work generation but include idle polling and startup. This short, paced native fixture establishes neither public throughput nor saturation resistance. Actual write backpressure, unpaced saturation, large valid envelopes and difficulty calibration remain open. Evidence: challenge-load-milestone-v1.json. Production and Fly remain unchanged.

Unpaced saturation counterexample

The follow-up tested 16 unpaced paid-forgery clients, 800 attack attempts, 24 fresh honest claims, and 8/12/16-bit work with small or 4,096-dimension Beacons. Honest acceptance fell to 8/8/2 of 24 for small envelopes and 11/10/4 for large envelopes. All forgeries were rejected, and both recovery checks passed in every case.

The gate prevents unpaid signature amplification; it does not make verification queues fair. Increasing difficulty alone did not restore honest access in these single samples. Queue and connection capacity remain capturable by paid clients. The current scheduler is now a retained saturation control. Next isolate queue competition from challenge occupancy and compare bounded scheduling policies over repeated runs before selecting a public difficulty or integrating the wire change. Evidence: challenge-saturation-milestone-v1.json. Production and Fly are unchanged.

Scheduling comparison: queue relief moves the bottleneck

Eighteen native trials compared fixed visitation, rotating visitation and rotating visitation with reads paused when the two-job queue fills. All kept 16 connections and one active verifier. Under four paid attack clients, pausing preserved 24/24 honest claims in all three runs, versus 11/11/16 for the fixed control. Under sixteen attackers, pausing preserved only 5/8/6; connection refusals replaced queue refusals. Rotation alone did not consistently improve progress.

All forgeries were rejected and all fresh recovery checks passed. Read pausing is useful queue flow control, but this experiment does not establish independent-user fairness or public availability. Next measure time and occupancy at each stage and compare bounded verifier dispatch separately from connection admission. Evidence: challenge-scheduling-milestone-v1.json. Production and Fly remain unchanged.

Dispatch timing: less queue wait does not establish fairness

Twelve trials compared one versus two sequential verifications per polling iteration with the same 16 connections, two queued jobs and one active verifier. All four-client cases preserved 24/24 honest claims. Under sixteen clients, one-job dispatch preserved 8/9/5 and two-job dispatch 5/8/6. Every forgery was rejected and fresh recovery passed.

Two-job dispatch substantially reduced measured queue residence, but did not consistently improve honest access. Stage occupancy is sampled connection time, not CPU time; receiver-only resource logs remain separate. Next compare matched arrival timing and large envelopes, including event-loop delay, before promoting a scheduler change. Evidence: challenge-dispatch-milestone-v1.json. Production and Fly remain unchanged.

Transport feasibility milestone and integration decision

Twenty-four scheduled-arrival trials tested small, large and maximum-length descriptor JSON with one/two-job dispatch. All forgeries were rejected; every fresh recovery check passed. No connection expired in these workloads. The maximum-JSON submission was 65,754 bytes with its open-cost claim. Peak receiver RSS across the trials was approximately 6.4 MB.

The faster schedule missed some arrival slots. A slower confirmation gave both dispatch variants 66/72 honest successes, providing no consistent admission benefit for promoting two-job dispatch. Keep the existing one-job bound as the integration control and end polling-order tuning as a proposed fairness solution.

The next deliverable is an opt-in, versioned submission cost gate: wire vectors, a bounded adapter, and TLS/durable-ledger/restart conformance before a finite Fly comparison. It prevents unpaid signature amplification; it does not promise fair access, retention or attention. It is separate from Conserved Reach. Current public bytes and deployed runtime remain unchanged. Full decision: docs/ENVELOPE_WORK_TRANSPORT_DECISION_V1.md. Evidence: challenge-transport-feasibility-milestone-v1.json.

Work adapter staging before image approval (historical)

The opt-in serve-work-tls-proxy listener implements SKADWRK1 with fresh receiver challenges, exact request-body work, bounded nonblocking challenge writes and the original absolute deadline. Submissions and queries use the new handshake; their existing bodies, replies, work budgets, ledger identity and retention policy remain unchanged. Legacy SKADPUB1 stays available as the control.

A Python-generated hash/proof vector agrees with Rust. Native and Linux tests cover maximum sponsored submissions, queries and durable restart. Independent Python checks cover unpaid mutations, paid forgeries, wrong versions, cross-connection replay, oversized headers, partial-frame expiry and fresh recovery. Deterministic writer tests exercise partial output, WouldBlock, Interrupted and closure.

The final native cohort routed 25 requests and refused 25 sessions before routing; seven claims were retained, with no late owner completions. All five Linux lifecycle tests passed serially; an earlier concurrent legacy test hit an interrupted syscall under amd64 emulation, and that log is preserved. The non-root runtime binary is 878,056 bytes, 8,048 bytes larger than the previous control.

No Fly deployment occurred: automatic approval review rejected export of the new image because existing approvals cover other hashes. The tested image and pending control/work/restart runner are pinned in work-adapter-ready-milestone-v1.json. Wire details: docs/DISCOVERY_REQUEST_WORK_WIRE_V1.md. Public TLS verification of this new adapter remains pending the specific image upload approval.

Work adapter Fly milestone completed

After approval of the exact image, the finite Fly comparison passed with verified public TLS and no invitation. The work profile refused all 20 unpaid mutations before routing and rejected all 16 paid signature forgeries. Honest requests during pressure succeeded 4/4 versus 3/4 in the legacy control; both recovered. The phases shared fixtures and a journal, so this is functional validation with replay, not an independent fresh-admission fairness comparison.

Work-profile restart preserved seven durable claims and exact journal bytes while refilling the initially empty volatile index. The temporary 256 MB machine was destroyed. Historical machines remain stopped and unchanged, with no services. The approved image required a refreshed registry login before upload; no image contents changed. Evidence: work-adapter-fly-milestone-v1.json.

The cost gate is now implemented and tested over Fly. It remains opt-in and separate from Conserved Reach, retention and attention. Next use independent state and fresh fixtures for sustained paid-demand comparison, then return to journal/epoch and provenance/newcomer retention experiments. No public service was left running.

Sustained independent-state comparison completed

The active roadmap is consolidated and published as the Roadmap page. Eight cases used independent empty ledgers and fresh fixtures with thresholds declared before execution. Clean native and Fly baselines admitted 20/20 honest claims. Under 400 paid forgeries, native legacy/work profiles admitted 6/20 and 7/20; Fly admitted 17/20 and 16/20. Every scheduled query and fresh recovery passed, no forgery was accepted, and durable counts reconciled with successful honest replies.

Fly met the declared 16/20 progress target; native did not. TLS clients offered the attack more slowly (last starts around 26–30 seconds versus a 20-second target), so the environments are not interchangeable load measurements. Preserve the native counterexample; do not promote a fairness claim. All temporary Fly resources were removed and historical machines remain stopped and unchanged.

Next: useful retention under attack, with distinct full-pipeline and preverified candidate arms so conditional retrieval quality cannot hide admission losses. Evidence: sustained-admission-milestone-v1.json.

Real-vector retention baseline completed

Six fresh-ledger loopback cases separate full admission from retention conditional on valid claims. All live cases missed preregistered utility targets. Attack-first conditional retention lost every newcomer positive; correlated honest sponsorship also lost useful positives under the one-entry issuer cap. Honest-first independent sponsorship was the only conditional case to pass all utility thresholds.

All bounded-state/accounting checks passed, and 144 live query rankings agreed with the evaluator. This does not establish useful discovery under hostile ordering. The corpus labels remain unreviewed. No runtime, tree, or Fly deployment changed. Next compare bounded replacement and issuer caps while preserving the failed control, then test epoch and journal bounds. See RETENTION_BASELINE_RESULTS_V1.md and retention-baseline-native-v1/summary.json for results and reproduction.

Bounded replacement and issuer-cap comparison completed

The 792-case offline comparison removed arrival-order dependence with fixed priority replacement but failed newcomer utility targets. Mean newcomer positive availability was 32–36%. Increasing the issuer cap from one to three restored honest sponsored members while also increasing captured-sponsor occupancy from one to three. All capacity, replay and batch-oracle checks passed. No recorded-admissions priority case passed the utility target; this arm reuses prior admissions and is not a new live test. Runtime and Fly images remain unchanged.

Neither change is promoted. Next exercise journal limits and epoch transitions; further honest-progress claims need an explicit scarce-resource or local-evidence assumption. See RETENTION_REPLACEMENT_RESULTS_V1.md and retention-replacement-v1/summary.json for the evidence.

Journal capacity and epoch retirement checked

The work-gated loopback server admitted eight valid same-sponsor claims but retained only one; seven unretained admissions still consumed journal capacity. A ninth valid claim was refused. Replay/query survived full capacity and restart without journal growth. Four native ledger epochs preserved accounting after descriptor expiry and retired old records only on explicit rollover. Integration and fsync fault tests passed; initial sandbox socket denials are retained with the successful rerun.

This is bounded accounting with an availability limit, not automatic epoch recovery. The server has no rollover command or scheduler. Next add a small explicit offline operator transition and test the process lifecycle before Fly. Runtime remains unchanged. See JOURNAL_EPOCH_RESULTS_V1.md for evidence and limitations.

Explicit operator epoch command tested

advance-epoch STATE OLD_POLICY NEXT_POLICY --experimental now exposes atomic rollover using the existing ledger lock and receiver wall time. The process test retired a full old ledger, admitted a fresh next-epoch claim through work-gated transport, and replayed it after restart without journal growth. Six refusal checks, the existing transport lifecycles and fsync fault tests passed. No scheduler or wire change was introduced. The native release is 718,416 bytes (+16,512).

Next validate the Linux image and a finite Fly maintenance/restart cycle on a dedicated ledger. No new image is deployed yet. See OPERATOR_ROLLOVER_V1.md and operator-rollover-v1/audit.json. Admission and retention utility failures remain open.

Operator rollover Linux image validated

All ten Linux tests passed. The runtime uses UID 10001 and an 889,432-byte binary. A finite Fly rollover/restart harness and signed full-ledger fixture generator are prepared. Exact image and binary hashes are in operator-rollover-v1/linux-build.json. Automatic approval review blocked this new image's registry upload because earlier approvals covered other digests. Fly execution remains pending explicit approval; no image upload or new machine creation occurred. See OPERATOR_ROLLOVER_V1.md.

Operator rollover Fly milestone completed

The approved image passed a finite Fly TLS test: eight old-epoch claims retired, fresh next-epoch admission/query succeeded, and replay after server restart left the journal unchanged. Both four-request rounds reported one claim, one retained descriptor and zero late completions. The temporary shared-CPU/256 MiB machine was destroyed; historical machines remained unchanged and stopped, with no service left running. Exact approval was supplied after the earlier automatic upload rejection.

See OPERATOR_ROLLOVER_FLY_V1.md and operator-rollover-fly-v1/summary.json. This covers normal process restart, not machine/volume failure or automatic epoch scheduling. Return to explicit honest-progress resource assumptions and semantic label review preparation; the earlier discovery utility failures remain open.

Honest-progress assumptions and semantic review prepared

The informative resource contract now separates bounded operation from honest progress. Permissionless identities do not prove newcomer status; fixed-population sampling cannot meet the earlier 80% target when 94 entries compete for 32 slots. No protocol or policy change follows merely from those observations.

Two unfilled review packets cover all 1,152 query/distinct-text pairs, expanding to 24×72 original Beacon pairs. They omit labels, rankings and timestamps; identical texts share semantic judgments while expiry stays separate. Validator tests passed. Actual independent review is pending, and no reviewers were contacted. Public source material cannot be described as a blind holdout. See DISCOVERY_PROGRESS_ASSUMPTIONS_V1.md and SEMANTIC_REVIEW_PLAN_V1.md.

Next preregister a resource-envelope sweep using frozen controls. Revised semantic scores must wait for reviewed labels; bounds and stage accounting can be tested independently. Runtime, corpus and prior results remain unchanged.

Resource envelope and paced controls completed

Seventy-two preregistered cases passed stage-accounting and frozen-policy checks: 54 native signed-ledger cases and 18 live bursts. Larger journals did not prevent attack-first newcomer retention loss. All clean bursts exceeded the initial 32-attempt allowance, so two additional paced controls isolated that effect.

At one honest offer per second, all 44 were admitted and retained. Adding one valid hostile offer immediately before each honest offer reduced honest admission to 31/44 and newcomer retention to 15/22. All thirteen refusals were attempt-budget responses. Journals, query membership and timing checks passed; no runtime or Fly change was made. This establishes bounded service, not fair allocation.

See RESOURCE_ENVELOPE_RESULTS_V1.md and PACED_RESOURCE_RESULTS_V1.md. Independent semantic judgments remain pending with two reviewers the user will arrange. Ready-to-send archives are prepared; existing public AI-authored labels are not a substitute. Further resource/multi-node hypotheses require explicit adversarial-budget, local-evidence or independence assumptions.

User-requested AI labeling and semantic reference completed

The assistant labeled all 1,152 text pairs (25 relevant, 1,122 unrelated, five unclear) and froze them before new ranking inspection. This is one nonblind AI-authored review, not independent human validation. Practice entries were excluded. All 48 native/reference rankings agreed. Under strict labels, a dev-selected 0.41 cutoff yielded eval Recall@5 of 87.5% with two of four no-match queries still returning candidates; without a cutoff, recall was 100% but all four returned candidates. Dev recall fell from 75% to 50% with the cutoff. No runtime cutoff is promoted.

See AI_SEMANTIC_EVALUATION_RESULTS_V1.md. The user need not complete the human packets for this exploratory run. Further calibration needs newly authored examples and dedicated dev no-match queries; independent validation remains future work.

New semantic constraint challenge completed

New frozen AI-authored text covers 24 queries, 32 candidates and 768 labels, with four semantic no-match queries per split. The pinned model ran offline; all 24 native full-pool rankings matched the separate evaluator. The dev-selected 0.55 cutoff retained eight of eight eval matches but returned candidates for all four eval no-match queries. Strong lexical/semantic similarity did not establish that mandatory capabilities were satisfied. No cutoff is promoted.

See SEMANTIC_CHALLENGE_RESULTS_V1.md. Next test a narrow recipient-local requirement contract with unknown/unsupported outcomes and abstention. This remains outside admission rights and discovery wire rules; no mandatory model or generic capability platform is introduced. Same-assistant synthetic authorship remains an assurance limit.

Recipient-local statement compatibility tested

A compact native experiment checks eight local boolean requirement slots after retrieval. Four tests include exhaustive mask checks, six malformed/oversized CLI cases reject, and sixteen signed-retrieval/mutation cases reproduce byte-for-byte on both Macs. The prerecorded offer is incompatible with offline live captions under supplied facts; stale, misbound or missing assessments remain unknown.

A fabricated all-positive statement still appears stated-compatible. Every result explicitly remains unverified and grants no attention. There is no automatic text extraction, new admission rule or wire extension. See RECIPIENT_REQUIREMENTS_RESULTS_V1.md. Next return to heterogeneous receiver policies and correlated attacker placement with preregistered resource assumptions.

Multi-receiver counterfactual completed

The preregistered 512-case offline comparison measured one versus three receivers, shared versus distinct retention keys, and broadcast versus partitioned attacks. All resource/accounting checks passed. Identical broadcast receivers added no utility. Distinct choices improved retained-union availability but failed combined hostile-first utility targets; final top-five ranking still lost useful candidates.

Three receivers permit up to 192 retained copies and 15 candidate references per query. Partitioned attacks impose a reach restriction and lower hostile submission spend; no runtime mechanism enforces that assumption. Admission is assumed successful throughout this counterfactual. See MULTI_RECEIVER_RESULTS_V1.md. No native runtime, wire or Fly policy is promoted; next separate availability from ranking losses on the frozen constraint challenge with explicit, unverified local requirements.

Frozen constraint stage audit completed

The 2,304-configuration audit separates retention, top-five truncation and local compatibility losses. Native rankings match the frozen challenge; 768 native requirement checks and reconstructed stage accounting pass. All pre-filter positive losses come from the artificial retention subsets. Retrieving ten instead of five candidates recovers nothing on this clean corpus.

With all offers retained, fifteen of sixteen labeled positives remain stated compatible; the accessibility-audit offer stays unknown. All eight no-match queries lose their compatible candidates under manually supplied facts. This is neither automatic extraction nor verified capability truth; no attention is authorized. See DISCOVERY_STAGE_RESULTS_V1.md. Next test hostile content and false capability statements under declared budgets. No runtime or Fly policy changes follow.

Hostile-content and false-statement counterexamples measured

The 288-case native experiment verifies separately signed injected Beacons against the frozen challenge. Five query-mimicking identities fill every top-five window. Ten candidates recover the original positives with five mimics, but twenty mimics fill the larger window as well. All descriptors are assumed admitted and retained; this is not a measured bypass of live admission policy.

Returned attackers stay unknown with missing facts and appear stated compatible with fabricated matching facts. All outputs remain unverified and authorize no attention. Signatures authenticate authorship, not service truth. See HOSTILE_CONTENT_RESULTS_V1.md. Next distinguish content duplication from provenance diversity under declared admission budgets. Runtime, candidate limits and Fly configuration remain unchanged.

Content duplication and supplied provenance compared

The 864 native configurations and 4,320 bounded selection cases separate modeled admission loss from candidate selection. Removing duplicates from an already saturated top five recovers nothing. Scanning further recovers originals from exact copies, while unique text suffixes defeat exact-text grouping. A supplied shared attacker group handles variants, but distinct keys alone reveal no such group.

At a 32-offer attacker-first admission budget, ten of sixteen original positives never enter. No downstream selector recovers those losses. This is an explicit admission-prefix counterfactual, not the durable ledger or a live proof-cost test. See CONTENT_PROVENANCE_RESULTS_V1.md. Next return to receiver-local provenance and separately budgeted exploration with declared capture assumptions. Runtime and Fly configuration remain unchanged.

Local provenance and exploration accounting measured

All 108 cases pass native signature/provenance checks, capacity refusals, journal accounting and replay checks. Splitting known-provenance and exploration accounting preserves some established senders but fails newcomer progress when exploration fills. A captured known issuer also fills the protected lane; a source cap limits that capture while excluding honest senders sharing an issuer. No tested arm passes the progress target under nonzero attacker-first pressure.

For the narrow first-arrival model, 32 exploration slots and 22 honest newcomers need at most fourteen hostile exploration claims to retain eighteen newcomers. The proof rules do not establish that bound, and shared ingress adds another service dependency. See LOCAL_PROVENANCE_BUDGET_RESULTS_V1.md. The proposed public service contract distinguishes best-effort permissionless exploration from a newcomer guarantee requiring an additional enforceable assumption. The deployment objective is pending; no runtime or Fly policy changed.

Best-effort public service model accepted

On 7 September 2026 the user accepted best-effort permissionless exploration as the global service model, with stronger guarantees confined to explicit conditional profiles. Core adds C-SERVICE-01 and records the revision. Useful discovery under a published hostile workload remains a readiness gate; previous failures are not waived.

A fresh reference recheck passes twelve primitive/preimage vectors, fourteen signed envelope vectors and six local transition traces. The finite model reproduces 122 states, 462 transitions, 900 replica-state pairs and its partition counterexample. These remain narrow subsets, not full Core conformance. The external implementer handoff is prepared; no independent implementation or review is claimed. Public service and handoff pages are available in the generated site. Runtime and Fly configuration remain unchanged.

Cross-language authentication comparison completed

A same-author Python diagnostic adapter passes the 26 existing primitive/claim vectors and agrees with Rust across 6,108 additional cases. This includes weak Ed25519 key/signature acceptances, including an identity-beneficiary open-cost envelope with authorization still unchecked. Agreement does not settle the profile's existing canonical-point and key-class acceptance question.

See CROSS_LANGUAGE_AUTH_V1.md. The next gate is an explicit acceptance rule with cross-backend tests before promotion. This is not independent-team review, full Core conformance or a demonstrated bypass of live admission. No runtime or Fly change was made; Python remains preparation/conformance tooling only.

Strict authentication candidate tested

The isolated canonical, non-identity prime-subgroup A/R rule passes all 26 existing vectors and rejects the five earlier weak-key acceptances. Weak issuer and beneficiary envelopes are rejected at the corresponding authentication stage; seven point-class probes include a mixed-order rejection. Point validation uses libsodium 1.0.22 and is not an independent arithmetic oracle.

See STRICT_AUTH_RESULTS_V1.md. The next adoption gate is a measured native implementation plus pinned acceptance-policy identity and restored-state tests. Legacy runtime, wire version and Fly configuration remain unchanged.

Native strict admission profile — 7 September 2026

The opt-in native profile now checks issuer, beneficiary, descriptor and conflict signatures and pins acceptance policy across journal reopen and epoch rollover. All 6,108 frozen strict differential cases agree. The arm64 runtime adds 16,560 bytes; the small signature benchmark costs about 3.1 times legacy verification. See NATIVE_STRICT_AUTH_V1.md. Next measure bounded-load behavior and recovery with this profile before preparing a new Fly image; no deployment occurred here.

Strict native workload and restart — 7 September 2026

All four finite strict-policy cases passed safety/accounting and post-load recovery. Clean cases admitted 20/20 honest requests; hostile cases admitted 7/20 without request work and 9/20 with it, missing the unchanged 16/20 target. Separate epoch rollover and process restart preserved idempotent journal accounting. See STRICT_LOAD_RESULTS_V1.md. Linux artifact preparation is blocked by the local Docker daemon not responding; no new Fly image was uploaded.

Strict Fly milestone

The approved strict-auth artifact passed all four finite Fly safety/accounting checks and both restart/epoch recovery phases. Clean cases admitted 20/20; both hostile cases admitted 2/20, missing the unchanged 16/20 target. All temporary machines were destroyed and the historical stopped machine was unchanged. See STRICT_AUTH_FLY_V1.md. Next close the strict transition-conformance coverage gap; no hostile-progress guarantee or larger-scale readiness follows from these results.

Strict transition conformance subset

Eight traces and 46 steps now exercise the strict local admission policy, including weak signatures, replay, conflict quarantine and policy-pinned journal reopen. All pass; the six legacy traces also still pass. See conformance/STRICT_TRANSITIONS_V1.md. This is same-author reference evidence; the Python adapter has no transition implementation. Portable epoch-rollover coverage and independent implementation remain next, with hostile public progress targets still failed.

Strict epoch conformance subset

Four portable traces (28 steps) now cover successful rollover, invalid rollover without journal mutation, old-epoch reopen refusal and retirement of conflict state. All pass alongside eight strict and six legacy transition traces; fixture regeneration is deterministic and Clippy passes. See conformance/STRICT_EPOCHS_V1.md. The next assurance gate is independent implementation; this same-author evidence does not close that gap or the failed hostile Fly progress targets.

Standalone implementer package

A deterministic 24-file archive now packages the strict contracts, fixtures, runner and attribution template without reference implementations. All four suites pass from a clean extraction against the existing reference; an altered fixture is detected by the manifest. See IMPLEMENTER_PACKAGE_V1.md. This makes the external exercise actionable but does not supply an independent author.