Hafıza OS is a Turkish-language, Markdown-based memory system shared across coding agents. Its Jev integration is unusually disciplined: semantic scoring is optional, while the local system retains responsibility for source eligibility, scope, and changes to canonical memory.

How Jev fits

  • Jev is off by default. In shadow mode the local answer stays in place while scores appear as diagnostics; on mode can reorder eligible source cards. A separate assist path can suggest missing candidates without silently replacing local selection.
  • araclar/jev_retrieval.py checks local candidate eligibility before scoring. It breaks multi-part requests into bounded facets, prioritizes coverage across those facets, and rechecks catalog records after the model call so revoked or changed sources cannot be revived by a stale result.
  • araclar/jev_client.py defines fixed question rubrics and budgets; an unknown provider endpoint requires explicit opt-in. It validates answers and labels provider confidence as unverified metadata, not a permission or an accuracy guarantee.
  • araclar/jev_runtime.py bounds concurrent calls and waiting time. Timeouts and failures degrade to the local selection path rather than authorizing a guess or a write.

What is still unknown

  • The repository includes tests and a proposed A/B/C pilot for real task utility, but its documentation explicitly says utility is not yet measured without observed user outcomes. I inspected the README, design documents, and implementation files; I did not run the code or make Jev calls.
  • A relevance score on a 0–2 rubric is not a calibrated probability that a memory is true, useful, or approved. A retrieved source still needs inspection; user acceptance cannot be inferred from tool output.

The interesting boundary is not the presence of Jev. It is the separation between a model’s suggestion and the durable authority to remember, act, or publish.