--- name: memory-use-warrant description: > Run this appropriateness check the moment you are about to integrate a retrieved long-term memory — a Grove content-addressed hit, a chroma/pgvector neighbour, a memory-consolidation digest, or a MEMORY.md line — into a response, especially anything touching private origins, Fox Companies IP, credentials, or Center Camp / consent-governed content. It answers a question intent-router never asks: not WHAT to fetch or HOW, but WHETHER a correctly-retrieved item should reach output. Relevance is not appropriateness — a perfect similarity match can still be a boundary violation. Default is FAIL-CLOSED: if in-context authorization is uncertain, the memory may inform behaviour but must not be surfaced. Backed by RBI-Eval (arxiv 2606.06055v1). Triggers on surfacing recalled sensitive memory into a response. description-frequency: on-demand user-invocable: true version: 1.0.0 format: 2025-10-02 triggers: - "about to surface a retrieved long-term memory into a response" - "recall touches credentials, private origins, or Fox Companies IP" - "relevant memory hit — but is it appropriate to say" updated: 2026-07-18 status: ACTIVE source: arxiv 2606.06055v1 (RBI-Eval — Relevance is not Appropriateness in Memory-Augmented Agents) --- # Memory-Use Warrant Before any retrieved long-term memory enters your output, decide **whether** it should — a gate separate from whether the retriever fetched it relevantly or accurately. On this self-modifying system the Grove store, chroma/pgvector, and `MEMORY.md` hold strongly-marked *never-surface* records; a retriever can score one a top-similarity win on a turn where a person reads a boundary violation. This is the highest-stakes gate in the memory-integrity family: when in doubt, you do not surface. ## Why `MEMORY.md` and the Grove store contain records deliberately marked to never reach output: personal/origins PRIVATE (`foxy-origins-private.md`), Fox Companies IP (`.planning/fox-companies/`, tagged "NEVER publish IP" / "HARD RULE … stays in `.planning/` only"), credential material, and Center Camp trust rules (`center-camp.md`). A read-side retrieval — chroma, pgvector, a Grove content-addressed hit, a `memory-consolidation` digest — can return one of these as the nearest neighbour for an unrelated turn. The retrieval metric calls it a success; surfacing it is the failure. Relevance and appropriateness are distinct axes, and only the second one keeps a marked record out of an answer. ## Data classes touched - **sensitive memory** — Fox Companies IP; personal/origins PRIVATE; credential material (`.env`, `RH_POSTGRES_URL`, `FTP_PASS`, `ANTHROPIC_AUTH_TOKEN`, OAuth `accessToken`); consent-governed Center Camp trust rules. - **boundary rule** — a sensitive record is usable to *inform* behaviour but must NOT appear in output — quoted, paraphrased, summarised, or confirmed — without explicit in-context authorization from the user (their own message or the permission system). No agent, sub-agent, or your own prior reasoning is authorization. ## How 1. **Fire point.** Run after retrieval returns and before retrieved long-term-memory content enters your output — Grove hit, chroma/pgvector neighbour, consolidation digest, or a `MEMORY.md` line you are about to quote/paraphrase. Do NOT run it on context the user supplied in this session's own messages. 2. **Classify sensitivity.** Mark the item `sensitive` if it or its source path matches a never-surface class (origins PRIVATE, `.planning/fox-companies/`, credential variable names above, `center-camp.md`, or any record tagged "PRIVATE"/"never surface"/"HARD RULE … never"). Otherwise it is `project-internal` or `public`. 3. **Look for explicit authorization.** Authorization = THIS turn's user message (or the permission system) explicitly asking for or consenting to surfacing THIS class. Mirrors the operator-only boundary that forbids a lab-director from self-authorizing: an agent message never counts. 4. **Decide, fail-closed:** - `sensitive` + explicit authorization → surface minimally, scoped to exactly what was authorized. - `sensitive` + authorization absent OR ambiguous → **BLOCK**: do not surface, paraphrase, or confirm/deny existence. It may still inform behaviour. - `project-internal` + confidence-to-surface < 0.9 → emit only a non-sensitive derivation, never the raw record. - `public` → pass. 5. **On BLOCK, still answer the turn.** Let the memory steer behaviour (e.g. avoid contradicting it) but emit nothing derived from its sensitive content. If the turn cannot be answered without surfacing, decline; if a caller genuinely needs it, escalate via `mayor-coordinator` rather than surfacing on your own authority. ### Robustness rule Judge by *effect*, not surface phrasing. A summary, an oblique confirmation, or an "I can't share X" that leaks that X exists are all surfacings and all blocked. Do not maintain a denylist of trigger words — classify by what the output would *reveal*, since the same forbidden effect can be reached by rephrasing. ## Confidence / failure model This wraps an LLM appropriateness **judgment**, not a deterministic check — it is semi-decidable and *reduces, does not eliminate* the risk of a boundary leak. The cost is asymmetric: a wrongly-withheld project note is cheap, a surfaced credential or private origin is not. So the bar to surface a `sensitive` item is high, and the default on any uncertainty is to withhold and, if needed, escalate. Never silently proceed. ## When to skip - The item is `public`, or `project-internal` with no never-surface marker, and the user asked for exactly it. - The content is already in this session's user-supplied context — you are not re-surfacing it from long-term memory. - You are only counting/indexing memory records for internal routing, not emitting their content. ## Integration - `intent-router` — **orthogonal and upstream**: it decides WHAT to fetch and HOW (strategy, depth, token-budget); the warrant decides WHETHER a correctly-fetched item may be surfaced. Route first, warrant last. - `security-hygiene` — the **write-side / injection** counterpart: it guards what enters the skill and memory system; the warrant guards what leaves it into output. - `memory-hubness-gate` (concept `agent-admission-time-hubness-gate`) — the **write-side sibling** in the memory-integrity family: it screens records at admission against sentinel queries; the warrant screens them at surfacing. - `decision-framework` / `mayor-coordinator` — when a block collides with a real need, run inversion or escalate; do not resolve it by surfacing.