test(temporal_spine): G3 latency-delta evidence for the #1064 flip gate

[robotrocketscience]

Part of #1064 (temporal-spine flip gate). Produces the G3 — latency
delta (#739-style) evidence: what turning the temporal-spine retrieval
lane on costs at the production operating point.

What this does

benchmarks/temporal_spine_latency.py — the spine analog of
bfs_latency_v3.py (the #739 gate). It:

1. Seeds a deterministic ≥10k-belief store partitioned into per-session
   chains, each with a strictly-increasing created_at, then builds a
   real TEMPORAL_NEXT spine via backfill_temporal_spine
   (beliefs − sessions edges).
2. Probes that the lane actually fires (reads last_lane_telemetry()
   for spine candidates) and refuses to report if it produces zero —
   so a ~0 delta cannot pass vacuously (the Restore the deterministic HRR vocabulary-bridge expansion lane behind a default-off flag, then ablate (revisits #605/#897) #981 trivial-null trap).
3. Times paired retrieve_v2 lane-off vs lane-on (only
   use_temporal_spine differs) and applies the delta gate:
   Δp50 ≤ +5 ms, Δp95 ≤ +50 ms, tail ratio ≤ 10×.

Result (recorded in docs/design/feature-temporal-spine.md)

10,000 beliefs / 200 sessions / 9,800 spine edges, budget 1500 / l1-limit 50:

metric	run 1	run 2	run 3	gate
Δp50	+0.78 ms	+0.04 ms	+0.83 ms	≤ +5 ms ✅
Δp95	+28.4 ms	+24.6 ms	+26.6 ms	≤ +50 ms ✅
tail	2.08×	2.02×	2.27×	≤ 10× ✅

Lane fires on 30/30 queries (109 candidates → 82 packed survivors),
byte-identical across runs. Absolute latencies are machine/load-dependent
(dev baseline p50 64 ms); the gate is a same-corpus delta, as reframed
for #739 in PR #754. The p95 cost (+25 ms) is real, reproducible, and
inside the band. G3 PASS.

What this does not close

• Does not close Temporal spine: ingest-time chronological edges + dedicated retrieval lane (confirmed +14.6pp coverage on LoCoMo) #1064. G2 shadow-eval and the default flip remain.
• No wall-clock assertion is added to the pytest matrix — latency gates
  flake on shared runners. The timed bench is run-on-demand; only the
  pure-logic + lane-fires unit tests run in CI.
• No results JSON is committed (results-file policy); the numbers above
  and in the design doc are the reviewable artifact.

Testing

• tests/test_temporal_spine_latency.py — 13 tests: percentile math,
  gate boundaries (inclusive), corpus/query generation + input
  validation, and a store-backed lane-fires guard. All deterministic.
• Full bench run 3× locally (numbers above); gate PASS each time.

[sourcery-ai]

Sorry @robotrocketscience, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Warning

Review limit reached

@robotrocketscience, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 39 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 66c98b30-6566-403f-bfd0-3980821bd324

📥 Commits

Reviewing files that changed from the base of the PR and between 33b7ddd and 9325f4f.

📒 Files selected for processing (3)

• benchmarks/temporal_spine_latency.py
• docs/design/feature-temporal-spine.md
• tests/test_temporal_spine_latency.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch test/issue-1064-g3-spine-latency

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

PR-size soft cap

This PR is over the advisory size threshold:

• 822 changed lines (limit: 200)
• 3 changed files (limit: 3)

Bigger PRs collide with more open work, which under the parallel-session workflow tends to produce repeated attn:merge-conflict cycles (see #602). When practical, split into smaller PRs that each touch a focused surface.

This is advisory only — nothing is blocked. If the size is intentional (large refactor, module removal, generated code), apply the size:override label and this comment will be removed on the next push.

[robotrocketscience]

[claim:review:Setr:2026-07-04T09:58:07Z]

[robotrocketscience]

Review: LGTM ✅

Reviewed as the author of the sibling G2 evidence (#1074), so this closes out the G3 leg of the same #1064 flip gate.

Methodology is right. The gate is a same-corpus delta (spine_on − spine_off), not an absolute latency — correct per the #739/#754 reframe, since absolute ms is machine/load-dependent. Timing is perf_counter around each retrieve_v2, with warmup iterations discarded so the percentiles reflect steady state. Gate constants (GATE_DELTA_P50_MS=5, GATE_DELTA_P95_MS=50, tail ratio ≤10×) match the design-doc criterion exactly.

The trivial-null trap is guarded. A ~0 delta is only meaningful if the lane actually did work; the bench refuses to report unless the lane fires on ≥1 query (the #981 trap), and the recorded run fires 30/30 (109 candidates → 82 packed). This is exactly the concern that matters for a default-off lane — good that it's enforced, not assumed.

No flake surface in CI. The timed bench is run-on-demand; only pure-logic (percentile math, gate pass/fail on each dimension, boundary-inclusive ≤) and lane-fires tests run in the pytest matrix. That's the right call — a wall-clock p95 assertion on shared runners would flake (the known pattern).

Result passes with margin. 10k beliefs / 200 sessions / real 9,800-edge spine at the production point (1500/50): Δp50 ≤ +0.8 ms, worst Δp95 +28.4 ms — comfortably inside the +5 / +50 ms band even allowing for hardware variance. Design-doc claim matches the bench's gate.

Gate checks: CI CLEAN, both commits signed, FF on main (includes the merged #1074 G2 evidence — design-doc additions don't collide), 0 unresolved threads, diff + commit messages discretion-clean.

With G2 (#1074, merged) and G3 (this PR) both green, the only remaining flip-gate item is the G2 shadow-eval on a real backfilled store. Routing to the merge-train.

[robotrocketscience]

[release:review:Setr:2026-07-04T10:00:01Z]

[github-actions]

merge-train: merged 9325f4f → main via FF push.