Skip to content

ADR-0198: Model-planned recall uses type hints, not guessed hard filters

  • Status: Accepted implementation mechanism under ADR-0178
  • Date: 2026-10-12
  • Detailed design: docs/plan/general-memory-recall.md

Evidence

The completed six-arm PostgreSQL development comparison records four remaining reader-planned failures. The planner asked for fact, preference or procedure_pointer records while normal formation had stored the required claims under other kinds. These hard predicates excluded the correct originals before either retrieval channel. The failures span a vehicle, a dietary constraint, a recurring review and an entrance instruction; this is not an ownership rule.

Decision

Production advertises memory.search@2.0.0 with optional type_hints. These are soft structured relevance anchors and never populate the query's hard belief_types predicate. The model-facing schema does not advertise the old belief_types argument; unsupported old arguments fail validation rather than silently widening a requested filter. Query preparation and execution use the same version and mapping. The major version identifies the changed input contract. Its concise description stays within the existing tool-definition budget; the limit is unchanged. Scope, explicit subjects and temporal arguments retain their existing semantics in this repair.

The explicit RecallQuery.belief_types predicate remains a hard filter in both stores, including dense retrieval. The legacy tool mode remains available to frozen/direct diagnostic callers with its unchanged memory.search@1.1.0 contract. No provider, index, ranker, owner-specific dictionary or production semantic channel is added or activated.

Verification

Runtime schema coverage first reproduces the unsafe planning surface. Cross-kind regressions must retrieve a lexically relevant original despite a wrong hint, while an explicit legacy filter still excludes it. Unknown hint values and the old hard-filter argument are rejected on the model-facing surface. Existing isolation, preparation, budgets and PostgreSQL contracts remain mandatory. The development comparison remains frozen; it cannot certify this later repair.