research(nightly): signed-receipt batch-fill latency — bounded hybrid scheduling (ADR-341)

[ruvnet]

Summary

• The 2026-08-31 nightly run (ADR-340) measured the CPU-only cost of Ed25519 batch-signing MerkleReceipt roots and explicitly left wall-clock batch-fill latency unmeasured — its own "Next Research" item Implement Ruvector high-performance vector database #1. This PR implements that direct follow-up.
• Adds BatchFillPolicy/BatchScheduler (crates/ruvector-retrieval-receipt/src/batch_fill.rs): a pure, clock-free scheduling module deciding when a batch of pending receipt roots closes — either fixed-size-only, or a hybrid policy that also closes on a fill-timeout.
• Adds a discrete-event simulation binary (bin/batch_latency.rs) that drives real Poisson/bursty query-arrival timelines through the real production search + receipt-generation path, and performs real Issuer::sign_root/BatchAnchor signing (timed with Instant, not estimated) whenever a batch closes, to measure genuine end-to-end receipt-availability latency.
• No changes to any existing file's logic (signing.rs, receipt.rs, index.rs untouched); all 23 pre-existing tests plus 7 new tests (30 total) pass.

Hypothesis & Result

Fixed-size-only batching (B=32) has unbounded tail latency under light load — measured p99 of 756ms, reproduced identically across 3 runs, at a modest 50 queries/second arrival rate. A hybrid policy (B=32, 50ms fill-timeout) bounds p99 latency to 50.03ms at that same load, while preserving full amortization at target load (1000 q/s) where the timeout essentially never fires.

ACCEPTANCE RESULT: ACCEPT — all 4 pre-registered acceptance thresholds passed in all 3 independent runs (100% batch verification; hybrid p99 ≤ 70ms bound at all 3 regimes; fixed-size-only p99 > 2× hybrid's at light load; hybrid amortized signing cost within 2× of fixed-size-only's at target load).

regime	policy	p99 latency	mean batch size
target (1000 q/s)	fixed-size-only	36.80ms	31.9
target (1000 q/s)	hybrid (50ms)	36.81ms	31.9
light (50 q/s)	fixed-size-only	756.13ms	31.9
light (50 q/s)	hybrid (50ms)	50.03ms	3.5
bursty (on/off)	fixed-size-only	415.69ms	31.9
bursty (on/off)	hybrid (50ms)	49.30ms	29.4

Benchmark command

cargo run --release -p ruvector-retrieval-receipt --bin batch_latency -- 2000 64 10 3000

Raw output for 3 independent runs: docs/research/nightly/2026-09-01-signed-receipt-batch-fill-latency/raw-runs.txt.

Darwin

Not executed this cycle. max_wait_ns = 50ms was chosen analytically (between the target- and light-load fill times), not evolved — noted as a legitimate future Darwin candidate in the ADR.

Flywheel / evidence retention

The nightly report's own "Next Research" section carries forward 5 concrete follow-ups (real-traffic re-derivation of the timeout, signer-throughput breakdown point, adaptive batch-size policy, BLS aggregate signatures, WASM measurement) for a future run to pick up, continuing the same evidence chain this run started from.

Security review

• No new cryptographic primitive or dependency — batch_fill contains no cryptography; the simulation reuses ADR-340's existing Issuer/BatchAnchor/verify_root API unmodified.
• Every closed batch's signature and every member's inclusion proof was independently verified in every run (100%).
• Experimental, not wired into any default query path — matches ADR-304/ADR-340's posture.

Main limitations

• Assumes a single serialized signer with no queueing delay for the sign operation itself — valid at all tested regimes (real signing cost is 3+ orders of magnitude below every tested fill window) but untested at higher arrival rates.
• Synthetic Poisson/bursty traffic, not measured production traffic; max_wait_ns = 50ms demonstrates the mechanism, it is not a recommended default.
• Discrete-event simulation (real crypto costs injected into simulated arrival timing), explicitly not a live real-time deployment test — stated in Limitations, not glossed over.

Production recommendation

Not promoted to any default path. Production adoption of BatchFillPolicy::hybrid requires re-deriving max_wait_ns from real traffic traces and validating the single-signer assumption at the deployment's actual peak rate — both listed as open Rejection Criteria in ADR-341.

Docs in this PR

• ADR: docs/adr/ADR-341-signed-receipt-batch-fill-latency-simulation.md (+ regenerated docs/adr/INDEX.md)
• Nightly research report: docs/research/nightly/2026-09-01-signed-receipt-batch-fill-latency/README.md
• Public gist write-up: docs/research/nightly/2026-09-01-signed-receipt-batch-fill-latency/gist.md

Test plan

• cargo build --release -p ruvector-retrieval-receipt
• cargo test --release -p ruvector-retrieval-receipt (30/30 passing, 7 new)
• cargo clippy --release -p ruvector-retrieval-receipt --all-targets -- -D warnings (clean)
• cargo fmt -p ruvector-retrieval-receipt -- --check (clean)
• cargo run --release -p ruvector-retrieval-receipt --bin batch_latency × 3 (reproducible ACCEPT)
• cargo run --release -p ruvector-retrieval-receipt --bin benchmark (ADR-304/ADR-340 regression check — unchanged, ACCEPT)

Co-Authored-By: claude-flow ruv@ruv.net
Claude-Session: https://claude.ai/code/session_01DYBHRF7WVzMyTRpe9Fo4qd

---

Generated by Claude Code