/memory-use-warrant

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

• `i