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-02T00:00:00.000Z"
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-18T00:00:00.000Z"
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.