JevMemoryGate reviews a candidate fact for lasting value and factual conflict before a memory write. It recommends admission; your application’s memory workflow owns writes, updates and deletion.
Example: remember a preference without overwriting an older fact silently
A user explicitly asks for concise answers from now on. That may be worth retaining. But if a candidate comes from an undated note contradicting an existing preference, first check its source and whether it is an explicit update. JEV separately assesses lasting value and conflict without evidence of an update. Both checks must pass; high value cannot compensate for conflict. Code checks ownership before any model request.1. Construct a candidate with ownership and provenance
owner from authenticated identity. Describe actual source evidence in source. Supplying a source string does not verify provenance. Do not mix in another user’s memory.
2. Review before writing
judge as in Application component setup. Compose this Mono into the write workflow and observe results before enforcement. Only PASS means both checks passed; host authorization, provenance and idempotency checks still apply.
Run and verify
SetJEV_CP using the example build instructions, then run:
Limits and errors
The candidate and existing facts must all belong to the explicit owner; otherwise an argument error occurs before any model call. The built-indurable condition expects true and conflict expects false, with example 0.2/0.8 thresholds. Define custom admission criteria with JevJudge.
This component does not intercept MemoryFlush or other write tools. Invoke it at the real write boundary. A denial never deletes old memory, and context compaction does not authorize long-term memory writes. Timeout and cancellation follow the Judge contract.