explain_inclusion: Making AI Retrieval Auditable by Default

You ask an AI assistant a question. It answers, citing context it has access to. You wonder: why did it surface that particular fact? Why didn't it surface the more recent one? Is the context it used even still accurate?

In most AI memory systems, you cannot find out. The retrieval layer is a black box. Memories appear in the model's working set, the model uses them, and the trail ends there.

We think this is broken. Memplex ships with a feature called explain_inclusion — a trace, returned alongside every retrieval, that explains exactly why each memory was included.

What the trace contains

For every memory in a retrieval response, explain_inclusion returns:

• Routing reason — what made this memory eligible for this request (matched scope rule, project affinity, freshness window)
• Scope rule — which destination policy and source ACL allowed it through
• Confidence score — the score at retrieval time, and the threshold it had to pass
• Lifecycle state — raw, extracted, suggested, accepted, verified, pinned, or revoked
• Channel — which retrieval channel surfaced it (lexical, semantic, graph traversal)
• Source artifact — paragraph-level link to where the memory originated
• Freshness — how recent the source artifact is, and how recently the memory was reviewed
• Token cost — how many tokens this memory consumed in the response

This is invisible 99% of the time. The user is happy with the AI's answer; the trace sits unread. But the 1% of the time the answer is wrong — wrong scope, stale data, leaked sensitive context — the trace is how you debug it.

Why this matters more than it seems

There are three audiences for retrieval auditability:

The end user. When the AI is confidently wrong, the user needs a way to inspect what the AI saw. "Show me what context produced this answer" is a basic right that current AI systems don't grant.

The administrator. In enterprise settings, governance teams need to verify that sensitive content isn't leaking into low-trust destinations. explain_inclusion is the audit log. "Show me every retrieval response that included memories from the 'M&A' scope, in the last 30 days, to non-M&A destinations." That query has to be answerable.

The developer building on top. If you're building an agent or a workflow on top of an AI memory system, you need to debug why your agent did something. The trace is the debug log. Without it, every misbehavior is a guessing game.

Why this should be the default

Most AI products treat auditability as a premium feature — something you get in the enterprise tier, gated behind a sales conversation. We think that's backwards.

Auditability isn't a feature you bolt on when you scale. It's a property of the architecture. If you didn't design the retrieval system to produce traces from day one, retrofitting it later is painful. If you did, exposing them costs nothing.

So Memplex ships explain_inclusion to every user from v0. Free tier, paid tier, enterprise — it's the same trace. The cost of the feature is zero once it exists; the cost of users who can't trust the system is enormous.

How this affects what we ship

Designing for auditability changes the code in real ways. Every routing decision has to be recorded. Every scope check has to log its reasoning. Every confidence threshold has to be inspectable. The graph store has to retain lineage edges even when memories are pruned.

This is a tax we pay on every feature. It's worth it. The product we want to ship is one where the user can verify everything the AI sees about them, not one where they have to trust us.

What we want the industry to standardize

We'd argue for explain_inclusion-style traces becoming a baseline MCP server pattern, the way request logging is a baseline web server pattern. The protocol already supports custom tool definitions; nothing prevents this from becoming standard. We're shipping ours; we'd love for others to follow.