trajectories 0.0.0 → 0.1.2

package/docs/research/ledger/docs/research/2026-09-16-c6-recency-prior.md

@@ -0,0 +1,438 @@
+# C6: the recency prior before RRF, 2026-09-16
+
+## Outcome
+
+Both lexical lanes now order by **bm25 × time decay**, Wake's shape: a session
+from today is ×2, one 30 days old ×1.5, one a year old ×1.08
+(`crates/wake-core/src/db.rs#L1546-L1560`, tag v0.6.5, MIT). The factor is keyed
+on the *session's* `started_at`, so hits inside one session keep their bm25
+order; it is the lane's `rank`, so within a lane the emitted `score` is the
+ordering key; the clock is one `Date.now()` per query, shared by both lanes. The
+semantic lane stays pure cosine, and hybrid inherits the prior through the
+lexical leg's *positions* — which is what RRF reads. No counter moves, no DDL
+changes, no new dependency: `FTS_FORMAT` stays `"3"`.
+
+On a byte-consistent copy of the production store (1,135,804,416 B, 2,613
+sessions, 230,451 records, 0 embeddings), the case the cycle exists for:
+(Point-in-time fixture — measured 2026-09-16 on that copy; the live store
+grew during review and later re-measurements of the same queries can flip
+differently while still following the same crossover rule, which predicted
+the winner in every re-measured case.)
+
+| query | what changed | raw bm25 gap | factor gap | verdict |
+| --- | --- | --- | --- | --- |
+| `recency prior` (record lane) | rank 1 was a 3.62-day-old session, now today's (age 0.11 d) | today's match was **0.7% weaker** | **1.055×** | flips — the intended case |
+| `gemini` (title lane) | rank 1 was a 34.81-day-old title, now a 2.11-day-old one | the new rank 1 is **16% weaker** | **1.322×** | flips |
+| `memory cards` (record lane) | rank 1 unchanged: the 64.2-day-old session | old is **2.50× stronger** than today's best | 1.478× | holds — a relevance lead past the factor's span survives |
+
+So the crossover is quantified, not assumed: **a newer hit takes the position of
+an older one only when its raw bm25 is within the factor ratio** — today vs 30
+days it needs ≥ 75% of the older hit's magnitude (2.0/1.5), today vs a 400-day
+one ≥ 54% (2.0/1.07), and the `memory cards` row above is the other side of it
+(40%, loses). Intra-session order is provably untouched: 17 hits of one session
+scale by exactly the same factor (measured ratio 1.9784, identical across all
+17) and none of them moves.
+
+The cost is one expression per matched row. Measured directly on the worst case
+(48,120 matched rows, `run`, 258 ms): **+4.9 ms** for the chosen `unixepoch()`
+route, where a `strftime('%s', …)` route costs +9.6–12.7 ms and `julianday`
++5.0–7.2 ms — the fastest epoch route is the one that shipped. At the reader
+level (interleaved A/B, 25 runs each, three passes) the delta is inside the
+host's noise: −1.42 ms to +0.12 ms per query, with the one reproducible residue
+being the fastest query in the set (0.66 → 0.78 ms, +0.12 ms, where a fixed cost
+is a measurable share).
+
+## The mechanism
+
+Pinned upstream (`/tmp/ledger-confer/wake`, `d9f702b6`, tag v0.6.5):
+
+```sql
+-- db.rs#L1552 (the constant), #L1604 (the message lane), #L1685 (the title lane)
+ORDER BY bm25(messages_fts) * (1.0 + 1.0 / (1.0 + max(0, ? - s.updated_at) / 2592000000.0)) LIMIT ?
+```
+
+Wake multiplies its message lane and its title lane by the same expression, keys
+it on the session's `updated_at` (not the message's `ts`, so intra-session order
+is untouched), binds the clock as a parameter, and uses only arithmetic and
+`max()` — no SQLite math extension. Its degraded `LIKE` path keeps time ordering
+because it has no bm25 to weigh; Ledger has no such path (its lexical fallback
+is still FTS5), so there is nothing to mirror there.
+
+Ledger's port, one shared fragment used by both lanes:
+
+```sql
+bm25(records_fts) * (1.0 + 1.0 / (1.0 + max(0, ? - COALESCE(unixepoch(s.started_at) * 1000, 0)) / 2592000000.0)) AS rank
+ORDER BY rank ASC, s.started_at DESC
+```
+
+Four Ledger-specific shape decisions inside one expression:
+
+- **`unixepoch()` is the epoch conversion**, because this store has no numeric
+  time column — `sessions.started_at` is ISO-8601 TEXT. It is core SQLite
+  (3.38+), and the read path only ever runs on Bun's bundled SQLite 3.51.0 (the
+  same runtime C5 verified its feature set against; the native SQLite window of
+  C1 never runs FTS ranking). Measured against the alternatives below.
+- **`COALESCE(…, 0)`** puts an absent or unparsable timestamp at the epoch —
+  the factor's neutral end (×1.0). Without it, the arithmetic yields NULL, and
+  NULL sorts *first* in an `ASC` ORDER BY: an unparsable timestamp would have
+  become the strongest possible ranking signal. Verified on the store: all
+  2,613 sessions parse (0 NULLs), so the clamp is a guard, not a behaviour.
+- **The `?` is `Date.now()` fixed once per query** and passed to both lanes, so
+  a title hit and a record hit of one session are weighted identically and a
+  single query cannot see two clocks (Wake's `now_ms()`, bound the same way).
+  This is also what made the constant cheap: `strftime('%s','now')` inside the
+  expression was evaluated per row.
+- **H is spelled as a real** (`${RECENCY_DECAY_MS}.0`): SQLite divides integers
+  with integer division, and a truncated divisor would silently make the factor
+  ×2 for every row in the corpus — a failure that would look like a stronger
+  prior rather than a bug.
+
+## Decisions (the cycle's open questions, resolved)
+
+**1. Where the prior applies: both lexical lanes; not the semantic lane.**
+Wake weighs both of its lanes, and Ledger's two lanes are one query's answer, so
+both take the same factor. The semantic lane was decided separately, on the
+measured shape of cosine rather than on symmetry: with the shipped model
+(`all-MiniLM-L6-v2`, 384 dims) over 300 real records from the production store,
+the whole top-50 span of a query's cosine scores is **1.77–2.60×**
+(r1/r50 = 2.19 / 1.77 / 2.60 for three queries; r1 ∈ [0.34, 0.40], r50 ∈ [0.15,
+0.20]). That is the *entire* range a semantic query has to work with, and the
+prior's own multiplier spans ×1–×2 over the same corpus — so the same factor on
+cosine would order that lane by age nearly regardless of text, and it would stop
+the reported `rank` from being a cosine at all. bm25 is the opposite kind of
+score: unbounded, negative, and sparse (the measured flips above turn on
+comparisons at 0.7% and 16%, and the no-flip on 2.5×). The program's promise —
+cheap, arithmetic-only, no rescore pass — is kept by the lexical lanes, where
+the prior is one `ORDER BY` term; the semantic lane is not left without recency,
+it is left to the fusion, which is the layer designed to combine rank orders.
+
+**2. The decay constant: 30 days, Wake's H, unchanged.** Measured distribution
+of the store as it stands (read-only queries against the live file; the cycle
+only ever read it):
+
+| age of session start | sessions |
+| --- | --- |
+| ≤ 1 day | 17 |
+| ≤ 7 days | 78 |
+| ≤ 30 days | 132 |
+| ≤ 90 days | 652 |
+| ≤ 1 year | 2,605 |
+| > 1 year | 8 |
+
+and by month: 2025-08 8, 2025-09 33, 2025-10 37, 2025-11 1, 2025-12 11, 2026-01
+755, 2026-02 2, 2026-03 12, 2026-05 1,068, 2026-06 69, 2026-07 209, 2026-08 300,
+2026-09 108. Two things follow. The corpus is **not** "two weeks of heavy
+activity" — it is a year wide with two backfilled lumps (2026-05, 2026-01) and a
+live edge of ~78 sessions in the last week — so a prior tuned only to the last
+fortnight would be tuned to 3% of the store. And 30 days is a scale that
+separates the live edge from the lumps without erasing everything older: a
+2026-05 session still carries ×1.20 and a 2026-01 one ×1.11, while the last
+week's work spans ×1.81–×2.0. The constant stays Wake's; nothing measured argues
+for a different one, and a deviation would need a corpus whose live edge sits at
+a different scale (a reopen condition, below).
+
+**3. The key is `started_at`, not `updated_at` or `ended_at`.** `updated_at` is
+the ingest write clock (`ingest.ts` stamps `new Date()`), and the measurement
+makes it unusable: every one of the store's 2,613 sessions is stamped between
+2026-09-12 and 2026-09-16 — a four-day window that would make a backfill of
+2025 material rank as "today". `ended_at` is the content analog of Wake's
+`updated_at` and would be the second-best choice: it moves the recency bucket of
+only 5 of 2,613 sessions (active in the last 7 days: 78 by `started_at`, 83 by
+`ended_at`; last 24 h: 17 vs 19; >1 day of spread between the two: 48 sessions,
+1.8%; `ended_at < started_at`: 0). With the two keys nearly equivalent on this
+corpus, the lane keeps one timestamp: the one its `ORDER BY … started_at DESC`
+tiebreak already names, and the one that never needs a fallback.
+
+**4. RRF interplay: the prior must move the legs, and it does.** RRF reads rank
+*positions* (k = 60), so a reorder inside a leg is exactly how a fused result
+changes; the fusion code was not touched. Two consequences, both checked: a hit
+whose raw relevance lead exceeds the factor ratio keeps its leg position (the
+`memory cards` row), so the fusion keeps its winner; and a hit whose relevance is
+comparable moves up its leg, which is the intended change (`gemini`: the
+2.11-day title was 16% weaker in raw bm25 and still takes rank 1 — 1/(60+1) vs
+1/(60+2) is a 1.6% RRF difference, and the fused order follows the leg). The
+test suite pins the direction end-to-end: a fresh session that is *only* a
+lexical match outranks a 500-day-old session that is *only* a semantic match,
+because the lexical leg's position carries the recency and the semantic leg's
+does not.
+
+**5. Envelope honesty: nothing is disclosed, and `rank`'s meaning is
+documented.** The prior is internal ranking, like bm25 itself — Wake's
+`SearchHit` carries no score at all (`crates/wake-core/src/models.rs#L433-L440`),
+and Ledger's envelope already discloses *mechanisms that change what could be
+answered* (widening, fallback, count precision) rather than ranking internals.
+What did change is what `score` means, so the api-surface lane-relative note now
+says it: title and record hits carry bm25 weighted by the same prior, so within a
+lane the score is the ordering key, and the stream's emission order (titles
+first, then body) remains the contract; consumers must not re-sort across lanes.
+The type comment on `SearchHitBase.rank` says the same for library callers. No
+`recency_weighted` field, because a boolean that is always true is not
+information.
+
+**6. The constant is pinned by a test, not a comment.** The one place the number
+30 is asserted: two sessions with *identical records* (identical raw bm25) aged
+0 and exactly 30 days must report ranks in the ratio 0.75 —
+`(1+1/(1+30/30)) / (1+1/(1+0)) = 1.5/2`. Move the constant and that ratio moves
+with it (`packages/core/tests/recency-prior.test.ts`).
+
+## FTS_FORMAT: verified against C2's counter contract, and it does not move
+
+C2's contract (`docs/research/2026-09-16-c2-derive-counter.md`, ADR "Derive-Rule
+Counters"): the counter names **the rules a derived index was produced under**,
+and "a mismatch → one full re-derivation" — it exists for changes to the derived
+tables' *shape* (rows, columns, tokenizer, projection), which is exactly what
+C3 (echo filter), C4 (title index) and the refused C5 (trigram) changed. C6
+changes none of that: the same DDL, the same projections, the same row sets, the
+same tokenizer — the same `records_fts` and `titles_fts` bytes. What changed is
+one expression inside two read-side `SELECT`s. The verification is structural,
+not a measurement: `git diff --stat` for this cycle touches `reader.ts` (both
+lane SQLs plus comments), tests, `types.ts` (a doc comment) and this note's docs
+— no `schema.ts`, no `db.ts`, no `ingest.ts`, no migration, and
+`DERIVE_COUNTERS[].outputs` (`records_fts`, `records_echo`, `titles_fts`) are
+untouched, so a store at `fts_format = "3"` is exactly as derivable under this
+build as under C4. The `derive-counters` suite passes unchanged. The honest
+consequence for operators: this cycle ships with **zero re-derivation cost** —
+the opposite of C3/C4/C5, which each cost a one-shot rebuild.
+
+## Measurements (OBSERVED)
+
+Host: Apple M1, macOS 25.6, APFS; Bun 1.3.14 (SQLite 3.51.0). Fixture: a copy of
+the production store taken with `cp` of `db` + `-wal` + `-shm` into `/tmp` (the
+live store was only ever read); "before" is the reader at HEAD `efa1b3a`
+extracted with `git archive`, "after" is the working tree.
+
+**The store's own timestamps** (read-only, production file): 2,613 sessions,
+230,451 records, 0 embeddings; `started_at` spans 2025-08-25T16:31:18.545Z →
+2026-09-16T08:14:08.018Z, `updated_at` spans 2026-09-12T08:50:56.960Z →
+2026-09-16T08:52:11.295Z; no NULL `started_at`/`ended_at`/`updated_at`; 0
+timestamps that `unixepoch()` or `strftime('%s', …)` cannot parse, and the two
+agree on all 2,613 values (checked before choosing `unixepoch`).
+
+**Before/after orderings** (limit 50, the reader's own SQL; "before" ranks are
+raw bm25, "after" ranks are the weighted value). The factor column is computed
+from the session age at the moment of the run.
+
+`recency prior` — the flip:
+
+| | rank | session age | raw | factor | weighted |
+| --- | --- | --- | --- | --- | --- |
+| before 1 | 1 | 3.62 d | −8.8617 | 1.892 | — |
+| before (today's session, lower down) | — | 0.11 d | −8.8014 | 1.996 | — |
+| after 1 | 1 | 0.11 d | −8.8014 | 1.996 | −17.5700 |
+| after 2 | 2 | 3.62 d | −8.8617 | 1.892 | −16.7684 |
+
+Raw gap 1.007×, factor gap 1.055×: today's match needed ≥ 94.8% of the older
+one's magnitude and had 99.3%.
+
+`gemini` (title lane) — the flip with a wider raw deficit:
+
+| | rank | session age | raw | factor | weighted |
+| --- | --- | --- | --- | --- | --- |
+| before 1 | 1 | 34.81 d | −8.4272 | 1.463 | — |
+| before (the new rank 1) | 3 | 2.11 d | −7.2660 | 1.934 | — |
+| after 1 | 1 | 2.11 d | −7.2660 | 1.934 | −14.0547 |
+| after 2 | 2 | 34.81 d | −8.4272 | 1.463 | −12.3282 |
+
+Raw gap 1.160×, factor gap 1.322×: the newer title needed ≥ 75.6% and had 86.2%.
+A record-lane hit from 1.65 d (raw −6.9040) also moved from below the old title's
+record-lane tail to overall rank 6.
+
+`memory cards` — the crossover holds:
+
+| | rank | session age | raw | factor | weighted |
+| --- | --- | --- | --- | --- | --- |
+| before 1 | 1 | 64.22 d | −14.7885 | 1.318 | — |
+| after 1 | 1 | 64.22 d | −14.7885 | 1.318 | −19.4970 |
+| after 2 | 2 | 1.65 d | −5.9181 | 1.948 | −11.5284 |
+
+Raw gap 2.499×, factor gap 1.478×: today's best match needed ≥ 67.7% of the old
+one's magnitude and has 40.0% — the relevance lead outlives the factor, and the
+old session keeps rank 1.
+
+**Intra-session invariance** (`wal_autocheckpoint`, one session, 17 hits): every
+hit scaled by the same 1.9784 (the session's factor at 0.66 d), so the sequence
+of weighted ranks is the sequence of raw ranks multiplied by a constant — no
+within-session reordering is possible.
+
+**Latency** (limit 50, warm, median of 25 interleaved runs in one process; hits =
+returned hits; matched rows from a separate `COUNT(*) … MATCH`, given where it
+matters):
+
+| query | hits | matched rows | before | after | delta |
+| --- | --- | --- | --- | --- | --- |
+| `recency prior` | 25 | — | 1.57 ms | 1.59 ms | +0.02 ms |
+| `memory cards` | 7 | — | 0.75 ms | 0.76 ms | +0.01 ms |
+| `wal_autocheckpoint` | 50 | 84 | 8.67 ms | 8.72 ms | +0.04 ms |
+| `gemini` | 50 | — | 41.90 ms | 40.48 ms | −1.42 ms |
+| `ledger` | 50 | 13,807 | 0.68 ms | 0.77 ms | +0.08 ms |
+| `the` | 50 | 74,074 | 3.09 ms | 3.04 ms | −0.05 ms |
+| `test` | 50 | — | 0.32 ms | 0.37 ms | +0.04 ms |
+| `run` | 50 | 48,120 | 258.33 ms | 257.57 ms | −0.76 ms |
+
+Three passes of the same harness agreed within this: the largest positive delta
+seen on any query in any pass was on `ledger` (0.68 → 0.77 ms, reproducible at
++0.08…+0.12 ms), and the 258 ms query measured −0.76 and +5.76 ms on the shipped
+shape and +4.10 ms on the earlier `strftime` variant — i.e. inside the host's
+noise band (±3 ms at that size), which is why the added term was also measured
+*directly*: the same rank expression with and without the factor, in the
+minimal SQL around it (no `snippet()` columns), 15 iterations, same store, query
+`run`, 48,120 matched rows:
+
+| rank expression | median |
+| --- | --- |
+| `bm25(records_fts)` (baseline) | 202.27 ms |
+| `bm25 × strftime('%s', …)` prior | 215.00 ms (+12.7 ms) |
+| `bm25 × julianday(…)` prior | 207.17 ms (+4.9 ms) |
+| **`bm25 × unixepoch(…)` prior (shipped)** | **207.13 ms (+4.9 ms)** |
+
+So the prior's true worst-case cost on this corpus is ~5 ms on a 258 ms query
+(≈1.8%), the chosen epoch route is the cheapest of the three measured, and
+everything that answers in under 10 ms pays ≤ 0.12 ms.
+
+**Cosine spread** (the semantic decision, measured with the shipped
+`OnnxEmbeddingProvider`): 300 real records' embedding text from the store copy,
+three queries, cosines of the top 50:
+
+| query | r1 | r10 | r50 | median | r1/r50 |
+| --- | --- | --- | --- | --- | --- |
+| `recency prior` | 0.3363 | 0.2338 | 0.1539 | 0.1908 | 2.19× |
+| `sqlite wal checkpoint` | 0.3463 | 0.2520 | 0.1953 | 0.2203 | 1.77× |
+| `gemini embeddings backfill` | 0.4027 | 0.2394 | 0.1550 | 0.1846 | 2.60× |
+
+## What is inferred (INFERRED, marked)
+
+- The corpus conclusion ("30 days separates the live edge from the backfilled
+  lumps") is an inference from the session-start histogram, not a measurement of
+  retrieval quality: no relevance judgement exists for this store, so the cycle's
+  evidence is ordering deltas and arithmetic, not graded accuracy. A qrels set
+  would be the way to argue for a *different* constant.
+- The +4.9 ms worst case is a lower bound for a bigger corpus: the expression is
+  O(matched rows), so a store several times this size would pay proportionally
+  more on its slowest queries (the same shape C5 measured for bm25 itself).
+- The claim that a semantic-lane prior would order by age is an extrapolation
+  from the measured 1.8–2.6× span plus the factor's own ×1–×2 range; it is not a
+  measured end-to-end semantic ranking (the production store holds no vectors:
+  `records_embeddings` is empty, so the semantic lane answers lexically there by
+  design).
+- `ended_at` as the key would likely read slightly better for resumed sessions
+  (the 5 sessions whose bucket moves), but nothing measured shows a user-visible
+  difference at this corpus size.
+
+## Tests
+
+`packages/core/tests/recency-prior.test.ts` (7 cases, fixtures dated relative to
+`now` because a literal timestamp cannot pin "today"). Three of them prove their
+own premise by *inverting* the prior — `rawBm25(hit) = rank / (1 + 1/(1 +
+age/30d))` recovers the raw bm25 the lane would have ranked by, so the test can
+assert that the fresh hit really was the weaker raw match the prior reversed,
+and that the crossover hit truly is stronger by more than the factor's span:
+
+1. the record lane prefers the session from today when the two matches are
+   comparable, with the premise asserted (today's raw bm25 is weaker);
+2. a much stronger old match still wins — the crossover, with the fixture's
+   measured raw gap (2.50×) against the factor's span (1.87×) in the case
+   comment and in the premise assertion;
+3. the title lane orders by the same prior (today's longer, weaker title beats
+   an older, stronger one), and an exact 400-day-old title still wins over
+   today's diluted one, again with both premises asserted;
+4. intra-session order is the session's bm25 order — the factor is the session's,
+   not the record's (the appended-today record still ranks below the older,
+   stronger one);
+5. the decay constant is 30 days: identical records 0 and 30 days old report
+   ranks in the exact ratio 0.75;
+6. the semantic lane stays pure cosine (a 500-day-old session wins on similarity
+   alone, and its reported rank is the cosine) while hybrid lifts the fresh
+   lexical match above it through the lexical leg's position;
+7. the lane contract survives: a title hit is emitted ahead of a record hit whose
+   rank is *more* negative, and both ranks are negative.
+
+Five existing tests carried assumptions the prior invalidates, each fixed at the
+assumption rather than around it:
+
+- `search-quality.test.ts`, the `zonk` twins: they no longer share a rank (the
+  prior separates them by session age), so the assertion pins the direction
+  (newest rank most negative) instead of equality — the order assertion above it
+  is unchanged and still passes.
+- `integration-migrations.test.ts`, `querySnapshot`: the rebuild comparison
+  cannot compare `rank` exactly any more, because rank is now a function of the
+  wall clock as well as the index; it compares at six significant digits, which
+  absorbs any time between the snapshots and is far tighter than any change a
+  rebuild could make to bm25.
+- `robot.test.ts`, the v1 byte-identity case, and `cli-canonical.test.ts`, the
+  `search`/`query` alias case: two CLI *processes* can no longer render identical
+  last digits for `score`, so the score value is blanked (robot) or zeroed
+  (cli-canonical, whose normalizer already does the same for `elapsed_ms`) on
+  both sides, and every other byte is still compared as written.
+- `title-index.test.ts`: the tie comment ("equal rank, so the newer session comes
+  first") became "equal relevance, so the prior decides" — the assertion is
+  unchanged.
+
+## Roadmap context and the open-source case (program doc, C6 row)
+
+> **C6** | Recency prior before RRF (bm25 × time-decay, arithmetic-only) | All
+> lanes order by relevance with `started_at DESC` tiebreak only; "the session
+> from today" loses to an old strong match | Cheap relevance win every user
+> feels; no extension dependency, single ORDER BY term
+
+Both halves hold as measured: the fix is real and visible (`recency prior`,
+`gemini`), it is one `ORDER BY` term with no extension and no rescore pass, and
+its cost is ~5 ms at the corpus's slowest query and unmeasurable elsewhere. The
+program's dependency note — C6 after C5, "ranking experiments on the final
+tokenizer" — resolves cleanly: C5 refused the trigram swap, so the prior was
+designed and measured against the porter index the store actually ships.
+
+## What would reopen this
+
+1. **A relevance judgement set.** Every ordering claim here is an ordering
+   delta; with graded relevance the constant (30 d) and the weight (W = 1) could
+   be tuned instead of inherited, and the crossover table is exactly the shape
+   that tuning would consume.
+2. **A corpus whose live edge sits elsewhere** — e.g. a store used hourly where
+   a 7-day scale separates the working set, or one whose backfill is recent
+   enough that `updated_at`-shaped reasoning tempts a re-look. Re-measure the
+   histogram first; the constant is one line.
+3. **Candidate capping for the common-term classes** (the C5 note's own reopen
+   item): the prior is O(matched rows) on top of bm25's existing O(matched rows),
+   and a match-set-bound query large enough to need capping would want the
+   recency term inside the capped plan rather than after it.
+4. **A semantic-lane recency decision with real vectors in the store.** The
+   decision here is argued from the cosine spread and defended by the fusion;
+   with a populated `records_embeddings` the same measurement could be run on
+   real semantic rankings.
+
+## Method (for reproducibility)
+
+Copy the live store to `/tmp` (`cp` of `db`, `-wal`, `-shm`; the original was
+never opened for writing). Extract HEAD into `/tmp/c6/before` with
+`git archive HEAD packages/core | tar -x` and symlink `node_modules`, so both
+codebases can be loaded side by side. The harnesses lived in `/tmp/c6` and were
+deleted: an A/B probe that prints ranked hits for a query from a given tree, an
+interleaved latency harness (25 runs per tree per query, medians, in one
+process), a direct-expression benchmark, a cosine probe against the shipped
+ONNX provider, and a fixture calibration script. Gates on the tree:
+`cd packages/core && bun test` (**586 pass / 0 fail** across 41 files, of which
+this cycle's 7 are `tests/recency-prior.test.ts`), `bun run typecheck`,
+`bun run build`.
+
+## Wake pins (MIT, `iAmCorey/Wake@d9f702b6` tag v0.6.5)
+
+| mechanism | pin |
+| --- | --- |
+| the decay factor, W = 1 and H = 30 days, as one ORDER BY term | `crates/wake-core/src/db.rs#L1552` (`RECENCY_BOOST`), `#L1604` |
+| the same factor on the title lane | `db.rs#L1685` |
+| keyed on the session's timestamp, so intra-session order is untouched | `db.rs#L1546-L1556` (the comment above the constant) |
+| the clock bound as a parameter, arithmetic and `max()` only | `db.rs#L1553` (`now_ms()`), `#L1604` |
+| the degraded path keeps time ordering (no bm25 to weigh) | `db.rs#L1632-L1650` |
+| ranking internals are not part of the hit shape | `crates/wake-core/src/models.rs#L433-L440` (no score field) |
+
+## Files
+
+- `packages/core/src/reader.ts` — `RECENCY_DECAY_MS`/`RECENCY_PRIOR_SQL`, the
+  record lane's `rank`, the title lane's `rank`, the per-query `now`, and the
+  semantic lane's decision comment.
+- `packages/core/src/types.ts` — the `SearchHitBase.rank` doc comment.
+- `packages/core/tests/recency-prior.test.ts` — this cycle's 7 cases.
+- `packages/core/tests/{search-quality,integration-migrations,robot,cli-canonical,title-index}.test.ts`
+  — the five assumptions the prior invalidates, each fixed where it was wrong.
+- `docs/api-surface.md` — the lane-relative `score` sentence (§1.4.4), the
+  `titles_fts` search bullet (§3.2), and the C6 ADR entry (§4).