[Feature]: Attribute recalled-memory utility after verified outcomes #3214

Problem

LoopX can record whether an agent says recalled memory was applied, ignored, or refuted. The current reward-memory dogfood path can then map applied directly to a hit. That is useful lineage, but it does not establish that the memory improved the verified work outcome.

These signals need to remain distinct:

• retrieval relevance;
• application decision;
• task or effect outcome;
• marginal memory utility;
• memory lifecycle and authority.

Otherwise a frequently retrieved but harmful memory can be reinforced, and a global evaluator can accidentally become an unbounded supervisor.

Proposal

Add a provider-neutral, post-outcome memory utility attribution contract under the existing reward-memory capability:

1. Bind the exact recall/application receipt to a later verified outcome.
2. Let an optional, default-off memory_utility_evaluator emit a typed, append-only observation.
3. Reduce observations deterministically into a scoped, bounded utility projection.
4. Keep semantic relevance as the retrieval anchor; use utility only as a bounded modifier.
5. Let provider adapters optionally apply/read back a rank-prior update and return a receipt.
6. Fail open: evaluator or provider failure must never block or change the main work result.

The evaluator is proposal-only. It must not select todos, gate work, spend another lane's quota, rewrite memory, or grant recalled content authority.

Attribution rules

• applied + success is not sufficient evidence for helpful.
• When several memories were used, record set-level utility unless evidence distinguishes individual contribution.
• Explicit user correction, deterministic effect evidence, or controlled replay is stronger than model inference.
• Weak inference may be retained as an observation without changing a strong ranking prior.
• Negative utility attenuates or quarantines retrieval; it does not delete or rewrite memory.
• Retried evaluation must be idempotent.
• Scope must include agent/project/corpus/surface boundaries, plus the retrieval or policy snapshot used at execution time.

OpenViking fit

OpenViking already provides useful seams:

• context/search results carry stable entry URIs, scores, and a response digest;
• Agent Evolution links explicitly read Experiences to trajectories and aggregates terminal outcomes;
• the training domain exposes rollout evaluation and policy_snapshot_id;
• the current training RFC models experience memory as a policy set.

However, current Agent Evolution lineage shows consumption plus a shared final outcome, not per-memory causal credit. The current hotness score is access frequency/recency, not task utility, and there is no first-class external utility/Q-value update API.

The smallest safe integration is therefore a LoopX sidecar projection that consumes OpenViking identity/lineage read-only. A later OpenViking adapter may apply a bounded rank prior only after an explicit provider contract exists. Do not encode utility in memory prose or overload active_count/hotness.

Smallest useful slice

• Define memory_utility_observation_v0 over existing recall/application receipts and verified outcome refs.
• Repair Stage 5 semantics so applied is not automatically a utility hit.
• Add an idempotent deterministic reducer and read-only utility projection.
• Add fixtures for harmful-applied memory, ambiguous multi-memory use, stale scope, user correction, duplicate delivery, and evaluator failure.
• Keep OpenViking integration read-only in v0; document future rank-prior/update receipt requirements.

Acceptance criteria

• Recall relevance, application, outcome, and utility are separate typed fields.
• No per-memory credit is assigned from a trajectory-level reward when attribution is ambiguous.
• Utility updates are scoped, bounded, evidence-tiered, and idempotent.
• Semantic relevance remains an anchor; utility cannot make unrelated memory rank globally.
• The main lane is unchanged when evaluation is disabled, unavailable, or malformed.
• Public packets contain opaque refs and compact evidence only, never raw memory or transcripts.
• Recalled memory remains observational and cannot grant authority.
• OpenViking policy/retrieval snapshot lineage is preserved where available.
• Provider writeback, if added later, has explicit effect and readback receipts.

Non-goals

• An omniscient global leader agent.
• Automatic memory rewriting or deletion.
• Cross-project or cross-user utility transfer by default.
• A production reinforcement-learning claim without controlled evaluation.
• Reviewing every trajectory on every heartbeat.

Related work

This is adjacent to #2353, but not a duplicate: that issue concerns loop reflection and retention; this issue concerns post-outcome credit for already recalled memory.

LoopX references:

• Reward Memory Architecture v0
• Peer Supervisor v0
• Agent IM + OpenViking Collaboration v0

OpenViking and research references:

• OpenViking Agent Evolution API
• OpenViking experience-memory training RFC #2533
• OpenViking on-policy/versioning RFC #2277
• MemRL
• Memory-R2
• Mem-π