What Jev sees when it ranks agent memory

What a memory tool sends to TypeSafe AI when Jev ranks recall, what a trial still sends, and what Heartwood Memory holds back. Eight questions to ask.

By Heartwood MemoryPublished . Dates are Pacific time.

Jev is a hosted model from TypeSafe AI, so a memory tool that ranks recall with Jev sends two things to TypeSafe AI: the recall query and the text of the candidate memories being ranked. Heartwood Memory sends them only for a hosted organization that has opted in. It sends nothing for a recall if any candidate is above the organization's egress ceiling, is labeled as personal data, or contains something shaped like a secret. Self-hosted Heartwood never calls Jev.

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.

If you are reviewing Jev data privacy for a memory layer, yours or a vendor's, the eight questions below are the ones to ask. Each has Heartwood's answer under it, checked against the code that runs. The row-by-row table of what is sent and what is kept is on the Jev integration page.

What exactly is sent to TypeSafe AI?

One request goes out for each judged recall. It holds the recall query, the text of the candidates being ranked, and a fixed relevance question about each candidate.

Only the leading candidates from Heartwood's own retrieval are sent, not the whole store. A long memory is cut off at a fixed length. Each candidate is labeled by its position in the list. Memory IDs, your organization's name and the calling agent's identity are not part of the request.

The text itself is what Jev reads. If a memory names a customer or a project in plain words, those words are in the request.

Ask any tool: is it the full memory or an excerpt, how many candidates go out, and does the request carry IDs or account names?

Who can turn it on, and is it off by default?

It is off by default. Heartwood turns it on for one organization at a time, after that organization opts in in writing.

The switch lives in operator configuration that the service reads at startup. A recall request or an MCP tool call cannot turn it on, so an agent can't opt your organization in by asking.

Before any send, Heartwood's hosted admission check confirms the organization is on Team or Professional and that a written opt-in and a processor disclosure are on record. The judge is included in Team and Professional.

What stops a sensitive record from being sent?

Four checks run in order. If any one fails, nothing is sent and Heartwood's local ranker orders the whole recall.

  1. Access policy. Records the calling agent isn't cleared to use are removed before anything is ranked. This is true with or without Jev, and it is the subject of Policy before ranking.
  2. The egress ceiling. Each organization has a ceiling: the highest classification allowed to leave. The default is internal, so public and internal records can be sent and confidential and restricted records cannot. One candidate above the ceiling holds the whole recall back.
  3. The personal-data label. If any candidate is labeled as personal data, nothing is sent.
  4. Secrets. The query and every candidate are checked for things shaped like API keys, tokens, private keys and passwords. One match and nothing is sent. Heartwood records which kind of thing matched and how many, never the value.

Heartwood does not drop the one flagged record and send the rest. The query goes out too, and a query that pulled up a restricted record may say something about it. So the query is treated at the level of the most sensitive candidate, and the recall is sent whole or not at all.

After those checks, Heartwood scrubs what is left. It removes email addresses, phone numbers, street addresses and any identifiers your organization has listed. Then it looks again, and if the scrubbed text still contains something shaped like an email address, a phone number, a Social Security number or a payment card number, nothing is sent.

Treat the scrubber as a second safeguard, not a promise. Pattern matching misses things: a name, a diagnosis, an account detail written in ordinary words. Its patterns were first written for our own team's text. The control to rely on is the label. Label a record as personal data, and a recall that includes it sends nothing.

Last, Heartwood's egress check has to return "allowed" for TypeSafe AI, by name, for these exact records. Any other answer keeps the recall local.

Does a trial still send data?

Yes. An organization can start with a trial in which Jev's scores are recorded but the local order is used. The query and the candidates are sent to TypeSafe AI during the trial exactly as they are when the judge is fully on. The only thing a trial holds back is the effect on your results.

Ask this of any tool that offers a shadow or evaluation mode. "It doesn't change your results" and "it doesn't send your data" are different statements.

Who receives the data, and how long is it kept?

TypeSafe AI, Inc., in the US. It is the only outside processor the judge calls. Heartwood calls one TypeSafe endpoint directly, with no gateway or second provider in between.

How long TypeSafe keeps what it receives is set by TypeSafe's terms, not ours. Read them at TypeSafe AI legal. We link to them instead of summarizing them, because they are TypeSafe's to state and they can change.

Heartwood doesn't describe this as a zero-data-retention arrangement. If your organization needs that guarantee, the Jev judge is not for you today. Heartwood's admission check will not turn the judge on for an organization recorded as needing zero retention, or as air-gapped.

Heartwood doesn't use Jev's answers to train or fine-tune any model.

What does Heartwood keep about each judged recall?

A record, in two places: explain_recall for that recall, and a row in Heartwood's hash-chained audit log.

The judge's record holds which ranker ordered the results, whether the recall ran as a trial, the egress decision and the policy it came from, the model, the request ID, a hash of what was sent, and a probability for each memory Jev scored. If the recall fell back to the local ranker, it holds the reason. It holds no query text and no memory text.

A recall that was held back is recorded too, with the reason. So afterwards you can show both what was sent and what was refused.

These are field names, not a published API. Don't build against them yet.

What happens when Jev is slow, down or switched off?

Recall still returns. Heartwood's local ranker runs alongside every judged recall. If Jev doesn't answer in time, returns an error, or returns something malformed, the results come back in the local order and the record says why. A request that timed out is not retried.

Heartwood's operators can also put a hold on the judge for one organization. The next recall uses the local ranker.

A hold or a withdrawn opt-in stops new sends. It cannot pull back what was already sent. That data stays under TypeSafe's terms.

What is never sent?

  • Records the calling agent isn't cleared to use.
  • Any part of a recall where one candidate is above the egress ceiling, is labeled as personal data, or matches a secret pattern.
  • Anything from an organization that hasn't opted in.
  • Anything from Community, self-hosted or air-gapped deployments. The self-hosted core has no Jev code in it.
  • Recalls in modes the judge doesn't cover. Those always use the local ranker.
  • AI-written memories waiting to be saved. Checking them with Jev is planned, not available, so nothing is sent for it.

If none of your memory may leave your environment, self-host. The quickstart runs governed agent memory on your own machine with no outside calls.

What isn't available yet?

Checking AI-written memories against their sources with Jev is planned. It is not available.

We haven't published accuracy, speed or cost figures for the Jev judge. When we do, they will come from Heartwood's pre-registered recall test and will sit next to how each one was measured, on our measurement receipts.

The eight questions, in one place

  1. What exactly is in the request: full text or excerpt, how many candidates, any IDs?
  2. Who can turn it on, and is it off by default?
  3. What stops a sensitive record from being sent, and does one flagged record hold back the rest?
  4. Does a trial or shadow mode send data?
  5. Who receives the data, and whose terms set how long it is kept?
  6. What is recorded about each call, and does the record hold the text?
  7. What does recall return when the model is slow or down, and can a switch-off pull data back?
  8. What is never sent, under any setting?

If your organization is on a hosted plan and wants the judge, ask to turn on the Jev judge. For what Jev is, see TypeSafe's announcement and documentation.

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.

Questions

Does Heartwood Memory send my agent's memories to TypeSafe AI by default?

No. The Jev judge is off by default. Nothing is sent unless your organization is on a hosted Team or Professional plan and has opted in in writing.

Does a trial of the Jev judge send data?

Yes. During a trial the recall query and the candidate memories are sent to TypeSafe AI as they are when the judge is fully on. Only the ordering of your results stays local.

Is this zero data retention?

No. Heartwood Memory doesn't describe it that way. Retention on TypeSafe AI's side follows TypeSafe's own terms.

Does self-hosted Heartwood Memory call Jev?

No. Community, self-hosted and air-gapped deployments never call Jev. Recall there always uses Heartwood's local ranker.

  1. Jev shadow mode still sends your data

    In Jev shadow mode your local ranking is kept and Jev's scores are only recorded. The query and candidate memories still go out to TypeSafe AI.

  2. What to record when a model ranks memory

    An agent memory audit trail for ranked recall: which ranker ordered the results, the egress decision, a hash of the request, and no query or memory text.

  3. Policy before ranking: agent memory and Jev

    In permission-aware RAG, access rules run before ranking, because a reranker reads what it scores. How Heartwood Memory reranks recall with Jev.