docs(measures): the supersede hook — 9.2x fewer records, and D8 is disqualified by watch_since Plus the release automation: gated off, verified skipped, tag still v0.4.5. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs(measures): P6 — recall is 1.0 by construction, query cost is O(ops), compaction cannot help Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs(measures): memory O(parts), the mint-order trap, drain 530x, state gauges, benches in CI Plus north-star P2-P5 landed and a 2026-10-08 session entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
wiki: the manifest quadratic is fixed, measured by a control that still sees it retain=0 disables pruning and IS the pre-fix behaviour, so the planted defect is a configuration the engine still accepts rather than a mutation. It still measures exponent 1.94 while the default measures 1.23, and the file count is held flat at ~39 across 4x the appends against 79 -> 320 unbounded. Residual recorded: bounded BYTES still grow at 1.23 because retention bounds snapshot count, not snapshot size. Adds tail latency, which criterion cannot give -- append p99 7550us against p50 4014us, and group commit 187x cheaper at p50 rather than the 20.4x the throughput figure shows. Adds the acceptance-criteria standard and its honest scoring: column C (observability) is barely started, because metrics.rs exports 7 public functions for an 88-file engine. Filed as noetl/ai-meta#454. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
wiki: the first measurements of the production L0 engine ehdb-l0 had 88 .rs files and ZERO benches while ehdb-reference had 22 and two, so every number on the existing performance page is about the reference model rather than the engine on the path. These are about the engine. ⭐ The two agree where they overlap: that page measured durable append as fsync-bound at ~3.9 ms / ~256 appends/s, and the production engine measures 3.749 ms / 267 appends/s -- within 4%, from a different crate and harness. Two new results. The fsync is ~95% of posture-A write cost: 267 rec/s fsync-per-append against 5 450 group-committed at batch 80, a 20.4x difference, and group commit needs FlushPolicy::CallerDriven or batching costs MORE. And a read steps 15.6x per record at seal_max_records = 1024, so a chain over 1024 events costs ~13x what extrapolating from the sub-1024 figures predicts -- filed as noetl/ai-meta#453, where whether the step is acceptable is an open judgement call rather than an assumed defect. Also records the method: three of three append instruments were wrong before they were right, each caught by its own planted-effect control, including one where the instrument was wrong and not the engine. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>