Policy before ranking: agent memory and Jev

Access rules should run before ranking, not after. In permission-aware RAG, a ranking model is one more reader of your records: whatever it scores, it has read. When the reranker is an outside model such as Jev, every candidate it scores has left your environment. So filter the candidates by the caller's permissions first, check what remains against a separate rule for what may leave, send only that, and keep a local ranker for every recall that can't be sent. Heartwood Memory works this way.

As of October 1, 2026, Heartwood Memory's Jev judge for recall ranking is available to hosted Team and Professional organizations that opt in; it is off by default.

Should access rules run before or after ranking?

Before. The usual discussion of permission-aware RAG is about the search step: filter the index before the vector search, or filter the hits after it. The same question applies one step later, at the reranker, and it matters more there.

A reranker reads the full text of every candidate you hand it. If you filter after ranking, the model has already read records the caller was never allowed to see. Removing them from the final list changes what the caller sees. It doesn't change what the model read.

Filtering late has two smaller costs. The caller can get fewer results than they asked for, because the removed records took up places. And the scores of the results that remain were produced in the company of records the caller can't see.

Why is a reranker another reader of your records?

Because reading is how it ranks. A local ranker reads candidates inside your own process, so the exposure stays where the records already are. A hosted ranker reads them on someone else's servers.

That makes the reranker a place where access control has to hold, the same as the index and the final answer. For an outside model it is also a place where data leaves. Those are two different questions, and they need two different rules.

Is "allowed to read" the same as "allowed to leave"?

No. The first is about the caller. The second is about the destination.

Take an agent that is cleared to read confidential records. Its recall can properly include them. That says nothing about whether those records may be sent to an outside model. A reviewer who approves an agent's clearance has not approved a new processor.

Heartwood keeps the two rules apart. Access policy decides which records the calling agent may use. A separate egress ceiling, set for the organization, decides the highest classification that may be sent to an outside model. The default ceiling is internal. A recall can pass the first rule and fail the second, and when it does, it is ranked locally.

How does Heartwood Memory rerank recall with Jev?

In this order, for an organization that has opted in:

1. Policy filters the candidates. Heartwood removes every record the calling agent isn't cleared to use: another tenant's records, records above the agent's clearance, records gated to a role or attribute the agent doesn't have, and private records the agent didn't create. Ranking only ever sees what is left.
2. The egress ceiling and labels are checked. If any candidate is above the organization's ceiling, is labeled as personal data, or contains something shaped like a secret, nothing is sent and the local ranker orders the whole recall.
3. What remains is scrubbed and checked again. Email addresses, phone numbers and street addresses are removed. If the text still looks sensitive, nothing is sent. This is a second safeguard, not a promise; the labels in step 2 are the control to rely on.
4. The egress check names the provider. The request goes out only if Heartwood's egress check allows TypeSafe AI, by name, for these exact records.
5. Jev and the local ranker run side by side. If Jev answers in time, its order is used; during a trial its scores are only recorded. If it is slow, unavailable or returns something malformed, recall returns in the local order.
6. The call is recorded. explain_recall and the hash-chained audit log show which ranker ordered the results, the egress decision, and a hash of what was sent.

Step 1 is not a Jev feature. It is how Heartwood's recall works in every deployment, including self-hosted ones that never call Jev. Steps 2 to 6 apply only to hosted organizations that have opted in to the judge. What is in the request and who receives it is covered in What Jev sees when it ranks agent memory and on the Jev integration page.

Why hold back the whole recall instead of the one record?

Because the query is sent too. A query that pulled up a restricted record may itself say something about that record. Heartwood treats the query at the level of the most sensitive candidate, so one candidate over the ceiling means the query can't go either.

There is a practical reason as well. A list in which some candidates were scored by Jev and one was not has no honest order. Ranking the whole recall locally gives the caller one consistent result.

What does the caller see when records are filtered out?

A normal result. Filtered records are not returned, and nothing in the result list marks where one was removed. From version 0.2.9, the vector search does not score them either. The number of records that policy removed is written to the audit log for the operator.

How can I check this myself?

The policy-first rule is in Heartwood's source-available core, and you can run the checks. The public repository has a test that hands recall a ranker that records what it was given, then asserts it received only the records the caller could see. The public trust benchmark has a "Policy before ranking" probe that tries to pull a confidential record with a query aimed at it. Our measurement receipts explain how we publish those results.

Two limits on that. The public suite checks the self-hosted core in a single trust domain; it doesn't claim a multi-tenant deployment. And the hosted Jev judge is not in the public repository, so steps 2 to 6 above are described here, not shipped there for you to run.

What should I ask of any reranker?

These apply to any pipeline, hosted or local, ours included.

1. Does access policy run before the reranker sees candidates, or after?
2. Is "may this caller read it" a separate rule from "may this leave"?
3. If one candidate can't be sent, what happens to the rest, and to the query?
4. What ranks the recall when the outside model can't be used?
5. Afterwards, can you show which ranker ordered a given recall?

To try policy-gated recall on your own machine, start with the quickstart. It runs governed agent memory with the local ranker and no outside calls. Checking AI-written memories with Jev is planned and not available yet.

Jev is a model from TypeSafe AI, Inc. Heartwood Memory is made by Edukas Solutions LLC and is not affiliated with or endorsed by TypeSafe AI.