DW Recall Eval Digest

_Run 2026-08-09T09:55:18+00:00 • http://localhost:8080/api/v1/memories • queries v1_

Verdict: 🟠 LATENCY

_Baseline: 2026-08-08T06-15-40+00-00.json_

p95 latency 582.6ms exceeds budget 445.7ms (1.5× baseline 297.1ms)

Latency p95: baseline 297.1ms → current 582.6ms (budget 445.7ms)

Per-query status vs baseline

Query	Status	Baseline newest	Current newest	Δ
`heartbeat-wide`	STABLE	6.6min	2.5min	+4.1min
`heartbeat-tight`	STABLE	6.6min	2.5min	+4.1min
`heartbeat-mid`	STABLE	6.6min	2.5min	+4.1min
`global-no-filter`	UNMEASURABLE	—	—	—
`sort-param-respected`	STABLE	6.6min	2.5min	+4.1min

5 queries • 0 with flags

Aggregate latency (all samples) p50=196.1ms p95=654.8ms max=582.6ms

`heartbeat-wide`

_The canonical heartbeat-freshness query from CLAUDE.md. limit=200, no sort. Must return cl-pal + codex-pal with fresh ts._

params: {"user_id": "mop-heartbeat", "limit": 200}
latency: p50 196.7ms, max 582.6ms (3 samples)
result_count: 200, http=200
agents_seen: cl-pal, codex-pal
freshness_min_per_agent: cl-pal=2.5min, codex-pal=2.4min
first_id_vs_prior: churned (was 303fbb39-b309-4740-bd12-44c146cc81ee, now ebac8f4d-dfbd-4434-93c4-fa2ed0b4c8f9)
✓ no flags

`heartbeat-tight`

_Catches the 'limit=5 silently returns arbitrary subset' bug. Same query as wide but limit=5 — record what set comes back so we can see set instability across runs._

params: {"user_id": "mop-heartbeat", "limit": 5}
latency: p50 168.4ms, max 191.6ms (3 samples)
result_count: 5, http=200
agents_seen: cl-pal, codex-pal
freshness_min_per_agent: cl-pal=2.5min, codex-pal=2.5min
first_id_vs_prior: churned (was 303fbb39-b309-4740-bd12-44c146cc81ee, now ebac8f4d-dfbd-4434-93c4-fa2ed0b4c8f9)
✓ no flags

`heartbeat-mid`

_Middle-bucket size to triangulate where set instability kicks in._

params: {"user_id": "mop-heartbeat", "limit": 50}
latency: p50 196.1ms, max 203.6ms (3 samples)
result_count: 50, http=200
agents_seen: cl-pal, codex-pal
freshness_min_per_agent: cl-pal=2.5min, codex-pal=2.5min
first_id_vs_prior: churned (was 303fbb39-b309-4740-bd12-44c146cc81ee, now ebac8f4d-dfbd-4434-93c4-fa2ed0b4c8f9)
✓ no flags

`global-no-filter`

_Unfiltered fetch to track corpus size + global latency. Tracks total memory store growth._

params: {"limit": 200}
latency: p50 203.6ms, max 221.4ms (3 samples)
result_count: 200, http=200
first_id_vs_prior: churned (was db29e646d7ece4b7, now 12df089f-ae34-44a1-9d6d-e4a2fc881560)
✓ no flags

`sort-param-respected`

_Per CLAUDE.md, the endpoint silently ignores sort/order/order_by params. This query passes sort=ts:desc — if behavior ever changes (endpoint starts respecting sort), the first-returned-id should differ vs heartbeat-wide. v1 just records the fact; v2 (with Steward) should pass._

params: {"user_id": "mop-heartbeat", "limit": 5, "sort": "ts:desc"}
latency: p50 196.1ms, max 207.0ms (3 samples)
result_count: 5, http=200
agents_seen: cl-pal, codex-pal
freshness_min_per_agent: cl-pal=2.5min, codex-pal=2.5min
first_id_vs_prior: churned (was 303fbb39-b309-4740-bd12-44c146cc81ee, now ebac8f4d-dfbd-4434-93c4-fa2ed0b4c8f9)
✓ no flags

How to read this

Flags are expectation-deltas, not hard failures (timer never pages).
first_id_vs_prior=churned on small-limit queries is the documented silent-arbitrary-subset behavior; it should stabilize once Steward re-rank lands.
Aggregate p95 is the baseline budget — Steward must not blow this out.
Historical snapshots live in recall_eval/baselines/*.json for offline diffing.