titen-memory 0.7.2

Stable release · npm latest

npm install -g titen-memory@0.7.2

Install guide · Release page · npm package

---

An urgent fix: 0.7.1 cannot serve a large single-subject store. Upgrade from
0.7.1 without delay; 0.7.0 is unaffected.

Fixed

• titen-memory@0.7.1 cannot serve a large single-subject store: one context
  compile takes a median 74.5 seconds where 0.7.0 takes under half a second. The 0.7.1
  fix for #291 wrote the
  disputed predicate as a join inside EXISTS while its own comment claimed
  the nested form, and a join inside EXISTS is still a join the planner may
  reorder. SQLite 3.53.0 — the version Bun 1.3.14 links — reorders it to
  SEARCH o USING INDEX observations_workspace_scope (org_id=?), scanning every
  observation in the organization once per candidate row: the exact shape
  src/core/authorization.ts documents as the historical 79-second failure,
  shipped in the release that believed it had prevented it.

  Who is affected: anyone whose store holds many claims under one subject
  and who compiles with a large max_candidates. The cost is the product of
  candidates and organization-wide observations, so small and per-subject stores
  are unaffected — which is why no test and no published benchmark caught it.
  Every published pooled quality figure was measured on 0.7.0; every published
  pooled or scoped-anchor latency figure was measured on 0.7.0 or on this
  release, never on 0.7.1.

  Measured, 342,129-claim / 19,829-observation store, one subject, real
  statement, EXPLAIN captured from bun:sqlite rather than a pasted copy:

  	candidate query	served compile
  0.7.1 as published	73,439 ms	74,474 ms
  this release	232 ms	417 ms p50 / 864 ms p95

  This restores 0.7.0's behaviour; it does not make compile fast. 864 ms
  p95 still fails the pre-registered 250 ms gate, so the 2026-08-07 latency
  falsifier stands — the pre-registration predicted exactly that outcome in
  writing before the run.

  The ranked output is byte-identical to the published 0.7.0 pooled run —
  equal sha256 over all 500 instances — so this restores the shipped answer
  rather than changing it. Full method and both plans in
  the report, protocol
  pre-registered
  before the A/B.

Added

• Plan-shape guards for the retrieval queries
  (tests/integration/query-plan.test.ts). The regression above was invisible
  to every existing test because contract stores hold tens of rows and still
  return the right answer quickly. The load-bearing discovery is that the bad
  plan reproduces on an empty store — SQLite picks the join order from the
  schema, not from row counts — so a cheap deterministic test could have caught
  this and the 2026-08-07 occurrence before either shipped. The guards assert
  the plan of the candidate query, the by-id hydration, and authorized-source
  loading; reverting the fix fails two of the three. They assert the plan, never
  a duration: a timing assertion on this hardware would be flaky, and the plan
  is what regressed.