evaluation(memory): assess Jev for duplicate and conflicting Memory candidates

Tracking issue: #1649

Feature description

Run a bounded Jev experiment for semantic duplicate and conflict assessment between a proposed Memory entry and existing entries. Feed the result into the quality/lifecycle design in #1590 before considering a write-path integration.

Priority: P2 — provider experiment supporting the existing Memory quality proposal.

Problem and proposed solution

Exact content hashes catch identical text but not paraphrases. At the same time, two similar statements can be valid for different versions, environments, people, or time periods. Treating every similar statement as a duplicate can destroy useful history.

After an existing extractor or explicit caller produces a candidate, use deterministic retrieval to select a small, authorized comparison pool. Give Jev the candidate, relevant exact entry versions, evidence excerpts, and explicit applicability conditions. Assess relationships such as equivalent under the same conditions, contradictory under the same conditions, complementary, unrelated, or insufficient evidence.

The evaluation output is a proposal/observation. Creation, revision, no-op, retirement, and retention decisions remain with PowerContext's existing mechanisms and the policy being designed in #1590. A newer timestamp alone does not prove that one fact supersedes another. Jev does not generate replacement Memory text.

Acceptance criteria

• Build a labeled set containing exact duplicates, paraphrases, conditional statements, changed requirements, historical facts, entity confusion, and version/time/environment differences in English and Chinese.
• Compare exact-hash and retrieval-similarity baselines, Jev, and a suitable LLM judge. Bound the comparison pool and report both candidate-retrieval misses and relationship-classification errors.
• Measure false-merge/false-conflict rates, duplicate detection, abstention, review burden, latency, and full pipeline cost. Define acceptable error costs before evaluating held-out data.
• Preserve exact entry/version/evidence references and immutable history. Use code for date ordering, revision comparison, and exact equality.
• Provider failure, uncertain relationships, and missing evidence produce an advisory unknown and preserve the normal write path.
• No automatic merge, deletion, retirement, or active-head rewrite is introduced by the experiment. Model suggestions cannot approve themselves or replace lifecycle policy.
• Deliver a reproducible report and a recommendation to #1590, including whether the expected reduction in repeated candidates improves subsequent recall under a fixed budget.

Alternatives considered

Deterministic content normalization and semantic similarity may be adequate for some duplicates. Generative extraction already considers current entries. The experiment should establish whether an additional typed relationship judgment adds measurable value.

Additional context

#1590 owns the broader quality-aware retrieval and reversible Memory lifecycle design. This issue supplies Jev-specific evidence to that design and does not establish a parallel lifecycle or automatic forgetting policy. Coordinate any reviewed evolution proposals with #1422 / #1635.

• Existing extraction interface
• TypeSafe entity-alignment cookbook
• Known limitations, including time comparison

Prepared with AI assistance. This is a proposed evaluation; no write-path quality improvement is claimed.

Related Jev work: reuse bounded provider and evaluation utilities from #1643. The resulting lifecycle recommendations belong in #1590.

Start by reading src/powercontext/builtin/artifacts/memory/extraction.py and the bounded provider and evaluation utilities from #1643, then review the lifecycle constraints in #1590. Build the labeled evaluation and compare the specified baselines and Jev without changing the write path. Done means a reproducible report with error, cost, latency, review-burden, and held-out-data findings plus a recommendation to #1590.