[ruvnet]

Summary

Nightly research run (2026-10-11) that implements the specific gap the previous nightly (ADR-347) deferred: ruvector-agent-memory's SignedWitnessSink::SigningStrategy::BatchTail has no bound on how long a partially-filled signing span can stay unauthenticated if arrivals stop. ADR-347's own "Alternatives Considered" ("Wall-clock BatchTail fill timeout. Deferred.") and Open Question 1 named this directly.

• Adds SigningStrategy::BatchTailTimeout { batch_size, max_wait_ns }, which closes a pending span at batch_size records or after max_wait_ns since the oldest unsealed record, whichever comes first — porting the hybrid count-or-timeout policy ruvector-retrieval-receipt::batch_fill already validated (ADR-343), adapted natively to SignedWitnessSink rather than added as a new dependency.
• Purely additive: PerRecord/BatchTail are byte-for-byte unchanged; no new Cargo dependency, no new crate.
• The adversarial-review pass caught a real ordering bug before any benchmark ran (checking the timeout after merging a new arrival into a stale span, instead of before) — fixed and covered by a dedicated regression test plus a randomized property test.

Architecture

TransactionalLedger.add/accept
        -> WitnessSink::emit_batch
              -> SignedWitnessSink::emit_batch_at(records, now_ns)
                    -> [BatchTailTimeout] check_timeout_at(now_ns)  (seal stale span FIRST)
                    -> merge into pending span, count-close if full
        -> inner: MemoryWitnessLog
periodic tick (ruFlo workflow / host scheduler) -> check_timeout()

Files changed

• crates/ruvector-agent-memory/src/witness_signing.rs — core implementation (new strategy variant, emit_batch_at/check_timeout_at/check_timeout/next_timeout_deadline_ns/strategy, WitnessSignerError::ZeroMaxWait).
• crates/ruvector-agent-memory/src/witness_signing_tests.rs — 10 new tests (45 → 55 in the crate), including a randomized bounded-latency property test.
• crates/ruvector-agent-memory/examples/witness_signing_timeout_bench.rs — new dedicated benchmark (dense-burst overhead + sparse-arrival bounded-latency, both real wall-clock measurements).
• docs/adr/ADR-348-bounded-witness-batch-fill-timeout.md + docs/adr/INDEX.md — design record.
• docs/research/nightly/2026-10-11-bounded-witness-batch-timeout/{README.md,gist.md} — full nightly report (capability discovery, benchmark evidence, rejected alternatives, Darwin-style lineage, applications, falsification criteria).

Benchmark command

cargo run --release -p ruvector-agent-memory --example witness_signing_timeout_bench

Real benchmark results (3 runs)

Dense-burst overhead (20,000 add+accept pairs, batch_size=64, no idle gaps; threshold ±10%):

Run	BatchTail{64} mean	BatchTailTimeout{64,5ms} mean	Overhead	Signatures
1	3.387µs	3.340µs	-1.39%	625 / 625
2	3.448µs	3.441µs	-0.19%	625 / 625
3	3.635µs	3.377µs	-7.11%	625 / 625

Sparse-arrival worst-case latency (20-record burst, real 15ms idle gap, max_wait_ns=5ms, 1ms poll; bound = 6ms):

Run	BatchTail pending after gap	BatchTailTimeout sealed after
1	20 (unchanged, no timeout concept)	5.585ms
2	20 (unchanged, no timeout concept)	5.527ms
3	20 (unchanged, no timeout concept)	5.653ms

Every run printed an explicit Acceptance: ACCEPT from the benchmark binary itself.

Full regression: cargo test -p ruvector-agent-memory --lib → 55/55 passing. cargo clippy -p ruvector-agent-memory --all-targets -- -D warnings → clean. cargo fmt -p ruvector-agent-memory -- --check → clean.

Acceptance result

ACCEPT

Darwin / Flywheel / MetaHarness

Checked before assuming availability: npx metaharness --help resolves (a scaffolding generator, not a runtime for this repo), npx ruvector harness doctor/darwin/flywheel does not resolve an executable in this checkout. Documented honestly in the nightly README rather than fabricating tool output; this run used a manual equivalent (explicit hypothesis, real baseline, bounded one-candidate evolution, pre-declared fitness gates, retained rejected alternatives in the ADR).

Security review

No new cryptographic surface — a timeout-forced seal produces the same SignPurpose::BatchTail-tagged span a count-triggered seal would, indistinguishable to a verifier. Wall clock is Instant-based (monotonic, immune to system-clock adjustment). "No witness, no mutation" ordering preserved. Full detail in ADR-348's Security/Governance/Failure Modes sections.

Main limitations

• The bound is caller-enforced: a periodic check_timeout tick must actually be wired up in production, or BatchTailTimeout silently degrades to BatchTail's original behavior. This is documented as an operational obligation, not hidden.
• No durable (non-MemoryWitnessLog) sink, multi-issuer, or WASM/edge measurement — explicitly out of scope, listed as open items.
• Benchmark figures are from one shared, containerized workstation (3 repetitions); treat as indicative.

Production recommendation

Land as-is (additive, opt-in, zero behavior change for existing callers). Before relying on the bound in a real deployment: pick a max_wait_ns default, build the described ruFlo periodic-tick workflow, and extend verification to a durable sink.

---

Generated by Claude Code

[ruvnet]

CI: npm audit (npm/ workspace) is failing, but not because of this PR

The supply-chain workflow's npm audit (npm/ workspace) job (run) fails on this PR's head commit with 9 vulnerabilities (5 moderate, 3 high, 1 critical) in transitive node_modules dependencies: @modelcontextprotocol/sdk, axios, compression, fast-copy, ip-address, proxy-addr, and qs (via body-parser/express).

This PR's diff is Rust (crates/ruvector-agent-memory) and Markdown docs only — it touches no package.json, lockfile, or node_modules content. I confirmed the same job fails identically on main itself at its current head (6191f8f66cdb132cbb676fa94571f87c1e8de308, run), with the same 9 advisories — so this is a pre-existing finding on the base branch, not something introduced here.

I checked for an existing fix PR to port in (there have been several past PRs fixing npm audit findings, e.g. #739, #682, #474, #346, all closed/merged already) but none currently open addresses this specific set of advisories, so there's nothing to port. Resolving it would mean running npm audit fix / bumping dependency versions across the npm/ workspace — out of scope for this Rust-focused research PR, and I'd rather not widen this diff with an unrelated dependency upgrade.

Not re-running the job: this is a deterministic audit finding (reproducible on main), not a flake, so a re-run wouldn't change the result. Leaving this as a known, pre-existing, unrelated failure unless maintainers want it addressed separately.

---

Generated by Claude Code

[ruvnet]

CI: Tests (core-and-rest) is failing, also not caused by this PR

Tests (core-and-rest) fails at the link step (run) building ruvector-typesafe-train's smoke_train test binary: rust-lld: error: undefined symbol: __isoc23_strtol / __isoc23_strtoull / __isoc23_strtoll plus a libstdc++ _M_replace_cold symbol, linking the prebuilt libort_sys (ONNX Runtime) archive. This is a glibc/libstdc++ ABI mismatch between the ONNX Runtime binary and the Ubuntu 22.04 runner's toolchain — nothing to do with ruvector-agent-memory or this PR's diff.

Confirmed pre-existing: the identical job (run) fails the same way on main's current head (6191f8f66cdb132cbb676fa94571f87c1e8de308), with byte-for-byte the same undefined symbols in the same libort_sys archive.

A fix exists but hasn't landed on main yet: open PR #1114 diagnosed this exact failure (citing the same symbols) and validated that moving the core-and-rest job to an ubuntu-24.04 runner resolves it (all 3,827 tests passed after that change, per that PR's own description). That fix is bundled inside #1114's much larger, unrelated, unmerged change (a tenant-bound MicroLoRA runtime feature) as a shared-workflow-file edit, not available as a small standalone patch to cherry-pick. Changing a shared CI workflow's runner OS for all PRs is a disproportionate, repo-wide infrastructure change for this narrow Rust-only research PR to carry unilaterally, so I'm not porting it here — recommend it land via #1114 or a dedicated CI-infra PR instead.

Not re-running: deterministic linker failure, reproduces identically on main, not a flake.

(Tests (core-platform) and Tests (core-and-rest-heavy) were still in progress as of this comment; per PR #1114's description they hit the identical ort_sys link failure on the same runner class, so if they complete red here too, same root cause and conclusion applies.)

---

Generated by Claude Code