---
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.