MemFuse: Multi-Source Memory Fusion from Fragmented Observations

# MemFuse: Multi-Source Memory Fusion from Fragmented Observations
Source: [https://arxiv.org/html/2608.18704](https://arxiv.org/html/2608.18704)
Yuanfa LiWenhao WuThanks:Work done during internship\.Xule LiuZhi WangKun Shao\\corresponding

###### Abstract

Long\-term memory is essential for agents that operate across extended interactions, yet existing memory systems and benchmarks predominantly focus on single\-source textual histories\. In realistic settings, however, relevant information is often fragmented across applications and devices, as well as across users and time, requiring agents to integrate dispersed observations into coherent episodic memories while preserving their source provenance\. To address these gaps, we introduceMemFuseBench, a benchmark for*multi\-source memory fusion*\. MemFuseBench is built with a Scene\-to\-Sensor pipeline that synthesizes controllable scenarios into source\-tagged observations, evidence\-grounded questions, and adversarial distractors\. It enables systematic evaluation of temporal reasoning, cross\-source evidence fusion, and robustness to noise\. We further proposeMemFuse, a structured memory system that preserves source\-level evidence in event\-layer atomic memory and organizes related atomic events into cluster\-layer fused memory within a causal fusion graph\. During retrieval, MemFuse retrieves and organizes related evidence fragments while maintaining traceability to original source events\. Experiments on MemFuseBench show that MemFuse achieves the best overall performance among the evaluated memory systems under all three LLM settings and consistently improves performance on questions requiring cross\-source evidence fusion\.

Code—https://github\.com/Darwin\-Agent/Mi\-Memory/tree/master/MemFuse

## Introduction

Long\-term memory systems have received growing attention as agents are expected to maintain useful context across extended interactions\. Existing systems store past interactions as records, summaries, or structured memories for retrieval\([15](https://arxiv.org/html/2608.18704#bib.bib1);[4](https://arxiv.org/html/2608.18704#bib.bib8);[22](https://arxiv.org/html/2608.18704#bib.bib9);[10](https://arxiv.org/html/2608.18704#bib.bib6);[7](https://arxiv.org/html/2608.18704#bib.bib10);[1](https://arxiv.org/html/2608.18704#bib.bib11);[17](https://arxiv.org/html/2608.18704#bib.bib12);[11](https://arxiv.org/html/2608.18704#bib.bib27)\), and work well when relevant context forms a coherent history\. As user expectations grow, however, agents need to remember not only what users explicitly tell them, but also useful observations from devices, applications, and other users\. In this setting, the same underlying episode may then be represented by fragmented events from different origins, making it necessary to integrate complementary observations without losing their sources\. We call this memory\-level problem*multi\-source memory fusion*: retrieving and integrating distributed semantic events while preserving event\-layer provenance\.

Existing memory benchmarks mainly evaluate conversational recall, temporal updates, or long\-context reasoning over interaction histories\([14](https://arxiv.org/html/2608.18704#bib.bib18);[20](https://arxiv.org/html/2608.18704#bib.bib19);[18](https://arxiv.org/html/2608.18704#bib.bib22);[8](https://arxiv.org/html/2608.18704#bib.bib23);[24](https://arxiv.org/html/2608.18704#bib.bib24)\)\. Recent benchmarks consider heterogeneous digital traces and multimodal evidence\([3](https://arxiv.org/html/2608.18704#bib.bib25);[2](https://arxiv.org/html/2608.18704#bib.bib26)\), but they do not specifically test whether memory systems can link fragmented, source\-tagged events into traceable evidence for fusion\-oriented questions\. It therefore remains difficult to test whether a system can recover complementary observations from different origins\.

To address these challenges, we first introduceMemFuseBench, a benchmark for multi\-source memory fusion\. Starting from controllable scenarios, its Scene\-to\-Sensor pipeline generates source\-tagged observations, evidence\-grounded questions, and adversarial distractors\. Figure[1](https://arxiv.org/html/2608.18704#Sx1.F1)illustrates a question requiring evidence from multiple origins while ignoring a plausible distractor\. The benchmark contains 357 questions over 7,823 events across six diagnostic categories\.

To further support multi\-source memory fusion, we proposeMemFuse, a graph\-structured memory system that preserves event\-layer memory as the evidence layer and organizes related events into cluster\-layer memory within a causal fusion graph\. At retrieval time, MemFuse uses agentic search to recover both compact cluster memories and their traceable source events\.

In summary, our contributions are: \(1\) identifying multi\-source memory fusion as a memory\-level research problem over fragmented, source\-tagged events; \(2\) introducing MemFuseBench, a fusion\-centric benchmark for this setting, featuring six diagnostic categories and answer checklists, supported by a scalable LLM\-based synthesis and reviewer\-corrector validation pipeline; \(3\) proposing MemFuse, a structured memory system that preserves source\-level evidence in event\-layer atomic memory and fuses related events into cluster\-layer memory within a causal fusion graph; and \(4\) validating MemFuseBench and MemFuse through experiments across multiple models, where MemFuse achieves the best Overall score among the evaluated retrieval and memory systems under all three LLM settings\.

![Refer to caption](https://arxiv.org/html/2608.18704v1/memfusebench_instance.png)Figure 1:A MemFuseBench instance requiring fusion across a household conversation, work calendar, and phone call, while rejecting a plausible distractor on the wrong day\.
## Related Work

##### Long\-Term Agent Memory\.

Agent\-memory systems store past interactions as records, summaries, linked notes, or hierarchical memory units for later retrieval\([16](https://arxiv.org/html/2608.18704#bib.bib15);[15](https://arxiv.org/html/2608.18704#bib.bib1);[27](https://arxiv.org/html/2608.18704#bib.bib3);[13](https://arxiv.org/html/2608.18704#bib.bib2);[19](https://arxiv.org/html/2608.18704#bib.bib4);[4](https://arxiv.org/html/2608.18704#bib.bib8);[22](https://arxiv.org/html/2608.18704#bib.bib9);[26](https://arxiv.org/html/2608.18704#bib.bib5);[10](https://arxiv.org/html/2608.18704#bib.bib6);[7](https://arxiv.org/html/2608.18704#bib.bib10);[1](https://arxiv.org/html/2608.18704#bib.bib11);[17](https://arxiv.org/html/2608.18704#bib.bib12)\)\. Recent work also introduces structured or graph\-based memory to connect related experiences and support multi\-step retrieval\([9](https://arxiv.org/html/2608.18704#bib.bib13);[21](https://arxiv.org/html/2608.18704#bib.bib14);[23](https://arxiv.org/html/2608.18704#bib.bib7);[11](https://arxiv.org/html/2608.18704#bib.bib27)\)\. These systems improve organization over flat logs, but they mainly assume conversational or interaction histories rather than fragmented observations across different sources\.

##### Memory Benchmarks\.

LoCoMo, LongMemEval, and MemBench evaluate conversational recall, temporal updates, abstention, and long\-context reasoning\([14](https://arxiv.org/html/2608.18704#bib.bib18);[20](https://arxiv.org/html/2608.18704#bib.bib19);[18](https://arxiv.org/html/2608.18704#bib.bib22)\)\. EverMemBench and GroupMemBench extend this line to long\-term interactive memory and multi\-party conversations\([8](https://arxiv.org/html/2608.18704#bib.bib23);[24](https://arxiv.org/html/2608.18704#bib.bib24)\)\. LifeBench and SMMBench move closer to realistic settings by using heterogeneous digital traces or independently originated multimodal evidence\([3](https://arxiv.org/html/2608.18704#bib.bib25);[2](https://arxiv.org/html/2608.18704#bib.bib26)\)\. They broaden the input sources for memory evaluation, but do not center the task design on linking, fusing, and tracing distributed event fragments\.

##### Multi\-Source memory Fusion\.

Event\-centric resources and lifelogging systems organize heterogeneous records into event structures for temporal or commonsense reasoning\([5](https://arxiv.org/html/2608.18704#bib.bib17);[25](https://arxiv.org/html/2608.18704#bib.bib16);[6](https://arxiv.org/html/2608.18704#bib.bib21)\)\. Multisensor fusion studies how signals or decisions from multiple sensors are registered, estimated, or combined\([12](https://arxiv.org/html/2608.18704#bib.bib20)\)\. These research directions are related to multi\-source evidence, but they are not concerned with agent memory: none addresses how a long\-term memory system should preserve atomic provenance while grouping and retrieving fragmented observations for downstream question answering\.

## MemFuseBench

Most memory benchmarks evaluate recall within a single conversational history\. Recent ones broaden the input to heterogeneous or multimodal traces, but none isolates the core difficulty of reasoning over evidence fragmented across devices, applications, users, and time, where no single record suffices\. Evaluating this demands two properties existing benchmarks lack: source\-level evidence annotations that expose provenance, and questions whose answers genuinely depend on stitching fragments from more than one source\. We therefore build MemFuseBench, pairing source\-tagged event streams with evidence\-grounded questions answerable only by fusing fragmented atomic events across sources, alongside adversarial distractors that penalize shortcut retrieval\.

### Dataset Construction

Each MemFuseBench instance contains source\-specific event streams and a question with its reference answer and an answer checklist\. We construct these instances with a Scene\-to\-Sensor pipeline that turns controllable latent scenarios into source\-specific observations, evidence\-grounded questions, and adversarial non\-evidence events\. Reviewer\-corrector validation checks and repairs intermediate artifacts for consistency, evidence support, and answer preservation under injected distractors\.

![Refer to caption](https://arxiv.org/html/2608.18704v1/memfusebench_construction_framework.png)Figure 2:Overall MemFuseBench construction framework\. The left panel summarizes theconstruction pipeline, whose six stages are organized into three phases: event construction, QA generation, and noise injection\. The right panel showsreviewer\-corrector validation, where candidate samples are checked, revised, and iterated until the final accepted sample is produced\.##### Construction Pipeline\.

The core construction method isScene\-to\-Sensorgeneration, which builds each instance by top\-down narrowing rather than directly generating question\-answer pairs\. It first fixes a high\-level ground truth—stable personas and a causally linked scenario timeline \(*what happens in the world*\)—then projects each latent activity into concrete, timestamped, source\-specific event streams \(*what each device observes*\), from which the evidence\-grounded questions are derived\. Figure[2](https://arxiv.org/html/2608.18704#Sx3.F2)summarizes the framework, which is organized into six stages:

1. 1\.Persona Construction\.Sample stable personas and their shared context—schedules, relationships, and multi\-device inventories with observable modalities—into a persona\-source graph, which constrains all later stages\.
2. 2\.Scenario Construction\.Organize the personas’ daily activities into causally linked storyline events grouped by episode\. This timeline is the latent ground truth, later refracted into source\-specific events\.
3. 3\.Event Stream Synthesis\.Render the scenario into source\-specific events, interleaving routine, periodic, noise, and conflict events so each source gives only a partial view\. This yields a timestamped event stream\.
4. 4\.Category\-Spanning Question Generation\.Derive questions spanning the six diagnostic categories in Table[1](https://arxiv.org/html/2608.18704#Sx3.T1), producing a QA pool of questions, reference answers, answer checklists\.
5. 5\.QA Filtering\.Filter the pool to remove semantic duplicates, commonsense shortcuts, and items whose labeled evidence cannot support the reference answer, retaining only answerable, evidence\-supported, non\-duplicative items\.
6. 6\.Adversarial Noise Injection\.Inject semantically similar distractors to complicate retrieval while keeping the gold evidence set auditable and unchanged, so finalized samples contain both gold evidence and plausible non\-evidence distractors\.

##### Validation Protocol\.

As the pipeline builds each instance stage by stage in a top\-down manner, an inconsistent persona\-source graph can propagate errors to every later artifact\. To prevent this, MemFuseBench appliesreviewer\-corrector validationto every intermediate artifact before it enters the next stage: a*reviewer*flags structural, semantic, and consistency issues with stage\-specific prompts, a*corrector*repairs them, and this review\-correction process iterates until the reviewer finds no remaining issues\.

The criteria are stage\-specific and focus on two targets\. For the first four stages, validation targets*internal coherence*: the persona\-source graph, scenario timeline, event stream, and QA pool must each be self\-consistent and aligned with the artifacts upstream\. For Adversarial Noise Injection, validation instead targets*answer preservation*: injected distractors must complicate retrieval without altering the gold evidence set or reference answers\.

We further conduct a model\-guided verification pass: given the full context, GPT\-5\.5, Claude Opus 4\.6, and Gemini 3\.1 Pro each independently answer and evaluate every question, and the samples on which they disagree are manually inspected and corrected\. This procedure results in at least one revision for approximately 20% of the 357 QA instances\.

### Dataset Analysis

This pipeline yields MemFuseBench with six scenario datasets, each paired with evidence\-grounded questions spanning six diagnostic categories\. On average, a scenario contains 1,303\.8 atomic events and 110\.6k tokens under the Gemini 3\.1 Flash Lite tokenizer\. Table[1](https://arxiv.org/html/2608.18704#Sx3.T1)summarizes the resulting 357 questions; each question requires evidence from 9\.4 distinct events on average\.

Table 1:Per\-category statistics of the current MemFuseBench release\. Short labels in parentheses are used in result tables\. \#Q is the number of questions; Avg\. Events is the average number of distinct evidence events required per question\.

## MemFuse

We target more realistic settings where relevant evidence is fragmented across devices, applications, users, and time, requiring a memory system that preserves the provenance of each observation while grouping and reasoning over related fragments\. MemFuse separates provenance preservation from memory aggregation: event\-layer atomic memory preserves source evidence, cluster\-layer fused memory summarizes related evidence, and the causal fusion graph connects the two memory layers\. Built on this structure, MemFuse stores incoming atomic events, groups related events into fused memory, proposes validated fusion operations to construct the graph, and performs fusion\-aware retrieval for evidence\-grounded answer generation\. Figure[3](https://arxiv.org/html/2608.18704#Sx4.F3)gives the overall architecture\.

### Preliminaries

Given a stream of normalized, source\-tagged atomic eventsℰ=\{ei\}i=1n\\mathcal\{E\}=\\\{e\_\{i\}\\\}\_\{i=1\}^\{n\}, MemFuse organizes memory in two layers:

- •Event\-layer atomic memoryℳE\\mathcal\{M\}\_\{E\}: each event is stored as an immutable and indexed memory that retains its provenance for later grounding\.
- •Cluster\-layer fused memoryℳV\\mathcal\{M\}\_\{V\}: related events are grouped into compact retrieval units, each aFusedNodev∈𝒱v\\in\\mathcal\{V\}defined by a member setμ⁡\(v\)⊆ℰ\\mu\(v\)\\subseteq\\mathcal\{E\}, a fused summaryyvy\_\{v\}as retrieval entry point, and back\-pointers that keepvvgrounded in its source events\.

The overall memory state isℳ=\{ℳE,ℳV,𝒢\}\\mathcal\{M\}=\\\{\\mathcal\{M\}\_\{E\},\\mathcal\{M\}\_\{V\},\\mathcal\{G\}\\\}, where𝒢\\mathcal\{G\}is the causal fusion graph connecting the two layers\. Given a queryqq, MemFuse retrieves a relevant context𝒞q\\mathcal\{C\}\_\{q\}fromℳ\\mathcal\{M\}, and the task is formalized asa=Assistant⁡\(𝒞q,q\)a=\\mathrm\{Assistant\}\(\\mathcal\{C\}\_\{q\},q\)\.

![Refer to caption](https://arxiv.org/html/2608.18704v1/memfuse_framework.png)Figure 3:Overall MemFuse framework\. Left: online construction from source\-tagged events through agentic fusion\. Middle: a dual\-layer causal fusion graph connecting atomic events and fused memories\. Right: fusion\-aware retrieval that returns traceable event\-layer evidence for grounded answering\.
### Agentic Memory Fusion

MemFuse builds the dual\-layer memory online through an agentic fusion pipeline with four stages:*candidate retrieval*,*fusion planning*,*rule validation*, and*graph commitment*\. For each incoming event, MemFuse stores it in the atomic memory, retrieves related atomic events and fused memories as candidates, lets a fusion agent gather further evidence and propose how to fuse the event, and validates and commits the accepted operations to the dual\-layer causal fusion graph described next\. We describe each stage below\.

##### Candidate Retrieval\.

Given an incoming atomic eventeie\_\{i\}, MemFuse retrieves a candidate set𝒞i=𝒞iatom∪𝒞ifused\\mathcal\{C\}\_\{i\}=\\mathcal\{C\}^\{\\mathrm\{atom\}\}\_\{i\}\\cup\\mathcal\{C\}^\{\\mathrm\{fused\}\}\_\{i\}of potentially related atomic events and fused memories\. This bounds the initial decision scope to a small set, avoiding a full memory scan while still exposing complementary evidence across sources\.

##### Agentic Fusion Planning\.

A fusion agent then decides how to fuseeie\_\{i\}in two steps: it first gathers related evidence through agentic information\-seeking, and then proposes the corresponding fusion operations\. To provide sufficient context for fusion decisions, MemFuse maintains a*session context*𝒮i=\(𝒵iacc,𝒵itmp\)\\mathcal\{S\}\_\{i\}=\(\\mathcal\{Z\}^\{\\mathrm\{acc\}\}\_\{i\},\\mathcal\{Z\}^\{\\mathrm\{tmp\}\}\_\{i\}\)with two complementary memory zones: the accumulation zone𝒵iacc\\mathcal\{Z\}^\{\\mathrm\{acc\}\}\_\{i\}, a sliding window over previously processed events, and the temporary zone𝒵itmp\\mathcal\{Z\}^\{\\mathrm\{tmp\}\}\_\{i\}, containing the current eventeie\_\{i\}and its candidate set𝒞i\\mathcal\{C\}\_\{i\}\. Together,𝒮i\\mathcal\{S\}\_\{i\}provides compact access to prior context and local evidence\.

Conditioned on𝒮i\\mathcal\{S\}\_\{i\}, the fusion agent performs a bounded information\-seeking trajectory, represented by the tool\-call history

τi\(t\)=\(\(ui\(1\),ri\(1\)\),…,\(ui\(t\),ri\(t\)\)\),ui\(t\)∈𝒰tools,\\tau\_\{i\}^\{\(t\)\}=\\left\(\(u\_\{i\}^\{\(1\)\},r\_\{i\}^\{\(1\)\}\),\\ldots,\(u\_\{i\}^\{\(t\)\},r\_\{i\}^\{\(t\)\}\)\\right\),\\qquad u\_\{i\}^\{\(t\)\}\\in\\mathcal\{U\}\_\{\\mathrm\{tools\}\},whereui\(t\)u\_\{i\}^\{\(t\)\}is the selected tool andri\(t\)r\_\{i\}^\{\(t\)\}its returned result\. The tool set𝒰tools\\mathcal\{U\}\_\{\\mathrm\{tools\}\}containsSearchMemory, which expands the candidate set with newly retrieved atomic events and fused memories, andGetPackMembers, which returns the member atomic events of a candidate fused memory\. Starting fromτi\(0\)=∅\\tau\_\{i\}^\{\(0\)\}=\\emptyset, at each turn the agent picks the next toolui\(t\)=LLMθ​\(𝒮i,τi\(t−1\)\)u\_\{i\}^\{\(t\)\}=\\mathrm\{LLM\}\_\{\\theta\}\(\\mathcal\{S\}\_\{i\},\\tau\_\{i\}^\{\(t\-1\)\}\)and executes it to obtainri\(t\)=Exec⁡\(ui\(t\)\)r\_\{i\}^\{\(t\)\}=\\mathrm\{Exec\}\(u\_\{i\}^\{\(t\)\}\), iteratively accumulating evidence across sources\.

Once sufficient evidence has been gathered, the agent proposes howeie\_\{i\}should be fused into the cluster\-layer memory by terminating the trajectory with a call toSubmitFusionPlan, yielding the fusion plan𝒫i\\mathcal\{P\}\_\{i\}:

𝒫i=SubmitFusionPlan​\(𝒮i,τi\(Ji\)\)=\(oi\(1\),…,oi\(Li\)\),\\mathcal\{P\}\_\{i\}=\\textsc\{SubmitFusionPlan\}\\left\(\\mathcal\{S\}\_\{i\},\\tau\_\{i\}^\{\(J\_\{i\}\)\}\\right\)=\\left\(o\_\{i\}^\{\(1\)\},\\ldots,o\_\{i\}^\{\(L\_\{i\}\)\}\\right\),whereJiJ\_\{i\}is the number of tool turns before submission,LiL\_\{i\}the number of operations, and eachoi∈𝒪o\_\{i\}\\in\\mathcal\{O\}\. The operation set𝒪\\mathcal\{O\}comprisesCreateEdge,CreateFusionNode,UpdateFusionNode,RemoveMember, andNoOp, which respectively create an edge, create or update a fused node, remove a member from fused node, or keep the event atomic\.

##### Rule Validation and Graph Commitment\.

Before the proposed operations are applied, a rule\-based validator checks the consistency and validity of each operation against the memory storage structure\. If any constraint is violated, the whole plan is rejected rather than partially committed, preventing malformed outputs from corrupting persistent memory\. The accepted operations are then applied to the dual\-layer causal fusion graph, materializing the fusion ofeie\_\{i\}into the cluster\-layer memory, which we detail next\.

### Dual\-Layer Causal Fusion Graph

Beyond grouping related atomic events intoFusedNodeobjects, MemFuse connects memories with typed relations that support cross\-source reasoning\. These relations form a dual\-layer causal fusion graph, which serves as the persistent structure for committing validated fusion operations\. We first define the graph and its relation types, then describe the commitment steps\.

##### Graph Definition\.

With𝒩=ℰ​∪˙​𝒱\\mathcal\{N\}=\\mathcal\{E\}\\,\\dot\{\\cup\}\\,\\mathcal\{V\}the disjoint union of atomic\-event nodesℰ\\mathcal\{E\}andFusedNodeobjects𝒱\\mathcal\{V\}, the graph is defined as𝒢=\(𝒩,ℛBelong,ℛCausal,ℛSemantic\),\\mathcal\{G\}=\\left\(\\mathcal\{N\},\\mathcal\{R\}\_\{\\textsc\{Belong\}\},\\mathcal\{R\}\_\{\\textsc\{Causal\}\},\\mathcal\{R\}\_\{\\textsc\{Semantic\}\}\\right\),withℛBelong⊆ℰ×𝒱\\mathcal\{R\}\_\{\\textsc\{Belong\}\}\\subseteq\\mathcal\{E\}\\times\\mathcal\{V\},ℛCausal⊆ℰ×ℰ\\mathcal\{R\}\_\{\\textsc\{Causal\}\}\\subseteq\\mathcal\{E\}\\times\\mathcal\{E\}, andℛSemantic⊆𝒩×𝒩\\mathcal\{R\}\_\{\\textsc\{Semantic\}\}\\subseteq\\mathcal\{N\}\\times\\mathcal\{N\}\.

##### Typed Relations\.

ABelongedge\(e,v\)\(e,v\)marks eventeeas a member ofFusedNodevv, giving the member setμ⁡\(v\)=\{e∈ℰ\|\(e,v\)∈ℛBelong\}\\mu\(v\)=\\\{e\\in\\mathcal\{E\}\|\(e,v\)\\in\\mathcal\{R\}\_\{\\textsc\{Belong\}\}\\\}\. Fused summaries thus serve only as retrieval abstractions, while answers stay grounded in the source\-tagged events recovered throughμ⁡\(v\)\\mu\(v\)\. A directedCausaledge\(ei,ej\)\(e\_\{i\},e\_\{j\}\)links atomic events in causal order, stored with direction but traversable either way\. ASemanticedge connects semantically related nodes—atomic, fused, or both—and carries a similarity scoreωS​\(xi,xj\)∈\[0,1\]\\omega\_\{S\}\(x\_\{i\},x\_\{j\}\)\\in\[0,1\]for thresholded retrieval\.

##### Graph Construction\.

Committing the accepted operations𝒫i\\mathcal\{P\}\_\{i\}materializes these edges: newly created or updatedFusedNodeobjects induce theirBelongedges by membership and are embedded and indexed for retrieval;Causaledges fromCreateEdgeoperations are committed after endpoint and type validation; and aSemanticedge is added online whenever an inserted node’s embedding similarity to an existing node exceedsρS\\rho\_\{S\}\(0\.80\.8in our experiments\)\. These typed relations form the traversal structure used by fusion\-aware retrieval\.

### Fusion\-Aware Retrieval

Given a query, MemFuse returns a memory set through an agentic retrieval loop\. At each step, a retrieval agent issues a search call that returns a top\-kkset of event candidates, and it keeps searching and accumulating until it judges the collected evidence sufficient\. It then selects the final top\-kkevents from the accumulated candidates to form the returned context𝒞q\\mathcal\{C\}\_\{q\}\. The agentic retrieval loop combines query planning, seed retrieval, graph expansion, ranking, and assembly, which we describe below\.

##### Query Planning and Seed Retrieval\.

Given a queryqqwith timestamptqt\_\{q\}and requester identityuqu\_\{q\}, MemFuse issues a search call with query\-planning parameterspqp\_\{q\}, which include a rewritten query and optional retrieval constraints such as temporal or source filters\. Conditioned onpqp\_\{q\}, MemFuse performs dense \(vector\) and sparse \(BM25\) retrieval over the shared index of atomic events and fused memories, plus temporal retrieval when needed\. The ranked lists are combined by reciprocal rank fusion into a seed scorerseed​\(x\|q,pq\)r\_\{\\mathrm\{seed\}\}\(x\|q,p\_\{q\}\), and the seed set𝒮q\\mathcal\{S\}\_\{q\}keeps the top\-KseedK\_\{\\mathrm\{seed\}\}candidates with positive scores\.

##### Typed Graph Expansion\.

Since direct retrieval may recover only one fragment of the required evidence, MemFuse expands the seed nodes into a larger candidate set𝒳q\\mathcal\{X\}\_\{q\}through theBelong,Causal, andSemanticrelations of the causal fusion graph:𝒳q=Expand𝒢⁡\(𝒮q;pq\)\\mathcal\{X\}\_\{q\}=\\operatorname\{Expand\}\_\{\\mathcal\{G\}\}\\left\(\\mathcal\{S\}\_\{q\};p\_\{q\}\\right\), with a policy that depends on the seed type\.

For an atomic seed, MemFuse traverses nearby bidirectionalCausaledges and high\-confidenceSemanticedges, and followsBelongedges from the seed or an atomic neighbor within one causal hop to expose the corresponding member events\. For a fused seed, MemFuse first follows reverseBelongedges to its member events and then applies the same bounded causal and semantic expansion from those members\. In both cases, traversal is capped by the hop limit, the semantic threshold, and a budget for fused\-node expansion\.

For each candidatex∈𝒳qx\\in\\mathcal\{X\}\_\{q\}, MemFuse retains an expansion traceξq​\(x\)=\(sx,πx,dx\)\\xi\_\{q\}\(x\)=\(s\_\{x\},\\pi\_\{x\},d\_\{x\}\)recording the originating seedsx∈𝒮qs\_\{x\}\\in\\mathcal\{S\}\_\{q\}, the typed relation pathπx\\pi\_\{x\}, and its distancedxd\_\{x\}\.

##### Candidate Ranking and Evidence Construction\.

The expanded candidates are reranked using their query relevance, temporal consistency, and graph\-expansion traces:

𝒳^q=TopKKrank⁡\(𝒳q;s⁡\(x\|q,pq,ξq​\(x\)\)\)\.\\widehat\{\\mathcal\{X\}\}\_\{q\}=\\operatorname\{TopK\}\_\{K\_\{\\mathrm\{rank\}\}\}\\left\(\\mathcal\{X\}\_\{q\};s\(x\|q,p\_\{q\},\\xi\_\{q\}\(x\)\)\\right\)\.The final scores⁡\(x\|q,pq,ξq​\(x\)\)s\(x\|q,p\_\{q\},\\xi\_\{q\}\(x\)\)combines cosine similarity to the query, time decay, graph\-hop decay, the RRF seed score when available, a path\-type prior fromξq​\(x\)\\xi\_\{q\}\(x\), and a date\-match boost\. As a result, at comparable relevance, candidates reached through short membership or causal paths are favored over distant semantic neighbors\.

Since a fused node serves as a retrieval and expansion unit, MemFuse projects each ranked candidate to atomic events viaEv⁡\(x\)\\operatorname\{Ev\}\(x\): the event itself ifx∈ℰx\\in\\mathcal\{E\}, or its member setμ⁡\(x\)\\mu\(x\)ifx∈𝒱x\\in\\mathcal\{V\}\. It then deduplicates and truncates the result to the top\-kkevents for the current search\.

##### Final Context Assembly\.

Once the agentic loop terminates, MemFuse selects the final top\-kkevents from the accumulated search results, forming the context𝒞q\\mathcal\{C\}\_\{q\}\. To keep this budget fixed, MemFuse backfills any unfilled slots from the earlier search history and truncates any excess to the final top\-kkevents\. The resulting context𝒞q\\mathcal\{C\}\_\{q\}is finally sent to the reader model, which generates the answer\.

## Experiments

Our experiments characterize performance on fragmented, source\-tagged event streams in MemFuseBench and evaluate MemFuse as an end\-to\-end memory system\. We ask four questions: \(i\) how well existing systems handle fragmented multi\-source memory under top\-kkaccess relative to the long context reference, \(ii\) how MemFuse compares with retrieval and memory baselines, \(iii\) which diagnostic categories expose the largest gaps, and \(iv\) how removing each MemFuse component affects answer quality\.

### Experiment Setup

#### Baselines\.

We compare MemFuse against Long context prompting, naive RAG, and three existing memory systems—Mem0\([4](https://arxiv.org/html/2608.18704#bib.bib8)\), A\-MEM\([22](https://arxiv.org/html/2608.18704#bib.bib9)\), and EverMemOS\([7](https://arxiv.org/html/2608.18704#bib.bib10)\)\.

#### Implementation\.

We evaluate each system under three LLM settings: Qwen3\-30B\-A3B, GPT\-4\.1 Mini, and Gemini 3\.1 Flash Lite, using the same LLM within each setting for method\-specific LLM calls and answer generation\. All systems ingest the same event stream and question set\. Long context prompting ingests the entire event stream\. Naive RAG retrieves nearest\-neighbor events by embedding similarity\. Mem0, A\-MEM, and EverMemOS use their native memory interfaces to ingest the same event stream and return candidate memories\. We use BGE\-M3 embeddings and compare top\-kksystems under the same top\-2020item budget\. For MemFuse, fused nodes expand candidate discovery; the resulting candidates are projected to atomic events, deduplicated, and truncated to the final 20\-event context\.

#### Evaluation Metrics\.

We measure answer quality with an LLM\-as\-judge checklist score, using GPT\-4\.1 Mini as the judge for all evaluations\. The judge marks each answer checklist item as covered or not, and the score is the fraction covered; the full prompt is provided in the supplement\. We report an Overall score as the mean across all questions, together with per\-category scores averaged within each diagnostic category in Table[1](https://arxiv.org/html/2608.18704#Sx3.T1)\.

### Main Results

Table[2](https://arxiv.org/html/2608.18704#Sx5.T2)reports answer checklist scores and token usage for all systems across the three LLM settings\. Based on these results, we aim to answer the following questions:

Table 2:MemFuseBench answer checklist scores and token usage\. Token counts are in millions; “–” marks unavailable or inapplicable values\. Excluding Long context, bold and underlined scores mark the best and second\-best system per checklist column\.##### Q1: How well do existing systems handle fragmented multi\-source memory?

Existing memory systems struggle to reliably integrate fragmented multi\-source evidence\. The strongest memory baseline improves over naive RAG under Qwen3\-30B\-A3B and GPT\-4\.1 Mini but trails it under Gemini 3\.1 Flash Lite, and remains 0\.0673–0\.2060 below Long context across the three settings\. This pattern is consistent with information loss in top\-kkmemory retrieval and sensitivity to the underlying LLM\.

##### Q2: How does MemFuse compare with retrieval and memory baselines?

MemFuse obtains the highest observed Overall score among all top\-kkretrieval and memory systems, with scores of 0\.4659, 0\.4574, and 0\.4698 across the three LLM settings\. It scores 0\.1285–0\.1481 above naive RAG and 0\.0024–0\.1461 above the strongest competing retrieval or memory system\. Compared with EverMemOS, MemFuse uses fewer inference tokens in all three settings and fewer ingest tokens in two of the three settings\.

##### Q3: Which diagnostic categories expose the largest gaps?

The Fusion category is the primary bottleneck, with a 0\.2047–0\.2706 gap between naive RAG and Long context across the three LLM settings\. MemFuse closes 62%–78% of this gap while also scoring substantially higher than naive RAG on User Query and Perspective\. It obtains the highest observed Conflict score under every LLM setting, indicating consistent strength on this diagnostic category\.

MemFusew/o ARw/o RCw/o Graphw/o Fusion0\.20\.20\.250\.250\.30\.30\.350\.350\.40\.40\.450\.450\.50\.50\.550\.550\.46980\.46980\.36620\.36620\.41850\.41850\.45140\.45140\.46180\.4618Overall Score0\.20\.20\.250\.250\.30\.30\.350\.350\.40\.40\.450\.450\.50\.50\.550\.550\.60\.60\.650\.650\.70\.70\.750\.750\.80\.8Category ScoreCausalFusionUser Agg\.User QueryConflictPerspective

Figure 4:Ablation results on MemFuseBench\. Bars show Overall checklist scores; lines show category\-level checklist scores\.

### Ablations

We remove one component at a time while keeping the remaining pipeline fixed\. All ablations use MemFuse @k=20k=20with Gemini 3\.1 Flash Lite as the main LLM and GPT\-4\.1 Mini as the judge\. Figure[4](https://arxiv.org/html/2608.18704#Sx5.F4)reports Overall checklist scores and category\-level breakdowns\. We consider four ablation variants:

w/o AR\.This variant disables the answer\-time agentic retrieval loop while retaining construction\-time agentic fusion and the remaining retrieval components\.w/o RC\.This variant keeps only the rewritten query from query planning and removes retrieval constraints, while leaving seed retrieval, typed graph expansion, candidate ranking, and final context assembly unchanged\.w/o Graph\.This variant keeps the Fusion Agent and cluster\-layer fused memories, but disables explicit causal fusion graph storage and typed\-edge traversal\.w/o Fusion\.This variant disables cluster\-layer fused memory, leaving atomic events with causal and semantic edges\.

##### Q4: How does removing each MemFuse component affect answer quality?

The ablations show that retrieval\-time components drive most of MemFuse’s gains\. Removing agentic retrieval and retrieval constraints reduces Overall by 0\.1036 \(22\.1%\) and 0\.0513, respectively, highlighting the importance of iterative, constrained search for recovering complementary multi\-source evidence\. In contrast, the graph and cluster\-level fused memory yield smaller Overall gains but show category\-specific benefits, most notably on User Query \(0\.0609\) and Perspective \(0\.0938\)\. This suggests that preconstructed memory structures help primarily when their organization aligns with the evidence view required by the question\.

## Conclusion

In this work, we focus on Multi\-Source Memory Fusion for long\-term agent\-memory reasoning\. To support research in this area, we construct MemFuseBench with controllable Scene\-to\-Sensor generation, source\-level evidence, adversarial noise, and reviewer\-corrector validation\. Building on this benchmark, we introduce MemFuse, a structured memory framework that combines event\-layer atomic memory with cluster\-layer fused memory and a causal fusion graph for retrieval and expansion\. Experimental results show that MemFuse achieves the best Overall score among the evaluated retrieval and memory systems under all three LLM settings and consistently outperforms naive RAG across all six diagnostic categories\.

One limitation is that the evidence events required by a question are not always perfectly aligned with the member events surfaced through fused\-memory retrieval\. Future work could further optimize the fusion process and graph structure to improve retrieval and answer quality\.

## References

- Caoet al\.\(2026\)S\. Cao, J\. He, and F\. TanHiGMem: a hierarchical and LLM\-guided memory system for long\-term conversational agents\.InFindings of the Association for Computational Linguistics: ACL 2026,pp\. 33853–33862\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p1.1),[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Chaiet al\.\(2026\)H\. Chai, Y\. Wang, Y\. Yang, D\. Peng, Y\. Song, Z\. Fu, W\. Liu, J\. Lin, J\. Wang, and W\. ZhangSMMBench: a benchmark for source\-distributed multimodal agent memory\.arXiv preprint arXiv:2605\.15710\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p2.1),[Memory Benchmarks\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px2.p1.1)\.
- Chenget al\.\(2026\)Z\. Cheng, W\. Wang, Y\. Zhao, Z\. Ren, J\. Chen, R\. Xu, S\. Huang, Y\. Chen, G\. Li, M\. Wang, Y\. Xie, R\. Zhu, Z\. Jiang, K\. Lu, Y\. Li, X\. Wang, L\. Liu, and C\. NguyenLifeBench: a benchmark for long\-horizon multi\-source memory\.arXiv preprint arXiv:2603\.03781\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p2.1),[Memory Benchmarks\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px2.p1.1)\.
- Chhikaraet al\.\(2025\)P\. Chhikara, D\. Khant, S\. Aryan, T\. Singh, and D\. YadavMem0: building production\-ready AI agents with scalable long\-term memory\.arXiv preprint arXiv:2504\.19413\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p1.1),[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1),[Baselines\.](https://arxiv.org/html/2608.18704#Sx5.SSx1.SSSx1.p1.1)\.
- Gottschalk and Demidova \(2018\)S\. Gottschalk and E\. DemidovaEventKG: a multilingual event\-centric temporal knowledge graph\.InThe Semantic Web,pp\. 272–287\.Cited by:[Multi\-Source memory Fusion\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px3.p1.1)\.
- Gurrinet al\.\(2014\)C\. Gurrin, A\. F\. Smeaton, and A\. R\. DohertyLifeLogging: personal big data\.Foundations and Trends in Information Retrieval8\(1\),pp\. 1–125\.Cited by:[Multi\-Source memory Fusion\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px3.p1.1)\.
- Huet al\.\(2026a\)C\. Hu, X\. Gao, Z\. Zhou, D\. Xu, Y\. Bai, X\. Li, H\. Zhang, T\. Li, C\. Zhang, L\. Bing, and Y\. DengEverMemOS: a self\-organizing memory operating system for structured long\-horizon reasoning\.InProceedings of the 64th Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 45836–45853\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p1.1),[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1),[Baselines\.](https://arxiv.org/html/2608.18704#Sx5.SSx1.SSSx1.p1.1)\.
- Huet al\.\(2026b\)C\. Hu, T\. Li, X\. Gao, H\. Chen, Y\. Bai, D\. Xu, T\. Lin, X\. Li, Y\. Han, J\. Pei, and Y\. DengEvaluating long\-horizon memory for multi\-party collaborative dialogues\.arXiv preprint arXiv:2602\.01313\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p2.1),[Memory Benchmarks\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px2.p1.1)\.
- Huet al\.\(2026c\)Y\. Hu, J\. Liu, J\. Tan, Y\. Zhu, and Z\. DouMemory matters more: event\-centric memory as a logic map for agent searching and reasoning\.InFindings of the Association for Computational Linguistics: ACL 2026,pp\. 22389–22407\.Cited by:[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Huet al\.\(2025\)Y\. Hu, S\. Liu, Y\. Yue, G\. Zhang, B\. Liu, F\. Zhu, J\. Lin, H\. Guo, S\. Dou, Z\. Xi,et al\.Memory in the age of AI agents\.arXiv preprint arXiv:2512\.13564\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p1.1),[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Huet al\.\(2026d\)Z\. Hu, Q\. Zhu, R\. Zhao, D\. Liang, H\. Yan, Y\. He, and L\. GuiBeyond rag for agent memory: retrieval by decoupling and aggregation\.arXiv preprint arXiv:2602\.02007\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p1.1),[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Khaleghiet al\.\(2013\)B\. Khaleghi, A\. Khamis, F\. O\. Karray, and S\. N\. RazaviMultisensor data fusion: a review of the state\-of\-the\-art\.Information Fusion14\(1\),pp\. 28–44\.Cited by:[Multi\-Source memory Fusion\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px3.p1.1)\.
- Liuet al\.\(2023\)L\. Liu, X\. Yang, Y\. Shen, B\. Hu, Z\. Zhang, J\. Gu, and G\. ZhangThink\-in\-Memory: recalling and post\-thinking enable LLMs with long\-term memory\.arXiv preprint arXiv:2311\.08719\.Cited by:[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Maharanaet al\.\(2024\)A\. Maharana, D\. Lee, S\. Tulyakov, M\. Bansal, F\. Barbieri, and Y\. FangEvaluating very long\-term conversational memory of LLM agents\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 13851–13870\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p2.1),[Memory Benchmarks\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px2.p1.1)\.
- Packeret al\.\(2023\)C\. Packer, S\. Wooders, K\. Lin, V\. Fang, S\. G\. Patil, I\. Stoica, and J\. E\. GonzalezMemGPT: towards LLMs as operating systems\.arXiv preprint arXiv:2310\.08560\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p1.1),[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Parket al\.\(2023\)J\. S\. Park, J\. O’Brien, C\. J\. Cai, M\. R\. Morris, P\. Liang, and M\. S\. BernsteinGenerative agents: interactive simulacra of human behavior\.InProceedings of the 36th Annual ACM Symposium on User Interface Software and Technology,Cited by:[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Sunet al\.\(2026\)H\. Sun, S\. Zeng, and B\. ZhangH\-MEM: hierarchical memory for high\-efficiency long\-term reasoning in LLM agents\.InProceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 341–350\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p1.1),[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Tanet al\.\(2025\)H\. Tan, Z\. Zhang, C\. Ma, X\. Chen, Q\. Dai, and Z\. DongMemBench: towards more comprehensive evaluation on the memory of LLM\-based agents\.InFindings of the Association for Computational Linguistics: ACL 2025,pp\. 19336–19352\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p2.1),[Memory Benchmarks\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px2.p1.1)\.
- Wanget al\.\(2023\)W\. Wang, L\. Dong, H\. Cheng, X\. Liu, X\. Yan, J\. Gao, and F\. WeiAugmenting language models with long\-term memory\.InProceedings of the 37th International Conference on Neural Information Processing Systems,pp\. 74530–74543\.Cited by:[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Wuet al\.\(2025\)D\. Wu, H\. Wang, W\. Yu, Y\. Zhang, K\. Chang, and D\. YuLongMemEval: benchmarking chat assistants on long\-term interactive memory\.InThe Thirteenth International Conference on Learning Representations,Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p2.1),[Memory Benchmarks\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px2.p1.1)\.
- Xuet al\.\(2026\)B\. Xu, Y\. Chen, J\. Fang, R\. Zhong, Y\. Yao, Y\. Zhu, L\. Du, and S\. DengStructMem: structured memory for long\-horizon behavior in LLMs\.InProceedings of the 64th Annual Meeting of the Association for Computational Linguistics \(Volume 2: Short Papers\),pp\. 122–146\.Cited by:[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Xuet al\.\(2025\)W\. Xu, Z\. Liang, K\. Mei, H\. Gao, J\. Tan, and Y\. ZhangA\-Mem: agentic memory for LLM agents\.InAdvances in Neural Information Processing Systems,Vol\.38,pp\. 17577–17604\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p1.1),[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1),[Baselines\.](https://arxiv.org/html/2608.18704#Sx5.SSx1.SSSx1.p1.1)\.
- Yanget al\.\(2026a\)C\. Yang, C\. Zhou, Y\. Xiao, S\. Dong, L\. Zhuang, Y\. Zhang, Z\. Wang, Z\. Hong, Z\. Yuan, Z\. Xiang,et al\.Graph\-based agent memory: taxonomy, techniques, and applications\.arXiv preprint arXiv:2602\.05665\.Cited by:[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Yanget al\.\(2026b\)J\. Yang, K\. Lai, X\. Wang, S\. Chang, Y\. Harari, and E\. GabrilovichGroupMemBench: benchmarking LLM agent memory in multi\-party conversations\.arXiv preprint arXiv:2605\.14498\.Cited by:[Introduction](https://arxiv.org/html/2608.18704#Sx1.p2.1),[Memory Benchmarks\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px2.p1.1)\.
- Zhanget al\.\(2020\)H\. Zhang, X\. Liu, H\. Pan, Y\. Song, and C\. W\. LeungASER: a large\-scale eventuality knowledge graph\.InProceedings of The Web Conference 2020,pp\. 201–211\.Cited by:[Multi\-Source memory Fusion\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px3.p1.1)\.
- Zhanget al\.\(2025\)Z\. Zhang, Q\. Dai, X\. Bo, C\. Ma, R\. Li, X\. Chen, J\. Zhu, Z\. Dong, and J\. WenA survey on the memory mechanism of large language model\-based agents\.ACM Transactions on Information Systems43\(6\),pp\. 1–47\.Cited by:[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.
- Zhonget al\.\(2024\)W\. Zhong, L\. Guo, Q\. Gao, H\. Ye, and Y\. WangMemoryBank: enhancing large language models with long\-term memory\.InProceedings of the AAAI Conference on Artificial Intelligence,Vol\.38,pp\. 19724–19731\.Cited by:[Long\-Term Agent Memory\.](https://arxiv.org/html/2608.18704#Sx2.SS0.SSS0.Px1.p1.1)\.

## A\. Ethics and Intended Use

MemFuseBench is fully synthetic and contains no real user records\. However, it simulates multi\-source personal traces such as routines, locations, device states, and cross\-user interactions\. The benchmark is intended for evaluating memory organization and evidence\-grounded retrieval, not for inferring sensitive attributes about real individuals\. Deploying similar memory systems in practice would require explicit user consent, access control across users and sources, audit logs, and user\-governed memory editing or deletion\.

## B\. MemFuseBench Synthesis Pipeline

The main paper presents the six\-stage Scene\-to\-Sensor framework\. This section follows the same construction order and records the reviewer\-corrector validation used to reproduce the finalized artifact\. We distinguish deterministic validation from semantic constraints imposed through generation prompts; the reviewer\-corrector and final verification procedures remain as described in the main paper\.

##### Stage 1: Persona Construction\.

The first pass samples stable personas and their shared context—schedules, relationships, and multi\-device inventories with observable modalities—and organizes them into a persona\-source graph, which constrains all later stages\. In implementation, generation proceeds in two passes: the first establishes character identities and a shared weekday/weekend schedule; the second expands this scaffold into individual routines, personal and shared devices, and a complete device inventory\. Required fields, device references, and modality labels are checked against a predefined sensing taxonomy\. Simple reference inconsistencies are repaired automatically, while unresolved outputs are regenerated\.

##### Stage 2: Scenario Construction\.

The second stage organizes the personas’ daily activities into causally linked storyline events grouped by episode\. This timeline is the latent ground truth, later refracted into source\-specific events\. In implementation, the generator first proposes episode themes and their date windows, then expands each episode into causally linked storyline events\. These events define the latent ground\-truth scenario timeline, including dates, observable devices, and causal relations\. Automated checks require a nonempty scenario timeline, valid device references, chronologically valid dates, and resolvable causal\-edge endpoints\. Invalid episodes are regenerated, and temporally inverted cross\-episode edges are removed\.

##### Stage 3: Event Stream Synthesis\.

The third stage renders the scenario into source\-specific events, interleaving routine, periodic, noise, and conflict events so each source gives only a partial view\. This yields a timestamped event stream\. In implementation, each storyline event is projected sequentially into source\-specific event streams from the devices marked as able to observe it\. Earlier episode summaries and observations already generated in the current episode provide continuity\. On dates with successful event projections, the pipeline also adds routine records, periodic environmental readings, incidental events, and paired multi\-source conflicts\. The combined stream is source\-tagged, ordered by timestamp, deduplicated by device and timestamp, and assigned scenario\- and episode\-qualified identifiers\. Atomicity, narrative coherence, and device compatibility are generation constraints; deterministic post\-processing handles parsing, ordering, deduplication, metadata, and identifiers\.

##### Stage 4: Category\-Spanning Question Generation\.

The fourth stage derives questions spanning the six diagnostic categories in Table[1](https://arxiv.org/html/2608.18704#Sx3.T1), producing a QA pool of questions, reference answers, and answer checklists\. In implementation, from the resulting event stream, questions are generated separately for the six diagnostic categories defined in the main paper, conditioned on the persona and device assignments and causal relations\. Each candidate contains a question, reference answer, evidence\-event identifiers, and query\-side user, time, and device metadata\. Identifiers are normalized within each scenario, and a query time that does not follow its latest labeled evidence is moved after that evidence\.

##### Stage 5: QA Filtering\.

The fifth stage filters the pool to remove semantic duplicates, commonsense shortcuts, and items whose labeled evidence cannot support the reference answer, retaining only answerable, evidence\-supported, non\-duplicative items\. In implementation, the resulting QA pool is filtered through semantic deduplication, a context\-free answerability test, and an evidence\-sufficiency check\. Questions with unresolvable evidence, questions answerable without the event stream, and answers not fully supported by their labeled events are rejected\. This stage filters candidates rather than rewriting retained questions\.

##### Stage 6: Adversarial Noise Injection\.

The sixth stage injects semantically similar distractors to complicate retrieval while keeping the gold evidence set auditable and unchanged, so finalized samples contain both gold evidence and plausible non\-evidence distractors\. In implementation, candidate distractors are generated from the target question, answer, labeled evidence, and scenario context\. They are intended to remain topically plausible without supplying the target answer\. After insertion, events are reordered and reassigned identifiers, and all evidence and checklist references are remapped\. The underlying gold evidence and reference answers must remain unchanged; distractor suitability is handled by generation and review rather than by identifier\-level checks alone\.

Because the synthesis pipeline involves stochastic generation, we freeze one reviewed JSON version of MemFuseBench and use it for all reported experiments\. Its evidence and checklist identifiers resolve to event records, and its query timestamps follow their labeled evidence\.

## C\. MemFuse Implementation Details

The main paper defines the memory layers, agentic fusion procedure, typed graph relations, and fusion\-aware retrieval algorithm\. This section records the concrete implementation choices and fixed budgets used in the reported experiments\.

### Storage and Indexing

Table[3](https://arxiv.org/html/2608.18704#Ax4.T3)records the storage and indexing backends\. Atomic events retain their benchmark identifiers, and cluster\-layer fused memories retain back\-pointers to their member events\.

### Retrieval Scoring and Context Assembly

For each search\-tool call, MemFuse instantiates the query\-planning and seed\-retrieval stage described in the main paper\. It combines dense retrieval for the original query and up to three rewritten queries, with at most 10 candidates per rewrite, BM25L retrieval for the planned lexical query, and temporal retrieval when the query\-planning parameters include a confident time window\. Retrieval constraints are used only when the planner assigns confidence at least 0\.6; the concrete time window and neighbor radius are query\-specific outputs rather than fixed hyperparameters\.

LetLℓL\_\{\\ell\}be a ranked list andrℓ​\(x\)r\_\{\\ell\}\(x\)the one\-based rank of candidatexx\. The ranked lists are combined by reciprocal rank fusion:

rRRF\(x\)=∑ℓ:x∈Lℓ160\+rℓ​\(x\)\.r\_\{\\mathrm\{RRF\}\}\(x\)=\\sum\_\{\\ell:x\\in L\_\{\\ell\}\}\\frac\{1\}\{60\+r\_\{\\ell\}\(x\)\}\.The 30 highest positive\-score candidates form the seed pool\. For an atomic event with timestamptxt\_\{x\}, query timetqt\_\{q\}, and graph distancehxh\_\{x\}, the implementation instantiates the fusion\-aware retrieval scoring functions⁡\(x∣q,pq,ξq​\(x\)\)s\(x\\mid q,p\_\{q\},\\xi\_\{q\}\(x\)\)as

s⁡\(x\)=\\displaystyle s\(x\)=\{\}cos⁡\(q,x\)​βhx\+2​rRRF​\(x\)\\displaystyle\\cos\(q,x\)\\beta^\{h\_\{x\}\}\+2r\_\{\\mathrm\{RRF\}\}\(x\)\+π⁡\(px\)\+bdate​\(q,x\)\.\\displaystyle\+\\pi\(p\_\{x\}\)\+b\_\{\\mathrm\{date\}\}\(q,x\)\.Here,cos⁡\(q,x\)\\cos\(q,x\)measures semantic similarity between the query and candidate event,hxh\_\{x\}is the graph distance from the seed, andβ=0\.7\\beta=0\.7downweights farther graph expansions\. The termrRRF​\(x\)r\_\{\\mathrm\{RRF\}\}\(x\)is the reciprocal\-rank\-fusion score from seed retrieval\. The path priorπ⁡\(px\)\\pi\(p\_\{x\}\)takes values 0\.08 for a direct seed, 0\.06 for a time\-window hit, 0\.04 for a causal path, 0\.03 for a membership path, and 0\.01 for a semantic path\. The date\-match boostbdate​\(q,x\)b\_\{\\mathrm\{date\}\}\(q,x\)is 0 in the reported English experiments, because temporal constraints are handled by query planning\.

For a fused nodevv, letsvs\_\{v\}andsjs\_\{j\}be the scores of its summary candidate and member events under the same retrieval scoring function, and lethvh\_\{v\}be its graph distance\. Fused\-node ranking uses

spack​\(v\)=\\displaystyle s\_\{\\mathrm\{pack\}\}\(v\)=\{\}0\.40​sv\+0\.35​maxj​sj\\displaystyle 0\.40s\_\{v\}\+0\.35\\max\_\{j\}s\_\{j\}\+0\.15​MeanTop3j⁡\(sj\)\+0\.10​βhv\.\\displaystyle\+0\.15\\operatorname\{MeanTop3\}\_\{j\}\(s\_\{j\}\)\+0\.10\\beta^\{h\_\{v\}\}\.The two scores are then compared in a shared ranking pool: atomic candidates uses⁡\(x\)s\(x\), while fused nodes usespack​\(v\)s\_\{\\mathrm\{pack\}\}\(v\)\. In the final context construction step, a selected atomic candidate is added directly, whereas a selected fused node contributes its summary first and then up to the configured number of member events, subject to the overall top\-kkand length budgets\. At most three fused nodes contribute to the reader context, with at most 10 member events from each\. An included fused summary consumes one of the 20 serialized context entries\. The context is deduplicated, capped at 128,000 characters, and ordered by timestamp\.

### Key Fixed Parameters

Table[4](https://arxiv.org/html/2608.18704#Ax4.T4)lists the fixed parameters that most directly affect fusion and retrieval; query\-specific planning outputs and secondary limits are omitted\.

## D\. Experimental Reproducibility

### Common Evaluation Protocol

GPT\-4\.1 Mini and Gemini 3\.1 Flash Lite are accessed through provider\-hosted APIs, while Qwen3\-30B\-A3B is served locally with vLLM on one NVIDIA A100 GPU\. Answer generation uses temperature 1 and a 2,048\-token output limit; MemFuse’s LLM\-assisted memory construction and query planning use temperature 1 and a 4,096\-token limit\. The GPT\-4\.1 Mini judge uses temperature zero and a 4,096\-token limit\.

Events are serialized in timestamp order for every system\. Retrieved contexts are passed to the same reader model together with the questioner identity, question time, and question\. Naive RAG’s selected events are restored to chronological order\. The full\-context and retrieved\-context readers use the same user message and differ only in their system descriptions; both prompts appear in the Prompt Templates section\.

### Answer Checklist Metric and Judge

For questionqq, letIqI\_\{q\}be its checklist and letci∈\{0,1\}c\_\{i\}\\in\\\{0,1\\\}indicate whether itemiiis covered\. The per\-question score is

ChecklistScore⁡\(q\)=1\|Iq\|​∑i∈Iqci\.\\operatorname\{ChecklistScore\}\(q\)=\\frac\{1\}\{\|I\_\{q\}\|\}\\sum\_\{i\\in I\_\{q\}\}c\_\{i\}\.Overall is the question\-macro average across all questions\. Category scores average questions within each category, so Overall is not the unweighted mean of the six category scores\.

GPT\-4\.1 Mini judges every reported answer from the question, system answer, and checklist\. Provider errors are retried up to eight times, and malformed judge outputs are re\-evaluated up to three times with an explicit format\-correction instruction\. A question that remains unscorable is marked as an error rather than assigned a zero, and the corresponding official aggregate is withheld until the error is resolved\. Each table entry is a point estimate from one fixed evaluation pass; no confidence intervals or statistical\-significance claims are reported\. The prompts governing the reported metric appear in the Prompt Templates section\.

Table 3:Storage and indexing backends used by MemFuse\.Table 4:Key fixed parameters used by MemFuse in the reported experiments\.

## E\. Selected Prompt Templates

The full prompt library is lengthy, so this appendix includes only the prompts most directly tied to reproducibility: representative reviewer–corrector prompts for internal\-coherence and answer\-preservation validation, plus the answer\-generation and evaluation prompts used for reported scores\. Runtime values are shown as braced placeholders\.

### Reviewer–Corrector Validation Prompts

The reviewer–corrector loop has two stage\-specific targets\. Stages 1–4 check*internal coherence*across the persona\-source graph, scenario timeline, event stream, and QA pool\. Stage 5 performs QA filtering to remove duplicate, ambiguous, shortcut\-answerable, or insufficiently supported items\. Stage 6 checks*answer preservation*: adversarial distractors may be revised for clarity or topicality, but they must not alter the gold evidence or the reference answer\. Because the full prompt set is extensive, we show only two representative stages here: Stage 1 for internal coherence and Stage 6 for answer preservation\.

##### Stage 1 reviewer system prompt\.

This prompt checks whether the generated persona and device schema are internally coherent before correction\.

Stage 1 Reviewer PromptYou are a data quality reviewer\. Review each element in thepersonasarray of data\_file one by one\.Data File[⬇](data:text/plain;base64,e2RhdGFfZmlsZX0=)\{data\_file\}Standards & RulesValid Modalities \(9 types only\)•health: physiological signs \(heart rate, SpO2, sleep stages, etc\.\)•motion: movement/activity \(steps, exercise, fall detection, etc\.\)•vision: visual perception \(face recognition, motion detection, etc\.\)•audio: audio perception \(conversation, ambient sound, intercom\)•environment: environmental data \(temperature, humidity, PM2\.5, etc\.\)•location: position & access \(GPS, entry/exit, unlock identity, etc\.\)•app\_usage: digital behavior \(screen time, app usage, viewing content\)•dialogue: conversational memory \(user’s stated intentions, preferences, plans\)•device\_status: device state change \(on/off, mode changes, fault alarms\)Key distinctions:•audio vs dialogue: audio is raw heard content; dialogue is semantic memory extracted from conversation•health vs motion: health = physiological metrics; motion = body activity and movement•vision vs location: vision = "what was seen"; location = "where a person/thing is"•environment vs device\_status: environment = physical quantities \(temp, humidity, air quality\); device\_status = device’s own operational state changesDevice Capability Reference \(expected modalities per device type\)•Smartwatch/Band: health, motion, location•Kids Smartwatch: health, motion, location•Smartphone: location, app\_usage, dialogue•Laptop: app\_usage•Tablet: app\_usage•Smart Speaker: audio, dialogue•Smart Display \(Speaker w/ Screen\): audio, dialogue, vision•Doorbell Camera: vision, audio, location•Indoor Camera: vision, audio•Smart Lock: location•Motion Sensor: motion•Door/Window Sensor: device\_status•Smart Thermostat: environment•Air Quality Monitor: environment•Air Purifier: environment, device\_status•Smart TV: app\_usage, device\_status•Smart Fridge: vision, device\_status•Smart Washer/Dryer: device\_status•Robot Vacuum: device\_status•Smart Light: device\_status•Smart Curtain: device\_status•Smart Scale: health•Car System: location, dialogue•Gaming Console: app\_usage, device\_statusRequired FieldsTop\-level persona fields:persona\_id,type,characters,shared\_devices,all\_devicesPer\-character fields:name,age,role,interests,health,routine,devicesRoutine sub\-fields:weekday,weekendPer\-device fields in all\_devices:device\_id,device\_type,owner,location,modalityReview DimensionsFor each persona, review each character element by element on the following aspects:1\. Routine Time Alignment \(Cross\-Character\)•Within the same persona, do multiple characters’ routines have consistent time points for shared events\(e\.g\., family meals, child pickup/dropoff\)?•Do character routines align with the times defined inshared\_schedule?•Example violation: One character says "dinner at 18:00" while another says "dinner at 19:00"\.2\. Routine Logical Conflicts \(Per\-Character\)•Does any single character’s routine have time overlaps or contradictions?•A person cannot be in two places at the same time•Example: A character doing "homework supervision 16:15\-17:00" and "cooking 16:30\-17:30" simultaneously3\. Routine Time Realism•Are activities allocated reasonable amounts of time?•Cooking, commuting, bathing all need adequate time•Elderly/children should have slower pacing•No teleportation: travel between locations requires time4\. Device Consistency•Doescharacters\[\]\.devicesunionshared\_devicesexactly equal the set ofdevice\_idvalues inall\_devices?•Are there any devices inall\_devicesnot referenced by any character orshared\_devices?•Are there any devices referenced incharactersorshared\_devicesbut missing fromall\_devices?5\. Modality Compliance•Does every device inall\_devicesuse ONLY the standard 9 modalities listed above?•Check for typos, non\-standard values, or empty modality fields6\. Device Modality Reasonableness•Does each device’s modality match the Device Capability Reference Table above?•Are there critical capabilities missing or unreasonable capabilities assigned?•Example: A smartwatch with only "health" is missing "motion,location"; a smart light with "audio" is unreasonable7\. Character Consistency•Does the character’s age, role, and interests match their routine content?•Example: A 5\-year\-old should not drive; a 9\-year\-old should not have independent late\-night activities•Does the role description match the daily activities described?8\. Field Completeness•Are all required fields present as listed in "Required Fields" above?9\. Owner Consistency•For personal devices:all\_devices\[\]\.ownermust equal the corresponding character’sname•For shared devices:all\_devices\[\]\.ownermust be"shared"•Cross\-check: devices listed in a character’sdevicesarray should have that character as owner inall\_devices10\. Device Location Reasonableness•Does each device’slocationmake sense for the device type?•Expected locations: smartphone \-\> "carried", smartwatch \-\> "wearable", car system \-\> "car"\.•Laptop can be "home\_office" or a similar plausible location\.•Shared devices should be in common household locations \(living\_room, kitchen, front\_door, etc\.\)\.•No contradictions: e\.g\., a "kitchen speaker" with location "bedroom"\.11\. Routine\-Device Support•If a character’s routine mentions an activity that requires a specific device, does that device exist in the persona?•Examples: "play video games" \-\> gaming console should exist\.•"robot vacuum runs" \-\> robot\_vacuum should exist\.•"voice assistant" interaction \-\> smart speaker or smart display should exist\.12\. Interests Count•Each character should have 2\-4 interests•Flag if fewer than 2 or more than 413\. Name Uniqueness•Within a single persona, all character names must be unique•Across all personas, persona\_id must be globally unique14\. Shared Schedule Name Consistency•All names inshared\_schedule\.participantsmust exactly match names incharacters\[\]\.name•Check for spelling differences, case mismatches, or names that appear in shared\_schedule but not in characters15\. Device ID Naming Convention•Personal devices typically follow\{type\}\_\{owner\_name\_lowercase\}format \(e\.g\.,watch\_david,phone\_sarah\)•Shared devices typically follow\{type\}\_\{location\}format \(e\.g\.,speaker\_living,camera\_playroom\)•Check for misspellings, inconsistent naming, or IDs that don’t match the device type16\. Child Device Age\-Appropriateness•Very young children \(under 6\) should NOT have smartphones or laptops•Children’s devices should be age\-appropriate \(kids smartwatch, tablet for educational use\)•Teens may have smartphones but probably not car systemsOutput FormatGenerate review report in the same directory as the data file\. File naming by loop number:•Loop 1:step1\_review\_report\_loop1\.md•Loop 2:step1\_review\_report\_loop2\.md•Loop N:step1\_review\_report\_loopN\.mdThe loop number will be provided in the task prompt when you are invoked\.Format:[⬇](data:text/plain;base64,IyBTdGVwMSBQZXJzb25hcyBSZXZpZXcgUmVwb3J0)\#Step1PersonasReviewReport[⬇](data:text/plain;base64,IyMgU3VtbWFyeQotIFRvdGFsIHBlcnNvbmFzOiBYCi0gUGVyc29uYXMgd2l0aCBpc3N1ZXM6IFkKLSBUb3RhbCBpc3N1ZXMgZm91bmQ6IFo=)\#\#Summary\-Totalpersonas:X\-Personaswithissues:Y\-Totalissuesfound:Z[⬇](data:text/plain;base64,IyMgUGVyc29uYToge3BlcnNvbmFfaWR9)\#\#Persona:\{persona\_id\}[⬇](data:text/plain;base64,IyMjIENoYXJhY3Rlcjoge25hbWV9Ci0gW3tEaW1lbnNpb259XSBJc3N1ZSBkZXNjcmlwdGlvbiB8IFNldmVyaXR5OiBISUdIL01FRElVTS9MT1c=)\#\#\#Character:\{name\}\-\[\{Dimension\}\]Issuedescription\|Severity:HIGH/MEDIUM/LOW[⬇](data:text/plain;base64,IyMjIERldmljZSBJc3N1ZXMKLSBbe0RpbWVuc2lvbn1dIElzc3VlIGRlc2NyaXB0aW9uIHwgU2V2ZXJpdHk6IEhJR0gvTUVESVVNL0xPVw==)\#\#\#DeviceIssues\-\[\{Dimension\}\]Issuedescription\|Severity:HIGH/MEDIUM/LOW[⬇](data:text/plain;base64,IyMjIENyb3NzLUNoYXJhY3RlciBJc3N1ZXMKLSBbe0RpbWVuc2lvbn1dIElzc3VlIGRlc2NyaXB0aW9uIHwgU2V2ZXJpdHk6IEhJR0gvTUVESVVNL0xPVw==)\#\#\#Cross\-CharacterIssues\-\[\{Dimension\}\]Issuedescription\|Severity:HIGH/MEDIUM/LOWList issues for every persona and every character\. If a persona/character has no issues, explicitly note "No issues found"\.Important Notes•Review EVERY element \- do not skip any persona or character•Be specific: include exact time values, device IDs, or field names in issue descriptions•Severity guide:•HIGH: Data contradiction, missing required field, modality violation•MEDIUM: Time misalignment between characters, missing device capability•LOW: Minor realism concern, slightly short time allocation

##### Stage 1 corrector system prompt\.

This prompt repairs Stage 1 issues while preserving the original persona structure and generation intent\.

Stage 1 Corrector PromptYou are a data repair specialist\. Based on the review report, verify and fix issues in data file\.Data File[⬇](data:text/plain;base64,e2RhdGFfZmlsZX0=)\{data\_file\}Review Report File[⬇](data:text/plain;base64,e3Jldmlld19yZXBvcnRfZmlsZX0=)\{review\_report\_file\}\(N = current loop number, provided in the task prompt\)Standards & RulesValid Modalities \(9 types only\)•health: physiological signs \(heart rate, SpO2, sleep stages, etc\.\)•motion: movement/activity \(steps, exercise, fall detection, etc\.\)•vision: visual perception \(face recognition, motion detection, etc\.\)•audio: audio perception \(conversation, ambient sound, intercom\)•environment: environmental data \(temperature, humidity, PM2\.5, etc\.\)•location: position & access \(GPS, entry/exit, unlock identity, etc\.\)•app\_usage: digital behavior \(screen time, app usage, viewing content\)•dialogue: conversational memory \(user’s stated intentions, preferences, plans\)•device\_status: device state change \(on/off, mode changes, fault alarms\)Device Capability Reference \(expected modalities per device type\)•Smartwatch/Band: health, motion, location•Kids Smartwatch: health, motion, location•Smartphone: location, app\_usage, dialogue•Laptop: app\_usage•Tablet: app\_usage•Smart Speaker: audio, dialogue•Smart Display \(Speaker w/ Screen\): audio, dialogue, vision•Doorbell Camera: vision, audio, location•Indoor Camera: vision, audio•Smart Lock: location•Motion Sensor: motion•Door/Window Sensor: device\_status•Smart Thermostat: environment•Air Quality Monitor: environment•Air Purifier: environment, device\_status•Smart TV: app\_usage, device\_status•Smart Fridge: vision, device\_status•Smart Washer/Dryer: device\_status•Robot Vacuum: device\_status•Smart Light: device\_status•Smart Curtain: device\_status•Smart Scale: health•Car System: location, dialogue•Gaming Console: app\_usage, device\_statusRequired FieldsTop\-level persona fields:persona\_id,type,characters,shared\_devices,all\_devicesPer\-character fields:name,age,role,interests,health,routine,devicesRoutine sub\-fields:weekday,weekendPer\-device fields in all\_devices:device\_id,device\_type,owner,location,modalityKey Constraints1\.Routine Time Alignment: Shared events in different characters’ routines must have identical time points\.They must also align withshared\_schedule\.2\.Routine Logical Conflicts: A single character cannot be in two places at the same time\.No time overlaps are allowed within one person’s routine\.3\.Routine Time Realism: Cooking, commuting, and bathing need adequate time\.No teleportation between locations\.4\.Device Consistency:characters\[\]\.devicesunionshared\_devicesmust exactly equal theall\_devicesdevice\_id set\.No orphans and no missing devices\.5\.Modality Compliance: Every device modality value must be one of the 9 standard types only\.No typos or non\-standard values\.6\.Device Modality Reasonableness: Each device’s modality must match the Device Capability Reference Table\.No missing critical capabilities and no unreasonable assignments\.7\.Character Consistency: Age, role, interests must match routine content \(e\.g\., 5\-year\-old cannot drive\)8\.Field Completeness: All required fields must be present \(see Required Fields section above\)9\.Owner Consistency: Personal devicesowner= character name; shared devicesowner= "shared"\.They must also cross\-match with thecharacters\[\]\.devicesandshared\_deviceslists\.10\.Device Location Reasonableness: smartphone \-\> "carried", smartwatch \-\> "wearable", car system \-\> "car"\.Shared devices should be in household locations, with no contradictions to device\_id naming\.11\.Routine\-Device Support: If a routine mentions an activity requiring a device \(e\.g\., "play video games"\), that device must exist in the persona\.12\.Interests Count: Each character must have 2\-4 interests13\.Name Uniqueness: Character names unique within persona; persona\_id globally unique across all personas14\.Shared Schedule Name Consistency: All names inshared\_schedule\.participantsmust exactly matchcharacters\[\]\.name\- no spelling differences or case mismatches15\.Device ID Naming Convention: Personal devices follow\{type\}\_\{owner\_lowercase\}format \(e\.g\.,watch\_david\); shared devices follow\{type\}\_\{location\}format \(e\.g\.,speaker\_living\)16\.Child Device Age\-Appropriateness: Children under 6 should not have smartphones/laptops; children’s devices should be age\-appropriate \(kids smartwatch, tablet\)Fix WorkflowStep 1: Independent Verification•For EACH issue in the review report, independently verify whether it actually exists by reading the data•Do NOT blindly trust the review report \- some findings may be false positives•Mark each issue as CONFIRMED or REJECTED with brief reasoningStep 2: Prioritized FixingFix confirmed issues by priority:•HIGH: Must fix•MEDIUM: Should fix•LOW: Fix if straightforward, skip if it would require major restructuringStep 3: Fix PrinciplesRoutine Time Alignment Issues:•Useshared\_scheduleas the ground truth•Adjust inconsistent character routines to match shared\_schedule times•Maintain the overall flow and logic of individual routines while fixing alignmentDevice Consistency Issues:•If a device is inall\_devicesbut not referenced: add toshared\_devices•If a device is referenced but not inall\_devices: remove the reference OR add the device definition \(choose whichever makes more sense\)•Ensure the union of all characters’ devices \+ shared\_devices = all\_devices device\_idsOwner Consistency Issues:•Personal devices \(in a character’sdeviceslist\): set owner to that character’s name•Shared devices \(inshared\_deviceslist\): set owner to "shared"Modality Issues:•Fix according to the Device Capability Reference Table above•If a device has an invalid modality value, replace with the correct one•If a device is missing a critical capability, add it•If a device has an unreasonable capability, remove itTime Conflict Issues:•Adjust to create a realistic, non\-overlapping schedule•Maintain consistency with shared events•Allow reasonable transition time between activitiesDevice ID Naming Issues:•Rename to follow convention: personal =\{type\}\_\{owner\_lowercase\}, shared =\{type\}\_\{location\}•Update ALL references \(characters\[\]\.devices, shared\_devices, all\_devices\) when renamingInterests Count Issues:•If fewer than 2: add plausible interests consistent with character’s role/age•If more than 4: trim to the 4 most relevantCharacter Consistency Issues:•If routine contains activities contradicting age/role \(e\.g\., child driving\), remove or replace with age\-appropriate activity•If interests don’t match routine activities, adjust interests to alignField Completeness Issues:•Add missing required fields with reasonable default values•For missinghealth: add "Healthy" or a brief condition consistent with the character•For missinginterests: infer 2\-4 from role and routine content•For missing device fields \(owner,location\): infer from device\_id naming and contextDevice Location Reasonableness Issues:•Fix location to match device type: smartphone \-\> "carried", smartwatch \-\> "wearable", car system \-\> "car", laptop \-\> "home\_office"•Shared household devices: use actual room name \(living\_room, kitchen, front\_door, etc\.\)Routine\-Device Support Issues:•If routine mentions an activity but no supporting device exists: add the device toall\_devicesandshared\_devices\(or character’s devices if personal\)•Alternatively, if adding a device is too disruptive, rephrase the routine activity to not require the missing deviceName Uniqueness Issues:•If character names are duplicated within a persona: rename one with a distinct but plausible name, update ALL references \(shared\_schedule participants, device owners, device\_ids\)•If persona\_ids are duplicated across personas: append a distinguishing suffix \(e\.g\.,\_002\)Shared Schedule Name Consistency Issues:•If a name in shared\_schedule\.participants doesn’t match any character name: fix the spelling in shared\_schedule to match the character’s actual name•Do NOT rename characters to match shared\_schedule \- shared\_schedule is reference material, characters are the source of truth for namesChild Device Age\-Appropriateness Issues:•If a child under 6 has a smartphone/laptop: replace with age\-appropriate device \(kids smartwatch or tablet\)•Update device\_id, all\_devices entry, and character’s devices list accordinglyStep 4: Backup & Write Back•Before making any changes, copy the original file to a backup with loop number suffix:•Loop 1:step1\_personas\_loop1\.json•Loop 2:step1\_personas\_loop2\.json•Loop N:step1\_personas\_loopN\.json•The loop number will be provided in the task prompt when you are invoked•The backup is placed in the same directory as the original file•Then write the fixed data back to the ORIGINAL file path \(step1\_personas\.json\)•Ensure valid JSON format after all fixes•After writing, validate the JSON loads correctlyOutput FormatGenerate fix report in the same directory\. File naming by loop number:•Loop 1:step1\_fix\_report\_loop1\.md•Loop 2:step1\_fix\_report\_loop2\.md•Loop N:step1\_fix\_report\_loopN\.mdThe loop number will be provided in the task prompt when you are invoked\.Format:[⬇](data:text/plain;base64,IyBTdGVwMSBGaXggUmVwb3J0)\#Step1FixReport[⬇](data:text/plain;base64,IyMgU3VtbWFyeQotIElzc3VlcyBpbiByZXZpZXcgcmVwb3J0OiBYCi0gQ29uZmlybWVkIHZhbGlkIGlzc3VlczogWQotIElzc3VlcyBmaXhlZDogWgotIFJlamVjdGVkIChmYWxzZSBwb3NpdGl2ZSk6IFc=)\#\#Summary\-Issuesinreviewreport:X\-Confirmedvalidissues:Y\-Issuesfixed:Z\-Rejected\(falsepositive\):W[⬇](data:text/plain;base64,IyMgRml4ZXMgQXBwbGllZA==)\#\#FixesApplied[⬇](data:text/plain;base64,IyMjIFBlcnNvbmE6IHtwZXJzb25hX2lkfQ==)\#\#\#Persona:\{persona\_id\}[⬇](data:text/plain;base64,IyMjIyBDaGFyYWN0ZXI6IHtuYW1lfQ==)\#\#\#\#Character:\{name\}•1: \[issue description\]; Verification: CONFIRMED/REJECTED; Action: \[fix description or rejection reason\]; Status: FIXED/REJECTED[⬇](data:text/plain;base64,IyMjIyBEZXZpY2UgRml4ZXM=)\#\#\#\#DeviceFixes•1: \[issue description\]; Verification: CONFIRMED/REJECTED; Action: \[fix description\]; Status: FIXED/REJECTEDImportant Notes•ALWAYS verify before fixing \- never trust the review report blindly•Keep fixes minimal and targeted \- do not rewrite entire routines unnecessarily•Maintain internal consistency after fixes \(fixing one thing should not break another\)•The file is large \- use careful, targeted edits rather than full rewrites when possible•After all fixes, verify the JSON is still valid

##### Stage 6 reviewer system prompt\.

This prompt checks whether adversarial noise is realistic, non\-evidence\-bearing, and schema\-consistent\.

Stage 6 Reviewer PromptYou are reviewing adversarial noise events in a benchmark dataset\.The dataset evaluates a memory retrieval system’s ability to distinguish relevant evidence from distractors\.BackgroundIn Stage~6, adversarial noise events were generated for each target question\. These events are intended to be:1\.Semantically similar to the target question’s topic, while remaining non\-evidence distractors2\.But must not be valid evidence for answering the target question3\.Must not serve as valid evidence for any other questionWhat You Are ReviewingData File:[⬇](data:text/plain;base64,e2RhdGFfZmlsZX0=)\{data\_file\}Structure:[⬇](data:text/plain;base64,ewogICJwZXJzb25hcyI6IFsuLi5dLAogICJzY2VuYXJpb3MiOiBbLi4uXSwKICAic2NlbmFyaW9fZGF0YSI6IFsKICAgIHsKICAgICAgInNjZW5hcmlvX2lkIjogInNjMSIsCiAgICAgICJwZXJzb25hIjogeyAuLi4gfSwKICAgICAgImVwaXNvZGVzIjogWwogICAgICAgIHsKICAgICAgICAgICJlcGlzb2RlX2lkIjogInNjMV9lcDEiLAogICAgICAgICAgImV2ZW50cyI6IFsKICAgICAgICAgICAgewogICAgICAgICAgICAgICJldmVudF9pZCI6ICJzYzFfZXAxX2U4MCIsCiAgICAgICAgICAgICAgImRldmljZSI6ICJ3YXRjaF9ldGhhbiIsCiAgICAgICAgICAgICAgIm1vZGFsaXR5IjogImhlYWx0aCIsCiAgICAgICAgICAgICAgImRlc2NyaXB0aW9uIjogIi4uLiIsCiAgICAgICAgICAgICAgInRpbWVzdGFtcCI6ICIyMDI2LTA1LTExVDEyOjE1OjAwIiwKICAgICAgICAgICAgICAibG9jYXRpb24iOiAid2VhcmFibGUiLAogICAgICAgICAgICAgICJzb3VyY2UiOiAiYWR2ZXJzYXJpYWwiLAogICAgICAgICAgICAgICJ0YXJnZXRfcXVlc3Rpb24iOiAicTEyIgogICAgICAgICAgICB9CiAgICAgICAgICBdCiAgICAgICAgfQogICAgICBdLAogICAgICAicXVlc3Rpb25zIjogWwogICAgICAgIHsKICAgICAgICAgICJxdWVzdGlvbl9pZCI6ICJxMTIiLAogICAgICAgICAgInF1ZXN0aW9uIjogIi4uLiIsCiAgICAgICAgICAiYW5zd2VyIjogIi4uLiIsCiAgICAgICAgICAiZXZpZGVuY2VfZXZlbnRfaWRzIjogWyJzYzFfZXAxX2U0IiwgInNjMV9lcDFfZTgiLCAuLi5dCiAgICAgICAgfQogICAgICBdCiAgICB9CiAgXQp9)\{"personas":\[\.\.\.\],"scenarios":\[\.\.\.\],"scenario\_data":\[\{"scenario\_id":"sc1","persona":\{\.\.\.\},"episodes":\[\{"episode\_id":"sc1\_ep1","events":\[\{"event\_id":"sc1\_ep1\_e80","device":"watch\_ethan","modality":"health","description":"\.\.\.","timestamp":"2026\-05\-11T12:15:00","location":"wearable","source":"adversarial","target\_question":"q12"\}\]\}\],"questions":\[\{"question\_id":"q12","question":"\.\.\.","answer":"\.\.\.","evidence\_event\_ids":\["sc1\_ep1\_e4","sc1\_ep1\_e8",\.\.\.\]\}\]\}\]\}•Only review events wheresource=="adversarial"•Each adversarial event has atarget\_questionfield linking it to a question in the same scenario’squestions\[\]array\.•Usepersonawithin the samescenario\_dataentry for cross\-referencing device/character infoReference InformationDate\-Weekday Mapping \(for this dataset\)[⬇](data:text/plain;base64,MjAyNi0wNS0xMSAoTW9uKQoyMDI2LTA1LTEyIChUdWUpCjIwMjYtMDUtMTMgKFdlZCkKMjAyNi0wNS0xNCAoVGh1KQoyMDI2LTA1LTE1IChGcmkpCjIwMjYtMDUtMTYgKFNhdCkKMjAyNi0wNS0xNyAoU3VuKQ==)2026\-05\-11\(Mon\)2026\-05\-12\(Tue\)2026\-05\-13\(Wed\)2026\-05\-14\(Thu\)2026\-05\-15\(Fri\)2026\-05\-16\(Sat\)2026\-05\-17\(Sun\)Valid Modalities \(9 types only\)•health: physiological signs \(heart rate, SpO2, sleep stages, etc\.\)•motion: movement/activity \(steps, exercise, fall detection, etc\.\)•vision: visual perception \(face recognition, motion detection, etc\.\)•audio: audio perception \(conversation, ambient sound, intercom\)•environment: environmental data \(temperature, humidity, PM2\.5, etc\.\)•location: position & access \(GPS, entry/exit, unlock identity, etc\.\)•app\_usage: digital behavior \(screen time, app usage, viewing content\)•dialogue: conversational memory \(user’s stated intentions, preferences, plans\)•device\_status: device state change \(on/off, mode changes, fault alarms\)Key distinctions:•audio vs dialogue: audio is raw heard content; dialogue is semantic memory extracted from conversation•health vs motion: health = physiological metrics; motion = body activity and movement•vision vs location: vision = "what was seen"; location = "where a person/thing is"•environment vs device\_status:–environment = physical quantities \(temp, humidity, air quality\)–device\_status = device’s own operational state changesDevice Capability Reference \(expected modalities per device type\)•Smartwatch/Band: health, motion, location•Kids Smartwatch: health, motion, location•Smartphone: location, app\_usage, dialogue•Laptop: app\_usage•Tablet: app\_usage•Smart Speaker: audio, dialogue•Smart Display \(Speaker w/ Screen\): audio, dialogue, vision•Doorbell Camera: vision, audio, location•Indoor Camera: vision, audio•Smart Lock: location•Motion Sensor: motion•Door/Window Sensor: device\_status•Smart Thermostat: environment•Air Quality Monitor: environment•Air Purifier: environment, device\_status•Smart TV: app\_usage, device\_status•Smart Fridge: vision, device\_status•Smart Washer/Dryer: device\_status•Robot Vacuum: device\_status•Smart Light: device\_status•Smart Curtain: device\_status•Smart Scale: health•Car System: location, dialogue•Gaming Console: app\_usage, device\_statusAdversarial Event FieldsEach adversarial event has exactly 8 fields:•event\_id: do not review; assigned by pipeline with format\{episode\_id\}\_e\{N\}\.•device: review; must exist in persona’sall\_devices\[\]\.device\_id\.•modality: review; must be one of 9 valid types and compatible with the device\.•description: review; primary target for evidence leakage, content validity, and adversarial quality\.•timestamp: review; must use ISO formatYYYY\-MM\-DDTHH:mm:ss, valid date, and plausible time\-of\-day\.•location: review; must be consistent with the device’s installation location\.•source: do not review; always"adversarial"\.•target\_question: do not review; fixed assignment used to look up the target question\.Note: Adversarial events intentionally do NOT have acharactersfield \(unlike other event sources\)\.Do not flag its absence\.Review CriteriaFor each adversarial event, you must check FOUR dimensions:•\(A\) Whether it wouldactually constitute valid evidencefor answering itstarget\_question•\(B\) Whether it wouldactually constitute valid evidencefor answeringany other questionin the same scenario•\(C\) Whether the event itself isinternally valid\(content, logic, device\-modality consistency\)•\(D\) Whether it hassufficient adversarial quality\(actually tests discrimination ability\)An adversarial event FAILS the review if:Dimension A & B: Evidence Leakage1\.Direct Answer Leakage \(target\): The event description directly reveals or strongly implies part of the answer to the target question\.•Example: If the question asks "Why did Sarah turn on the air purifier?" and the adversarial event says "Sarah turned on the air purifier because of high pollen", that’s a direct leak\.2\.Evidence Equivalence \(target\): The event provides the same type and quality of information as the actual evidence events for the target question\.•Example: If a question asks about health readings progression and the adversarial event contains specific health readings \(HR, SpO2, etc\.\) at a time that would fill a gap in the progression, it becomes valid evidence\.3\.Causal Chain Completion \(target\): The event completes a causal chain needed to answer the target question\.•Example: If the question asks "What happened after X?" and the adversarial event describes a consequence of X that matches the expected answer\.4\.Temporal/Factual Contradiction with Evidence: The event contradicts the actual evidence events or the ground\-truth answer in a way that would confuse the system about the correct answer\.•Example: It may provide contradictory readings at the same time as real evidence events\.5\.Cross\-Question Evidence Leakage: The event serves as valid evidence for a DIFFERENT question in the same scenario, not its target question\.•Example: If an adversarial event targeted at q12 describes "David cancelled the soccer reminder" and q17 asks about what David did after Ethan’s injury, this event would be valid evidence for q17\.•Check the event against ALL other questions in the scenario\.Dimension C: Content/Logic Validity6\.Device\-Modality Incompatibility: The event’smodalityis not supported by thedevice\.•Cross\-reference the device in persona’sall\_devicesand check itsmodalityfield \(comma\-separated list\)\.•Example:device: "watch\_david"withmodality: "audio"\- a smartwatch cannot produce audio events\.7\.Device Non\-Existence: Thedevicevalue doesn’t exist in the persona’sall\_devices\[\]\.device\_idlist\. Example: event uses"device": "camera\_garage"but no such device exists in persona\.8\.Modality\-Description Mismatch: The description content doesn’t match what the stated modality can perceive\.•Refer to the "perceivable information" column in the modality table\.•Example:modality: "health"but description says "camera detected movement"\.9\.Impossible/Unrealistic Readings: Physiological or environmental readings that are physically impossible\. Examples:•Heart rate: normal range 40\-180 bpm \(exercise up to 200\)•SpO2: normal range 88\-100%•Body temperature: 35\-40 deg C•Room temperature: 15\-35 deg C•Humidity: 20\-80%•PM2\.5: 0\-500 ug/m\\textasciicircum\{\}3•Step count per hour: 0\-1000010\.Location\-Device Inconsistency: The event’slocationconflicts with where the device should be\.•Fixed devices \(cameras, sensors\) must match their installation location\.•Wearable/carried devices follow the person\.11\.Timestamp Implausibility: Activity described at an impossible time\. Examples:•A child at school at 2 AM•Breakfast at 23:00•A person sleeping at noon without storyline justification12\.Character\-Device Ownership Mismatch: A wearable/personal device reports data about someone other than its owner\. Example:watch\_davidreports Sarah’s health data\.13\.Language Error: Description contains non\-English text \(this is an EN dataset\) or garbled/incomplete text\.14\.Non\-Atomic Event: The description spans multiple time points or combines multiple distinct activities into one event\.Each event should describe a SINGLE instantaneous observation at ONE timestamp\.•Example violation: "Smart watch recorded that David ran 5km between 7:00 and 7:45, then had breakfast at 8:00" \- combines two activities at different times•Example PASS: "Smart watch morning summary: total sleep 6\.5h, deep sleep 2\.1h, 3 awakenings" at 07:00 \- single summary report at one timestamp is acceptable•Severity: MEDIUM15\.Omniscient Narrator Perspective: The description uses an omniscient narrator viewpoint instead of the device’s sensing perspective\. Devices can only report what they can physically sense\.•Camera \-\> visual observations \(what it captured/detected/recorded\)•Watch \-\> physiological/motion data \(what it measured/recorded\)•Speaker \-\> audio content \(what it heard/detected\)•Sensor \-\> environmental readings \(what it measured\)•Example violation: "David felt anxious about the meeting" \- a device cannot know feelings unless expressed•Example violation: "Sarah decided to skip yoga today" \- internal decisions are not observable•Example PASS: "Smart watch recorded elevated heart rate of 95bpm, increased perspiration" \- device\-observable data•Severity: MEDIUM16\.Generic/Anonymous Name Usage: The description uses generic terms like "user", "owner", "the person", "he/she" instead of character names\.In a multi\-person household, it must be clear WHO is being described\.•Example violation: "The user returned home at 6pm"•Example PASS: "David returned home at 6pm"•Severity: MEDIUM \(LOW if it’s a single\-person device where the owner is obvious\)17\.Timestamp Format Invalid: The timestamp does not conform toYYYY\-MM\-DDTHH:mm:ssformat\.It may also contain an invalid date/time \(e\.g\., month 13, hour 25\), or the date may fall outside the scenario’s time span \(2026\-05\-11 \\textasciitilde\{\} 2026\-05\-17\)\.•Severity: HIGH18\.Weekday\-Activity Inconsistency: The event describes an activity that contradicts the day of the week\. Check against the date\-weekday mapping above\.•Example violation: Event on 2026\-05\-16 \(Saturday\) describes "Ethan attending math class at school"•Example violation: Event on 2026\-05\-11 \(Monday\) describes "family weekend outing to the zoo"•Example PASS: Activities that are plausible on any day \(cooking, watching TV, health readings\) don’t need weekday alignment•Severity: MEDIUM19\.Character\-Action Age/Role Inconsistency: The event describes a character performing an action that is impossible given their age, role, or health status as defined in the persona\.•Cross\-reference: check the character’sage,role, andhealthfields in persona•Example violation: A 5\-year\-old child "drives to the pharmacy" \- children cannot drive•Example violation: A 9\-year\-old "logs into their work laptop for a video conference" \- children don’t have work meetings•Example PASS: A 9\-year\-old "plays video games on the tablet" \- age\-appropriate•Severity: MEDIUM20\.Duplicate Device\-Timestamp: The adversarial event has the samedeviceANDtimestampas another event \(adversarial or non\-adversarial\) in the same episode\.This creates an ambiguous data point\.•Severity: MEDIUMDimension D: Adversarial Quality \(Distractor Effectiveness\)21\.Topic Irrelevance: The event has NO semantic connection to the target question’s topic\.It would be trivially easy for a retrieval system to exclude it, so it would not test discrimination ability at all\.•Check: Does the event share at least some topical overlap \(same domain: health/location/activity/device type\) with the target question?•Example violation: Target question asks "Why did Ethan’s heart rate spike?" but adversarial event describes "Living room thermostat measured 23\.5 deg C" \- completely unrelated topic•Example PASS: Target question asks about health readings, adversarial event describes health readings from a different context \- this IS topically related even though it’s not evidence•Severity: MEDIUM22\.Too Vague/Generic: The event description is so generic that it provides no specific information and would never confuse a retrieval system\.Examples: "Normal readings detected", "Activity observed", "Everything is fine", "Device is working properly"\.•Adversarial events must be SPECIFIC \- they should contain concrete details \(specific readings, named people, particular activities\) to actually test discrimination ability•Severity: MEDIUMReview Passing CriteriaAn adversarial event PASSES if:•It is topically related but does NOT provide information that helps answer the target question OR any other question•It describes similar\-type activities/readings but at irrelevant times or for irrelevant purposes•It is a genuine distractor that tests discrimination ability without leaking answer information to any question•Its content is internally consistent, realistic, and logically sound given the scenario context•Device, modality, and description are mutually consistentReview Process1\.Read the full data file2\.For each scenario inscenario\_data:a\. Build a map ofquestion\_id\-\> question \(withquestion,answer,evidence\_event\_ids\)b\. Build the full list of ALL questions in the scenario for cross\-checkingc\. Extract the persona’sall\_devicesfor device/modality validationd\. For each adversarial event \(wheresource=="adversarial"\):•Content/Logic check \(Dimension C\):–Validate device existence–Validate modality\-device compatibility–Validate modality\-description consistency–Validate reading plausibility–Validate location\-device match–Validate timestamp plausibility–Validate character\-device ownership•Target question check \(Dimension A\): Look up itstarget\_question, then compare the event description against the question’squestionandanswertext\.•Cross\-question check \(Dimension B\): Compare the event against ALL other questions in the same scenario\.Check whether it could serve as valid evidence for any of them\.3\.Document all failures with specific reasoningOutput FormatGenerate a review report as a markdown file\. File naming by loop number:•Loop 1:step6\_review\_report\_loop1\.md•Loop 2:step6\_review\_report\_loop2\.md•Loop N:step6\_review\_report\_loopN\.mdThe loop number will be provided in the task prompt when you are invoked\.Format:[⬇](data:text/plain;base64,IyBTdGFnZSA2IEFkdmVyc2FyaWFsIEV2ZW50cyBSZXZpZXcgUmVwb3J0)\#Stage6AdversarialEventsReviewReport[⬇](data:text/plain;base64,IyMgU3VtbWFyeQotIFRvdGFsIGFkdmVyc2FyaWFsIGV2ZW50cyByZXZpZXdlZDogWAotIElzc3VlcyBmb3VuZDogWQotIFBhc3MgcmF0ZTogWiU=)\#\#Summary\-Totaladversarialeventsreviewed:X\-Issuesfound:Y\-Passrate:Z%[⬇](data:text/plain;base64,IyMgU2NlbmFyaW86IHNjMQ==)\#\#Scenario:sc1[⬇](data:text/plain;base64,IyMjIElzc3VlIDE6IFtpc3N1ZV90eXBlXSAtIFNldmVyaXR5OiBISUdIL01FRElVTQ==)\#\#\#Issue1:\[issue\_type\]\-Severity:HIGH/MEDIUM[⬇](data:text/plain;base64,LSAqKkV2ZW50IElEKio6IHNjMV9lcDFfZTgwCi0gKipFcGlzb2RlKio6IHNjMV9lcDEKLSAqKkRldmljZSoqOiB3YXRjaF9ldGhhbgotICoqTW9kYWxpdHkqKjogaGVhbHRoCi0gKipUaW1lc3RhbXAqKjogMjAyNi0wNS0xMVQxMjoxNTowMAotICoqTG9jYXRpb24qKjogd2VhcmFibGUKLSAqKkV2ZW50IERlc2NyaXB0aW9uKio6ICIuLi4iCi0gKipUYXJnZXQgUXVlc3Rpb24gKHExMikqKjogIi4uLiIKLSAqKlRhcmdldCBBbnN3ZXIgRXhjZXJwdCoqOiAiZmlyc3QgMjAwIGNoYXJzLi4uIgotICoqQWZmZWN0ZWQgUXVlc3Rpb24qKiAoZm9yIGNyb3NzLXF1ZXN0aW9uIGlzc3Vlcyk6IHExNyAtICIuLi4iCi0gKipFeHBsYW5hdGlvbioqOiBEZXRhaWxlZCBleHBsYW5hdGlvbiBvZiB3aHkgdGhpcyBldmVudCBmYWlscyB0aGUgcmV2aWV3)\-\*\*EventID\*\*:sc1\_ep1\_e80\-\*\*Episode\*\*:sc1\_ep1\-\*\*Device\*\*:watch\_ethan\-\*\*Modality\*\*:health\-\*\*Timestamp\*\*:2026\-05\-11T12:15:00\-\*\*Location\*\*:wearable\-\*\*EventDescription\*\*:"\.\.\."\-\*\*TargetQuestion\(q12\)\*\*:"\.\.\."\-\*\*TargetAnswerExcerpt\*\*:"first200chars\.\.\."\-\*\*AffectedQuestion\*\*\(forcross\-questionissues\):q17\-"\.\.\."\-\*\*Explanation\*\*:Detailedexplanationofwhythiseventfailsthereview[⬇](data:text/plain;base64,IyMjIElzc3VlIDI6IC4uLg==)\#\#\#Issue2:\.\.\.[⬇](data:text/plain;base64,IyMgU2NlbmFyaW86IHNjMg==)\#\#Scenario:sc2[⬇](data:text/plain;base64,IyMjIElzc3VlIDE6IC4uLg==)\#\#\#Issue1:\.\.\.[⬇](data:text/plain;base64,KElmIGEgc2NlbmFyaW8gaGFzIG5vIGlzc3Vlcywgd3JpdGUgIk5vIGlzc3VlcyBmb3VuZCIp)\(Ifascenariohasnoissues,write"Noissuesfound"\)Each issue should be a separate section with all relevant fields clearly listed\.Severity Guide•HIGH:–Direct answer leakage–Evidence equivalence–Device non\-existence–Device\-modality incompatibility–Modality\-description mismatch–Language error–Timestamp format invalid•MEDIUM:–Causal chain completion–Cross\-question evidence leakage–Temporal/factual contradiction–Impossible readings–Location\-device inconsistency–Timestamp implausibility–Character\-device ownership mismatch–Non\-atomic event–Omniscient narrator perspective–Generic/anonymous name usage–Weekday\-activity inconsistency–Character\-action age/role inconsistency–Duplicate device\-timestamp–Topic irrelevance–Too vague/genericImportant Notes•Only flag REAL issues\. An adversarial event being "somewhat related" to the topic is by design \- that’s what makes it adversarial\. Only flag events that would genuinely serve as valid evidence or leak answer information\.•For content/logic checks: look up the persona’sall\_devicesto get each device’smodalityandlocationfields, then validate against the event\.•Be thorough: check every adversarial event in every scenario\.•Read the full answer text carefully \- adversarial events might leak specific details mentioned in the answer\.•When checking cross\-question leakage, focus on questions whose topic clearly overlaps with the event content \- you don’t need to exhaustively compare against every single question if the topics are unrelated\.•For device validation, use thepersonafield within the samescenario\_dataentry \(not the top\-levelpersonasarray\)\.

##### Stage 6 corrector system prompt\.

This prompt repairs Stage 6 adversarial events while keeping them useful as distractors\.

Stage 6 Corrector PromptYou are correcting adversarial noise events in a benchmark dataset based on a review report\.The dataset evaluates a memory retrieval system’s ability to distinguish relevant evidence from distractors\.BackgroundIn Stage~6, adversarial noise events were generated for each target question\. These events are intended to be:1\.Semantically similar to the target question’s topic, while remaining non\-evidence distractors2\.But must not be valid evidence for answering the target question3\.Must not serve as valid evidence for any other questionA reviewer has identified events that FAIL these criteria\.They may leak answer information, serve as valid evidence, have content/logic errors, or lack adversarial quality\.Input Files•Data File[⬇](data:text/plain;base64,e2RhdGFfZmlsZX0=)\{data\_file\}•Review Report File[⬇](data:text/plain;base64,e3Jldmlld19yZXBvcnRfZmlsZX0=)\{review\_report\_file\}The loop number will be provided in the task prompt when you are invoked\.Reference InformationDate\-Weekday Mapping \(for this dataset\)[⬇](data:text/plain;base64,MjAyNi0wNS0xMSAoTW9uKQoyMDI2LTA1LTEyIChUdWUpCjIwMjYtMDUtMTMgKFdlZCkKMjAyNi0wNS0xNCAoVGh1KQoyMDI2LTA1LTE1IChGcmkpCjIwMjYtMDUtMTYgKFNhdCkKMjAyNi0wNS0xNyAoU3VuKQ==)2026\-05\-11\(Mon\)2026\-05\-12\(Tue\)2026\-05\-13\(Wed\)2026\-05\-14\(Thu\)2026\-05\-15\(Fri\)2026\-05\-16\(Sat\)2026\-05\-17\(Sun\)Valid Modalities \(9 types only\)•health: physiological signs \(heart rate, SpO2, sleep stages, etc\.\)•motion: movement/activity \(steps, exercise, fall detection, etc\.\)•vision: visual perception \(face recognition, motion detection, etc\.\)•audio: audio perception \(conversation, ambient sound, intercom\)•environment: environmental data \(temperature, humidity, PM2\.5, etc\.\)•location: position & access \(GPS, entry/exit, unlock identity, etc\.\)•app\_usage: digital behavior \(screen time, app usage, viewing content\)•dialogue: conversational memory \(user’s stated intentions, preferences, plans\)•device\_status: device state change \(on/off, mode changes, fault alarms\)Device Capability Reference \(expected modalities per device type\)•Smartwatch/Band: health, motion, location•Kids Smartwatch: health, motion, location•Smartphone: location, app\_usage, dialogue•Laptop: app\_usage•Tablet: app\_usage•Smart Speaker: audio, dialogue•Smart Display \(Speaker w/ Screen\): audio, dialogue, vision•Doorbell Camera: vision, audio, location•Indoor Camera: vision, audio•Smart Lock: location•Motion Sensor: motion•Door/Window Sensor: device\_status•Smart Thermostat: environment•Air Quality Monitor: environment•Air Purifier: environment, device\_status•Smart TV: app\_usage, device\_status•Smart Fridge: vision, device\_status•Smart Washer/Dryer: device\_status•Robot Vacuum: device\_status•Smart Light: device\_status•Smart Curtain: device\_status•Smart Scale: health•Car System: location, dialogue•Gaming Console: app\_usage, device\_statusEvent Description Quality Rules \(must follow when writing/rewriting descriptions\)Any description you write or rewrite MUST comply with these rules\. Violating them while fixing another issue would introduce a new defect\.1\. Atomic Event Principle•Each event describes a SINGLE instantaneous observation at ONE time point•Must NOT describe a span of time \(e\.g\., "from 7:00 to 8:00 David exercised"\)•Must NOT combine multiple distinct activities into one event•Exception: A summary reading reported at a single timestamp is valid\.Example: "Smart watch recorded: total sleep 6\.5h, deep sleep 2\.1h" at 07:00 is a single summary observation at wake\-up\.2\. Device Perspective•Descriptions MUST be from the device’s sensing perspective, not an omniscient narrator•Camera: "captured/detected/recorded \[visual observation\]"•Watch: "measured/recorded \[physiological/motion data\]"•Speaker: "heard/detected \[audio content\]"•Phone: "recorded \[app activity/location\]"•Sensor: "measured/detected \[environmental readings\]"•Violation example: "David felt tired" \- a device cannot know feelings unless expressed aloud•Acceptable: "Smart watch recorded elevated heart rate of 95bpm and reduced step count"3\. Name Usage•Use character NAMES \(e\.g\., "David", "Sarah"\), not generic terms \("user", "owner", "the person", "he/she"\)•In multi\-person households, must be clear WHO is being described4\. Modality\-Description Match•Description content must match what the stated modality can perceive\.See the modality table in Reference Information\.•health \-\> physiological metrics only•motion \-\> movement/activity data only•vision \-\> visual observations only•audio \-\> heard sounds/speech only•environment \-\> physical measurements only•location \-\> position/access data only•app\_usage \-\> digital behavior only•dialogue \-\> spoken intentions/preferences only•device\_status \-\> device operational state changes only5\. Realistic Readings•Physiological: HR 40\-200 bpm, SpO2 88\-100%, temp 35\-40 deg C, respiration 10\-30/min•Environmental: room temp 15\-35 deg C, humidity 20\-80%, PM2\.5 0\-500 ug/m\\textasciicircum\{\}3•All numerical values must be physically plausible6\. Specificity•Descriptions must be SPECIFIC with concrete details \(exact readings, named activities, particular observations\)•Avoid vague/generic: "normal readings", "activity detected", "everything fine"7\. Language•All text must be in English \(this is an EN dataset\)•No Chinese, no garbled/incomplete textCorrection Process1\.Backup: Create backup of current data file \(see "Backup & Working Copy" above\)\.2\.Readthe review report to understand all identified issues\.3\.For each issue in the report:a\.Verify the issue is valid: Read the actual event and the target question/answer in the data file\.Confirm the reviewer’s assessment is correct\. If you disagree, document why and skip the fix\.b\.Fix the event: Apply the appropriate fix strategy \(see below\)\.c\.Post\-fix verification\(mandatory for evidence leakage fixes\): After writing the new description, verify it doesn’t become evidence for ANY question in the scenario\.See the "Post\-Fix Global Verification" section\.4\.Rules for fixes:•ONLY modify events withsource=="adversarial"that are flagged in the report•Do NOT modify any non\-adversarial events, questions, answers, or evidence\_event\_ids•The fixed event should still be topically similar enough to be a meaningful distractor5\.Modifiable fields\(for adversarial events only\):•description: can modify; primary fix target for most issues\.•device: can modify only for device non\-existence or device\-modality incompatibility\.•modality: can modify only for device\-modality incompatibility or modality\-description mismatch\.•timestamp: can modify only for invalid timestamp format or duplicate device\-timestamp\.•location: can modify only for location\-device inconsistency or after changing device\.•event\_id: never modify; assigned by pipeline\.•source: never modify; always "adversarial"\.•target\_question: never modify; fixed assignment from generation\.Principle: Prefer fixingdescriptionalone\. Only change metadata fields when the issue is specifically about that field being invalid\.After changing any metadata field, always verify the triple constraint:•deviceexists in the persona•modalityis compatible with that device•locationmatches the deviceFix Strategy by Issue TypeEvidence Leakage Fixes \(Dimension A & B\)•Direct Answer Leakage: Change specific details that match the answer\.Example: if the answer mentions "SpO2 91%" and the adversarial event also mentions "SpO2 91%", change to a different reading that doesn’t match any evidence detail\.•Evidence Equivalence: Shift the content to be related but not evidentially useful\.Example: if the question asks about health progression and the event gives readings at a critical time point, change to readings at a non\-critical parameter or make them routine/unremarkable\.•Causal Chain Completion: Break the causal link by describing a similar but unrelated activity\.•Temporal/Factual Contradiction: Ensure the event doesn’t contradict evidence at the same timestamp\.•Cross\-Question Evidence Leakage: Remove the specific details that answer that other question, while keeping the event topically related to its original target\_question\.Content/Logic Fixes \(Dimension C\)•Device\-Modality Incompatibility / Device Non\-Existence: Fix thedeviceormodalityfield to use a valid device from the persona’sall\_deviceslist with a compatible modality\.Then adjust the description to match:–deviceexists inall\_devices\[\]\.device\_id–modalityis listed in that device’smodalityfield–locationmatches the device’slocationfor fixed devices or follows the character for wearable/carried devices•Modality\-Description Mismatch: Change the description to describe information that the stated modality can actually perceive\.Or change the modality to match what the description actually describes, if a compatible modality exists for that device\.•Impossible Readings: Replace with realistic values within normal physiological/environmental ranges\.•Location\-Device Inconsistency: Fix the location to match where the device is installed\.Or adjust the description to be consistent with the device’s actual location\.•Character\-Device Ownership Mismatch: Fix the description to refer to the device’s actual owner\.•Language Error: Rewrite in proper English\.•Timestamp Format Invalid: Fix to validYYYY\-MM\-DDTHH:mm:sswithin time span 2026\-05\-11 \\textasciitilde\{\} 2026\-05\-17\.Keep the time portion plausible for the described activity\.•Weekday\-Activity Inconsistency: Rewrite the description to match the day of the week \(use date\-weekday mapping: Mon=05\-11 through Sun=05\-17\)\.Example: if the event is on Saturday but describes school attendance, change to a weekend\-appropriate activity\.•Character\-Action Age/Role Inconsistency: Rewrite the description so the action is appropriate for the character’s age, role, and health status\.Cross\-reference the persona’s character definitions\.•Duplicate Device\-Timestamp: Shift the adversarial event’s timestamp by 1\-5 minutes to avoid collision with the other event on the same device\.Ensure the description still makes sense at the new time\.•Non\-Atomic Event: Rewrite to describe a single instantaneous observation at the event’s timestamp\.Remove any time spans or multiple combined activities\.•Omniscient Narrator Perspective: Rewrite from the device’s sensing perspective\.Replace internal states/feelings with device\-observable data\.•Generic/Anonymous Name Usage: Replace "user"/"owner"/"the person" with the appropriate character name\.The character name is typically the device owner\.Adversarial Quality Fixes \(Dimension D\)•Topic Irrelevance: Rewrite the description to be semantically related to the target question’s topic while still not being valid evidence\.Keep the same device/modality/timestamp but change the content to share topical overlap with the target question’s domain\.•Too Vague/Generic: Add concrete, specific details to the description\.Use specific readings, named activities, and particular observations\.Make sure these details don’t constitute evidence for any question\.Post\-Fix Global VerificationAfter fixing any evidence leakage issue \(Dimension A or B\), you MUST perform this verification:1\.Read ALL questions in the same scenario \(not just the target or affected question\)2\.For the new/fixed description, check: does it contain information that directly helps answer ANY question?3\.Specifically focus on questions whose topic overlaps with the new description’s content4\.If the fix creates a new leakage to another question: iterate the fix until no leakage remains to any questionThis step is critical because fixing a leak to one question can accidentally create a leak to another\.OutputGenerate fix report in the same directory\. File naming by loop number:•Loop 1:step1\_fix\_report\_loop1\.md•Loop 2:step1\_fix\_report\_loop2\.md•Loop N:step1\_fix\_report\_loopN\.mdThe loop number will be provided in the task prompt when you are invoked\.Fix report format:[⬇](data:text/plain;base64,IyBTdGFnZSA2IEZpeCBSZXBvcnQgLSBMb29wIHtOfQ==)\#Stage6FixReport\-Loop\{N\}[⬇](data:text/plain;base64,IyMgU3VtbWFyeQotIFRvdGFsIGlzc3VlcyBpbiByZXZpZXcgcmVwb3J0OiBYCi0gSXNzdWVzIHZlcmlmaWVkIHZhbGlkOiBZCi0gSXNzdWVzIHJlamVjdGVkIChmYWxzZSBwb3NpdGl2ZXMpOiBaCi0gRml4ZXMgYXBwbGllZDogVw==)\#\#Summary\-Totalissuesinreviewreport:X\-Issuesverifiedvalid:Y\-Issuesrejected\(falsepositives\):Z\-Fixesapplied:W[⬇](data:text/plain;base64,IyMgRml4ZXMgQXBwbGllZA==)\#\#FixesApplied[⬇](data:text/plain;base64,IyMjIEZpeCAxOiBbZXZlbnRfaWRdIC0gW2lzc3VlX3R5cGVd)\#\#\#Fix1:\[event\_id\]\-\[issue\_type\][⬇](data:text/plain;base64,LSAqKlNjZW5hcmlvKio6IHNjMQotICoqT3JpZ2luYWwgRGVzY3JpcHRpb24qKjogIi4uLiIKLSAqKkZpeGVkIERlc2NyaXB0aW9uKio6ICIuLi4iCi0gKipGaXggUmVhc29uaW5nKio6IFdoeSB0aGlzIGZpeCByZXNvbHZlcyB0aGUgaXNzdWUgd2hpbGUgbWFpbnRhaW5pbmcgZGlzdHJhY3RvciBxdWFsaXR5Ci0gKipHbG9iYWwgVmVyaWZpY2F0aW9uKio6IENvbmZpcm1lZCBubyBsZWFrYWdlIHRvIG90aGVyIHF1ZXN0aW9ucw==)\-\*\*Scenario\*\*:sc1\-\*\*OriginalDescription\*\*:"\.\.\."\-\*\*FixedDescription\*\*:"\.\.\."\-\*\*FixReasoning\*\*:Whythisfixresolvestheissuewhilemaintainingdistractorquality\-\*\*GlobalVerification\*\*:Confirmednoleakagetootherquestions[⬇](data:text/plain;base64,IyMjIEZpeCAyOiAuLi4=)\#\#\#Fix2:\.\.\.[⬇](data:text/plain;base64,IyMgUmVqZWN0ZWQgSXNzdWVz)\#\#RejectedIssues[⬇](data:text/plain;base64,IyMjIFJlamVjdGlvbiAxOiBbZXZlbnRfaWRd)\#\#\#Rejection1:\[event\_id\][⬇](data:text/plain;base64,LSAqKlJldmlld2VyJ3MgQ2xhaW0qKjogLi4uCi0gKipSZWFzb24gZm9yIFJlamVjdGlvbioqOiBXaHkgdGhlIHJldmlld2VyJ3MgYXNzZXNzbWVudCB3YXMgaW5jb3JyZWN0)\-\*\*Reviewer’sClaim\*\*:\.\.\.\-\*\*ReasonforRejection\*\*:Whythereviewer’sassessmentwasincorrectImportant Notes•Verify each issue before fixing \- reviewers can have false positives•Fixed descriptions must still be realistic and specific \(not generic/vague\)•The goal is to maintain distractor quality while removing evidence leakage•Do not over\-correct: the event should still be topically related enough to test discrimination ability•For device/modality fixes, always cross\-reference the persona’sall\_devicesto ensure the fix uses valid devices and compatible modalities\.After any device/modality fix, verify the triple constraint: device exists, modality is compatible with device, location matches device’s installation\.•After fixing, double\-check that the new description doesn’t accidentally become evidence for ANY other question in the scenario\.See Post\-Fix Global Verification\.•Adversarial events intentionally do NOT have acharactersfield \- do not add one

### MemFuse Method Prompts

These templates govern the LLM\-controlled parts of memory construction and retrieval\.

#### Fusion Agent

##### System prompt\.

This prompt defines the fusion agent’s role, available tools, validity constraints, output schema, and fusion criteria\.

Fusion Agent System PromptYou are a tool\-driven memory fusion agent\.Decide whether the current new event should create causal edges with existing memories, create a fused node, update an existing fused node, or repair a noisy fused pack\.You may use three tools:1\. search\_memory: Search candidate memories with a retrieval query\.The system has already called search\_memory once with the current new event\.If candidates are insufficient, you may call search\_memory a limited number of additional times\.2\. get\_pack\_members: Inspect the member details of a candidate fused node only when member\-level evidence is required\.Use it when you are seriously considering update\_fusion\_node into a full pack, or when visible evidence gives a specific reason to suspect clear noisy members\.Each event has only a small lookup budget\.Repeated lookups of the same pack waste a turn and should be avoided\.3\. submit\_fusion\_plan: Submit the final fusion plan\. After submission, processing for this event ends\.Important constraints:•All JSON string values must be written in English\. If input events or candidate summaries are in another language, translate or paraphrase them into English in your summaries and reasons\.•search\_memory returns the same format as Candidate memories, including fused node summaries, retrieved member events, and standalone events\.•get\_pack\_members returns formatted text with the fused node summary, metadata, valid removable member IDs, and member event list\.•Do not invent chunk\_ids or fused node IDs that are not present in candidates\.•Never output placeholder literals such as "Fused node \[ID\]" or "candidate fused node ID"\. Always output a real fused\_xxx ID\.•target\_chunk\_id and fusion\_node\_id can only use fused node IDs shown as "Fused node \[ID\]" in candidates, not ordinary event IDs\.•involved\_events should contain only the current new event ID\.•Except for remove\_member, every operation must directly involve the current new event\.•For create\_edge, one endpoint must be the current new event ID\. The other endpoint must be a real chunk\_id or fused\_xxx ID visible in Candidate memories or a get\_pack\_members response\.Never create edges between two old memories, and never use an event ID that only appears inside your own reasoning or summary text\.•Candidate fused nodes show member count, time range, subjects, and devices\. When deciding whether to update\_existing, use these structured ranges: the current new event should naturally belong to the same concrete event segment, not merely share a topic\.•A fused pack has a maximum member count\. When a candidate fused node reaches the configured maximum, the pack is full\.•A fused pack with one member is a singleton\.Do not call get\_pack\_members merely to inspect a singleton pack, and never output remove\_member for a singleton pack because it would empty the pack\.For singleton packs, either update\_fusion\_node if the current event belongs with that member, create\_edge if it is only causally related, or create\_fusion\_node/no\_op if it is separate\.•Do not call get\_pack\_members for every full pack\.If the candidate summary, metadata, and retrieved member events already make the decision clear, submit a plan directly\.•If you plan to update\_fusion\_node into a full pack and the visible evidence is insufficient to know whether the current event belongs, first call get\_pack\_members for that pack\.After inspection, remove clearly noisy members if they exist\.If there is no clear noise, do not remove members just to make room; you may still output update\_fusion\_node and the system will apply its full\-pack logic\.•remove\_member only removes BELONG edges between members and the fused node; it does not delete atomic events\.Remove only members that clearly do not belong to the concrete event segment\.When uncertain, do not remove\.Never remove members just to make room\.•remove\_member is also a candidate pack repair operation: if get\_pack\_members reveals clear noisy members, output remove\_member even if the current event ultimately does not join that pack\.Do not skip obvious pack repair just because the final action is create\_new or no\_op\.•If you inspect a pack and do not output remove\_member, that means you confirm all inspected members belong to the same concrete event segment and provide useful evidence for the pack summary\.Do not replace this judgment with weak similarity such as related topic, same day, same household/dormitory, or close timestamps\.•If you output remove\_member, you must also output summary\.That summary must describe the remaining pack after removal and must not include information from removed members\.•remove\_member\.remove\_member\_ids must use exact member IDs shown in the latest get\_pack\_members response for that fused node\.Do not remove IDs copied from candidates, summaries, placeholders, or the current new event\.•If the same plan first removes members and then updates the fused node, remove\_member\.summary describes the pack after removal, and update\_fusion\_node\.summary describes the final pack after removal plus the current event\.•Use remove\_member only for a few clear noisy members, within the configured per\-operation removal limit\.Do not use it as a bulk pack restructuring tool\.•remove\_member must leave at least one original pack member\.If no core member can be kept, the pack cannot be repaired by deletion; use create\_fusion\_node, create\_edge, or no\_op instead\.•General remove\_member rule: remove a member only when it clearly breaks the pack’s "same concrete event segment" boundary\.Examples: a different activity instance, an unrelated time segment, a separate person storyline without interaction/evidence support, a different location/device scene that does not support the same event, a nearby system/environment reading with no event contribution, or a member that would force the summary into a broad daily log/topic bucket\.•Do not remove members that are before/after steps of the same event, family care/game/meal/return\-home follow\-ups in a continuous time segment, mutually supportive multi\-device observations, a dialogue and direct follow\-up action, an evidence chain for the same problem/conflict, complementary observations in the same household/dormitory scene, or cases where you are uncertain\.•After calling get\_pack\_members, choose one of three paths:1\.members are clean, so update\_fusion\_node with a clean summary if appropriate2\.a few clear noisy members exist, so remove\_member first and then update\_fusion\_node if appropriate3\.the pack is too mixed or needs many removals, so do not update that pack and use create\_fusion\_node, create\_edge, or no\_op•For full packs, the key question is not whether you can make room, but whether the pack is still one concrete event segment\.If there are obvious off\-topic members, remove them first\.If most members are mixed, keep only the coherent core when possible; otherwise do not merge the current event into the original pack\.•Do not repeatedly call get\_pack\_members for the same pack\. Use the member details already shown to submit a plan\.•If member relationships are clean but the old summary is polluted or too broad, do not remove members just to rewrite the summary; use update\_fusion\_node\.summary to rewrite a concrete summary covering the current pack members and the current new event\.•Keep fused summaries compact but evidence\-rich\.Preserve details that may matter in future QA: participants, source device, time order, concrete actions, objects, colors, counts, rounds/attempts, health readings, emotional reactions, care/concern, conflicts, viewpoint differences, and outcomes\.•Prefer create\_edge without fusion when events are causally related but belong to different concrete activity instances\. Prefer fusion only when events describe the same activity instance, short scene, or tightly connected evidence segment\.•If a causal relationship is plausible but the other endpoint is not visible as an exact candidate/member ID, do not output create\_edge\. Use no\_op or search\_memory with a targeted query if search budget remains\.•Prefer create\_fusion\_node over update\_fusion\_node when the existing pack has a different core activity, broad daily\-log scope, mixed subject lines, or would require the summary to become generic\.•Relatedness is not fusion\. If events only share the same topic, person, day, or device but lack concrete scene/activity continuity, prefer create\_edge or no\_op\.•Do not force noisy or weakly related events into a fused node\. If the current event is causally related but not part of the same concrete event segment, prefer create\_edge without fusion\.•Fusion is appropriate for multi\-device evidence in the same short scene, consecutive steps of the same activity instance, evidence before and after the same problem/conflict, a dialogue and its direct follow\-up action, or complementary observations in one household/dormitory event segment\.•When the default candidates are sufficient, prefer submit\_fusion\_plan directly\. Call search\_memory only when candidates are clearly insufficient and you have a clear new retrieval query\.•When the search\_memory budget is exhausted, submit a fusion plan using existing candidates; do not request more search\_memory calls\.•remove\_member is not a top\-level tool\. Do not output \{"tool":"remove\_member"\}; it can only appear as an operation inside submit\_fusion\_plan\.plan\.operations\.•When uncertain, choose none\. It is better not to fuse than to fuse incorrectly\.•You cannot write to the store directly; you can only output a JSON plan through submit\_fusion\_plan\.Each response must be exactly one JSON object in one of the following formats\.Call search\_memory:[⬇](data:text/plain;base64,ewogICJ0b29sIjogInNlYXJjaF9tZW1vcnkiLAogICJxdWVyeSI6ICJxdWVyeSB1c2VkIGZvciBhbm90aGVyIHJldHJpZXZhbCIKfQ==)\{"tool":"search\_memory","query":"queryusedforanotherretrieval"\}Call get\_pack\_members only when member\-level inspection is necessary:[⬇](data:text/plain;base64,ewogICJ0b29sIjogImdldF9wYWNrX21lbWJlcnMiLAogICJmdXNpb25fbm9kZV9pZCI6ICJmdXNlZCBub2RlIElEIHNob3duIGluIGNhbmRpZGF0ZXMiLAogICJsaW1pdCI6IDE1LAogICJyZWFzb24iOiAid2h5IHRoaXMgcGFjayBuZWVkcyBtZW1iZXItbGV2ZWwgaW5zcGVjdGlvbiIKfQ==)\{"tool":"get\_pack\_members","fusion\_node\_id":"fusednodeIDshownincandidates","limit":15,"reason":"whythispackneedsmember\-levelinspection"\}Submit fusion plan:[⬇](data:text/plain;base64,ewogICJ0b29sIjogInN1Ym1pdF9mdXNpb25fcGxhbiIsCiAgInBsYW4iOiB7CiAgICAib3BlcmF0aW9ucyI6IFsKICAgICAgewogICAgICAgICJ0eXBlIjogImNyZWF0ZV9lZGdlIiwKICAgICAgICAic291cmNlX2lkIjogImNodW5rX2lkIG9mIHRoZSBjYXVzZSBldmVudCIsCiAgICAgICAgInRhcmdldF9pZCI6ICJjaHVua19pZCBvZiB0aGUgZWZmZWN0IGV2ZW50IiwKICAgICAgICAiZWRnZV90eXBlIjogImNhdXNhbCIsCiAgICAgICAgInJlYXNvbiI6ICJ3aHkgdGhpcyBlZGdlIHNob3VsZCBiZSBjcmVhdGVkIgogICAgICB9LAogICAgICB7CiAgICAgICAgInR5cGUiOiAiY3JlYXRlX2Z1c2lvbl9ub2RlIiwKICAgICAgICAibWVtYmVyX2lkcyI6IFsiY3VycmVudCBuZXcgZXZlbnQgSUQiLCAiY2FuZGlkYXRlIGV2ZW50IElEIl0sCiAgICAgICAgInN1bW1hcnkiOiAibmV3IGZ1c2VkIG5vZGUgc3VtbWFyeSIsCiAgICAgICAgInJlYXNvbiI6ICJ3aHkgYSBuZXcgZnVzZWQgbm9kZSBzaG91bGQgYmUgY3JlYXRlZCIKICAgICAgfSwKICAgICAgewogICAgICAgICJ0eXBlIjogInVwZGF0ZV9mdXNpb25fbm9kZSIsCiAgICAgICAgImZ1c2lvbl9ub2RlX2lkIjogImZ1c2VkIG5vZGUgSUQgc2hvd24gaW4gY2FuZGlkYXRlcyIsCiAgICAgICAgImFkZF9tZW1iZXJfaWRzIjogWyJjdXJyZW50IG5ldyBldmVudCBJRCJdLAogICAgICAgICJzdW1tYXJ5IjogInVwZGF0ZWQgZnVzZWQgbm9kZSBzdW1tYXJ5IiwKICAgICAgICAicmVhc29uIjogIndoeSB0aGUgY3VycmVudCBldmVudCBiZWxvbmdzIGluIHRoaXMgZnVzZWQgbm9kZSIKICAgICAgfSwKICAgICAgewogICAgICAgICJ0eXBlIjogInJlbW92ZV9tZW1iZXIiLAogICAgICAgICJmdXNpb25fbm9kZV9pZCI6ICJmdXNlZCBub2RlIElEIHNob3duIGluIGNhbmRpZGF0ZXMiLAogICAgICAgICJyZW1vdmVfbWVtYmVyX2lkcyI6IFsibWVtYmVyIGNodW5rX2lkIHRvIHJlbW92ZSJdLAogICAgICAgICJzdW1tYXJ5IjogIm5ldyBzdW1tYXJ5IG9mIHRoZSByZW1haW5pbmcgZnVzZWQgbm9kZSBhZnRlciByZW1vdmFsIiwKICAgICAgICAicmVhc29uIjogIndoeSB0aGUgcmVtb3ZlZCBtZW1iZXJzIGFyZSBub2lzZSBmb3IgdGhpcyBjb25jcmV0ZSBldmVudCBzZWdtZW50IgogICAgICB9LAogICAgICB7CiAgICAgICAgInR5cGUiOiAibm9fb3AiLAogICAgICAgICJyZWFzb24iOiAid2h5IG5laXRoZXIgZnVzaW9uIG5vciBlZGdlIGNyZWF0aW9uIGlzIG5lZWRlZCIKICAgICAgfQogICAgXQogIH0KfQ==)\{"tool":"submit\_fusion\_plan","plan":\{"operations":\[\{"type":"create\_edge","source\_id":"chunk\_idofthecauseevent","target\_id":"chunk\_idoftheeffectevent","edge\_type":"causal","reason":"whythisedgeshouldbecreated"\},\{"type":"create\_fusion\_node","member\_ids":\["currentneweventID","candidateeventID"\],"summary":"newfusednodesummary","reason":"whyanewfusednodeshouldbecreated"\},\{"type":"update\_fusion\_node","fusion\_node\_id":"fusednodeIDshownincandidates","add\_member\_ids":\["currentneweventID"\],"summary":"updatedfusednodesummary","reason":"whythecurrenteventbelongsinthisfusednode"\},\{"type":"remove\_member","fusion\_node\_id":"fusednodeIDshownincandidates","remove\_member\_ids":\["memberchunk\_idtoremove"\],"summary":"newsummaryoftheremainingfusednodeafterremoval","reason":"whytheremovedmembersarenoiseforthisconcreteeventsegment"\},\{"type":"no\_op","reason":"whyneitherfusionnoredgecreationisneeded"\}\]\}\}Fusion standard: the events should belong to the same concrete activity instance, the same short\-time scene, the same event segment, or a mutually supportive evidence chain around the same problem/conflict\.Do not fuse merely because they share topic, person, day, or device\.create\_new is for multiple events that form the same concrete activity, same scene, short causal chain, or complementary observations in one event segment\.update\_existing is for a current new event that is a direct next step of an existing fused node, same\-scene complementary evidence, or a key detail that completes that event segment\.none is for cases without enough evidence for fusion or edge creation\.Summary requirements: write 1\-2 concise English sentences, ideally 40\-100 English words, including who, when, what specifically happened, and the key result\.Do not write a broad topic\.For update\_fusion\_node, summary must be the updated fused node summary, not the current event summary\.Preserve key people, time, actions, results, conflicts, and viewpoint differences from the old summary when they remain relevant to the same activity/scene\.You may compress minor background, but do not drop key information that changes the original meaning or affects future QA\.remove\_member\.summary must be the new pack summary after removing noisy members\.If update\_fusion\_node follows it, update\_fusion\_node\.summary must be the final pack summary\.

#### Fusion\-Aware Retrieval

This agentic retrieval loop uses two prompt templates: one to plan each round and one to judge accumulated evidence\. Each box below is one complete call containing its System and User messages; there are no separate calls for the planning rules or JSON schema\. The bracketed role labels and cross\-reference are presentation annotations rather than literal prompt text\. The controller may stop only after two rounds and is capped at five rounds\.

##### Round Retrieval Planning Prompt\.

This prompt asks the controller to propose the next structured retrieval plan for the current round\.

Round Retrieval Planning PromptSystemYou are the planning phase of an evidence\-aware memory retrieval controller\. Do not answer the question\. Emit one bounded, executable retrieval plan as strict JSON\.UserCreate the first retrieval plan for this question\.Original question:\{question\}Frozen question time:\{query\_time\}Question weekday/calendar reference:\{weekday\_calendar\_text\}Requester:\{requester\_id\}Planning\-field mapping for the unified Wrapper Controller:•focusis the primary standalone query and must preserve all relevant constraints from the original question\.•semantic\_queries,bm25\_query,keywords, andentitiescorrespond to the legacyquery\_rewritefields\.•coveragein the legacy rules meanscoverage\_diversificationhere; it is distinct from evidence\-facet coverage\.•The strings in the schema are descriptions, not default values\.Planning decision rules:•Query rewriting\.query\_rewritehas the highest priority and must not be distorted by later control strategies:–Every semantic query must preserve the main answer shape of the original question\.–Semantic queries should retrieve evidence events, not draft the final answer\.–If the original question asks for a full sequence, what exactly happened, a timeline, a process, or an experience, semantic\_queries must keep that process\-reconstruction intent\. Do not rewrite it into a why/cause query\.–Only generate cause\-oriented rewrites when the original question explicitly asks why, for the reason, what caused it, or how it happened\.–The first semantic\_query should stay close to the core wording of the original question; only compress, remove redundancy, and highlight keywords\.–Later semantic queries should cover complementary evidence facets, such as participant actions, device observations, location/object/state changes, before/after context, or source\-specific viewpoints\. Do not make all rewrites near\-duplicates\.–Preserve detail requests such as colors, quantities, durations, counts, game rounds, health readings, emotional reactions, care/concern, conflicts, viewpoints, and explicit objects; these details often decide checklist credit\.–For contradiction or record\-arbitration questions, preserve every competing value and source in both semantic\_queries and bm25\_query\. Include nearby evidence facets such as timestamps, pulse/score/count/unit fields, manual entry vs automated device source, and transcription/recording context when the original question compares two records\.–bm25\_query should remain close to the original question and keep exact lexical anchors\. Do not replace names/devices/objects with generic paraphrases in bm25\_query\.•Time\-window selection\.Settime\_windowonly when one bounded time span is useful for retrieval\. A calendar clue is not enough by itself\.–Disable time\_window for broad or longitudinal questions spanning multiple days, such as "this week", "past week", "over the week", "eventually", "from X to Y", "lead to … later", "commitments/plans this week", "everything bought/ordered this week", or questions mentioning multiple distinct dates\. These need semantic/BM25 coverage across days rather than one day crowding out other evidence\.–Disable time\_window when the question has no explicit date and the only time clue is a broad period like "this week" or "recently"\.–If a question contains both an initial event date and a later outcome date, do not choose only the initial date\. Disable time\_window unless the question asks specifically about one bounded episode\.•Enabled time windows\.Whentime\_window\.enabled=true, always output bothstart\_timeandend\_time\. The retrieval code cannot use a date\-only window\.–For date\-only questions such as an explicit calendar date, a named weekday, "that day", "all day", or "throughout the day", use start\_time="00:00:00" and end\_time="23:59:59"\.–Do not treat a question as date\-only if it contains a part\-of\-day or activity/session anchor\. Words such as morning, afternoon, evening, night, appointment, commute, clinic visit, or practice imply a narrower window\.–Do not infer a clock range from meal/session labels alone, such as dinner, breakfast, lunch, movie night, board game session, yoga session, or conversation, unless the question also gives an explicit time, part\-of\-day, or the answer asks only about that bounded session\. If the session label may be colloquial or the key anchors are topical \(for example treatment plans, purchases, bookings, reminders\), prefer semantic/BM25 retrieval with time\_window disabled or with a low quota\.–Sleep/night questions often refer to evidence recorded around wake\-up, not the whole daytime\. If the question asks about "that night", sleep quality, sleep score, sleep tracker/bed sensor records, or an earlier\-morning vs later\-morning sleep summary, do not use a full\-day daytime window\. Use the referenced morning window, usually 00:00:00\-09:59:59, and rely on exact sleep\-score/duration/device anchors for prior\-night evidence\.–When a question names a weekday/date but asks about sleep "that night" or "earlier that morning", the relevant evidence is the early\-morning sleep records for that resolved date, not the entire daytime\. Keep sleep\-score numbers, durations, and device names as lexical anchors\.–Explicit part\-of\-day words are stronger than a bare calendar date\. If the question says morning, afternoon, evening, night, or a similar part\-of\-day phrase, use that narrower range unless the question clearly spans multiple days\.–When both a date and a part\-of\-day/session anchor are present, keep the narrower part\-of\-day/session window instead of expanding to the full day\.–Use null start\_time/end\_time only when time\_window\.enabled=false\.•Relative weekday/date normalization\.–Use Question time as the reference point for relative dates and weekday names\.–If the question mentions a weekday such as Monday/Tuesday/Wednesday/Thursday/Friday/Saturday/Sunday without an explicit calendar date, choose the most recent matching weekday at or before Question time, not an arbitrary weekday from the same week\.–If the weekday in the question is the same weekday as Question time and the question describes an event that could already have happened, use Question time’s date\.–If the question says "last", "yesterday", "earlier", "this morning", "tonight", or similar relative wording, resolve it strictly relative to Question time\.–If the question names a weekday night and the evidence may continue after midnight, anchor the window to the named weekday and use evening/night hours; do not shift the whole window to the next day\.–If you cannot confidently resolve a weekday/date from Question time, set confidence below 0\.6 rather than inventing a high\-confidence date\.•Vague\-time normalization\.Normalize vague times with these ranges; do not expand morning/evening into the whole day:–pre\-dawn: 00:00:00\-05:59:00–early morning: 06:00:00\-09:59:00–morning: 05:00:00\-11:59:00–noon: 11:00:00\-13:59:00–afternoon: 13:00:00\-17:59:00–dusk: 17:00:00\-19:59:00–evening/night: 18:00:00\-23:59:00•Coverage diversification\.Enable coverage when the question requires complete coverage across multiple people, devices, places, sources, or viewpoints, such as comparing parties, explaining each one separately, all related people/device states, who was present, or what each source observed\. Do not enable coverage for a single subject’s cause, state, or fact query\.•Timeline mode\.Enabletimeline\_modewhen the answer needs multiple ordered steps, such as a full sequence, route/itinerary, key milestones, phase changes, repeated attempts, multiple rounds, a morning/day reconstruction, or the process from one time to another\. Do not enable it for a single\-point reason or single fact query\.•Temporal\-neighbor decision table\.–Enable when the question explicitly asks for a full sequence, timeline, total occurrences, each occurrence, a continuous period, a before/after progression, dialogue followed by actions, or a multi\-step activity where adjacent snippets around hit events are needed in context\.–Disable for ordinary why/reason/state/existence/how questions\. Do not enable merely because a question is causal; multi\-subject coverage also does not imply temporal\_neighbors\.–radius defaults to 3; use 1\-2 only for very short point\-context questions\.•Seed time\-window quota decision table\.–Default is 15\.–Use 20 when coverage\.enabled=true and timeline\_mode\.enabled=false\.–Use 25 when timeline\_mode\.enabled=true and time\_window\.enabled=true only if the time window is narrower than a full day\.–Use 25 for explicit claim\-verification questions with a date/time anchor, especially when the question asks whether a statement was true, accurate, supported by evidence, contradicted by records, or what actually happened\. These questions need same\-window corroborating and contradicting events, not just semantically similar older events\.–Use 25 for narrow activity/session windows when the question asks what happened during a conversation, dinner, movie night, board game session, yoga session, appointment, commute, clinic visit, or practice; the answer often depends on several adjacent snippets inside that session\.–For full\-day/date\-only windows such as a named weekday, an explicit calendar date, "that day", or 00:00:00\-23:59:59, do not let the time window crowd out semantic/BM25 seeds:\*Use 15 for full\-day timeline, full\-day reconstruction, complete sequence, throughout\-the\-day progression, or multi\-person/multi\-device coverage\.\*Use 10\-12 for full\-day questions about a specific subject, object, appointment, decision, purchase, message, or incident\.\*Use 20 only when the question explicitly asks for all events across the whole day and lexical anchors are weak\.–Do not go below 15 unless there is no time\_window\.–Never use a full\-day quota merely because a calendar date is present\. First decide whether the question has a narrower activity/session anchor; if it does, use the narrower window and its normal quota\.•Seed temporal\-neighbor keep decision table\.–Default is 24\.–When temporal\_neighbors\.enabled=true, still default to 24: first keep 24 original seeds, then use the remaining slots for adjacent events\.–Do not go below 24 unless the question clearly requires continuous adjacent\-snippet coverage and original semantic recall is not important\.•Confidence\.Control confidence means confidence in the enabled decision: clear enable \-\>enabled=trueand 0\.7\-1\.0; clear disable \-\>enabled=falseand 0\.7\-1\.0; ambiguous \-\> 0\.4\-0\.5\.•Semantic queries\.semantic\_queriesshould cover different retrieval intents of the question without adding unknown facts\. Prefer 2\-3 queries when the question asks for multi\-hop, multi\-detail, multi\-source, timeline, comparison, or checklist\-like evidence\.•Minimum query coverage\.Provide at least one semantic query unless the original question is already very short and cannot be usefully rewritten\.•Keywords\.keywordsmust be short terms extracted from the original question for lexical matching within time windows\. Prefer people, places, devices, objects, actions, numbers, colors, game/activity words, health readings, and state words\. Do not output long phrases, full sentences, generic words, or negated/intensified compound phrases\.•Entities\.entitiesmust be people, places, devices, or objects extracted from the original question\. Do not leave it empty when such entities exist\.•Output format\.Output JSON only, no markdown\.Output exactly one plan object using this schema:[⬇](data:text/plain;base64,ewogICJmb2N1cyI6ICJPbmUgc3RhbmRhbG9uZSBwcmltYXJ5IHF1ZXJ5IHByZXNlcnZpbmcgZXZlcnkgcmVsZXZhbnQgb3JpZ2luYWwgY29uc3RyYWludCIsCiAgInNlbWFudGljX3F1ZXJpZXMiOiBbIlVwIHRvIDMgY29tcGxlbWVudGFyeSBldmlkZW5jZSBxdWVyaWVzOyBlYWNoIGF0IG1vc3QgODAgY2hhcmFjdGVycyJdLAogICJibTI1X3F1ZXJ5IjogIkxpdGVyYWwgcXVlcnkgcmV0YWluaW5nIGV4YWN0IGxleGljYWwgYW5jaG9ycyIsCiAgImtleXdvcmRzIjogWyJTaG9ydCBsaXRlcmFsIGtleXdvcmQgZXh0cmFjdGVkIGZyb20gdGhlIHF1ZXN0aW9uIl0sCiAgImVudGl0aWVzIjogWyJQZXJzb24sIHBsYWNlLCBkZXZpY2UsIG9yIG9iamVjdCBwcmVzZW50IGluIHRoZSBxdWVzdGlvbiJdLAogICJ0aW1lX3dpbmRvdyI6IHsKICAgICJlbmFibGVkIjogImJvb2xlYW47IHRydWUgb25seSBmb3Igb25lIGNvbmZpZGVudGx5IHBhcnNlZCBib3VuZGVkIHNwYW4iLAogICAgImRhdGUiOiAiWVlZWS1NTS1ERCBvciBudWxsIiwKICAgICJzdGFydF90aW1lIjogIkhIOk1NOlNTIG9yIG51bGwiLAogICAgImVuZF90aW1lIjogIkhIOk1NOlNTIG9yIG51bGwiLAogICAgImNvbmZpZGVuY2UiOiAiMC4wLTEuMDsgY29uZmlkZW5jZSBpbiB0aGUgZW5hYmxlZCBkZWNpc2lvbiIKICB9LAogICJjb3ZlcmFnZV9kaXZlcnNpZmljYXRpb24iOiB7CiAgICAiZW5hYmxlZCI6ICJib29sZWFuOyBkaXZlcnNpZnkgYWNyb3NzIHVzZXIgYW5kL29yIGRldmljZSIsCiAgICAiZGltZW5zaW9ucyI6IFsiT25seSB1c2VyIGFuZC9vciBkZXZpY2UiXSwKICAgICJjb25maWRlbmNlIjogIjAuMC0xLjA7IGNvbmZpZGVuY2UgaW4gdGhlIGVuYWJsZWQgZGVjaXNpb24iCiAgfSwKICAidGVtcG9yYWxfbmVpZ2hib3JzIjogewogICAgImVuYWJsZWQiOiAiYm9vbGVhbjsgd2hldGhlciBhZGphY2VudCBldmVudCBzbmlwcGV0cyBhcmUgbmVlZGVkIiwKICAgICJyYWRpdXMiOiAiaW50ZWdlcjsgcmVjb21tZW5kZWQgMS0zIiwKICAgICJjb25maWRlbmNlIjogIjAuMC0xLjA7IGNvbmZpZGVuY2UgaW4gdGhlIGVuYWJsZWQgZGVjaXNpb24iCiAgfSwKICAidGltZWxpbmVfbW9kZSI6IHsKICAgICJlbmFibGVkIjogImJvb2xlYW47IHdoZXRoZXIgb3JkZXJlZCBtdWx0aS1zdGVwIHJlY29uc3RydWN0aW9uIGlzIG5lZWRlZCIsCiAgICAiY29uZmlkZW5jZSI6ICIwLjAtMS4wOyBjb25maWRlbmNlIGluIHRoZSBlbmFibGVkIGRlY2lzaW9uIgogIH0sCiAgInNlZWQiOiB7CiAgICAidGltZV93aW5kb3dfcXVvdGEiOiAicG9zaXRpdmUgaW50ZWdlciBvciBudWxsIiwKICAgICJ0ZW1wb3JhbF9uZWlnaGJvcl9rZWVwIjogInBvc2l0aXZlIGludGVnZXIgb3IgbnVsbCIKICB9Cn0=)\{"focus":"Onestandaloneprimaryquerypreservingeveryrelevantoriginalconstraint","semantic\_queries":\["Upto3complementaryevidencequeries;eachatmost80characters"\],"bm25\_query":"Literalqueryretainingexactlexicalanchors","keywords":\["Shortliteralkeywordextractedfromthequestion"\],"entities":\["Person,place,device,orobjectpresentinthequestion"\],"time\_window":\{"enabled":"boolean;trueonlyforoneconfidentlyparsedboundedspan","date":"YYYY\-MM\-DDornull","start\_time":"HH:MM:SSornull","end\_time":"HH:MM:SSornull","confidence":"0\.0\-1\.0;confidenceintheenableddecision"\},"coverage\_diversification":\{"enabled":"boolean;diversifyacrossuserand/ordevice","dimensions":\["Onlyuserand/ordevice"\],"confidence":"0\.0\-1\.0;confidenceintheenableddecision"\},"temporal\_neighbors":\{"enabled":"boolean;whetheradjacenteventsnippetsareneeded","radius":"integer;recommended1\-3","confidence":"0\.0\-1\.0;confidenceintheenableddecision"\},"timeline\_mode":\{"enabled":"boolean;whetherorderedmulti\-stepreconstructionisneeded","confidence":"0\.0\-1\.0;confidenceintheenableddecision"\},"seed":\{"time\_window\_quota":"positiveintegerornull","temporal\_neighbor\_keep":"positiveintegerornull"\}\}

##### Round Evidence Controller Prompt\.

This prompt asks the controller to judge accumulated evidence and decide whether another retrieval round is needed\.

Round Evidence Controller PromptSystemYou are an evidence\-aware memory retrieval controller and planner\.Judge accumulated evidence, select direct evidence IDs, and when another round is needed emit one executable structured retrieval plan\.Do not answer the question\. Return strict JSON\.UserOriginal question:\{question\}Current search query:\{current\_query\}Frozen question time:\{query\_time\}Current executed round plan:\{current\_plan\}Queries already searched:\{searched\_queries\}Executed plan history:\{plan\_history\}Completed round:\{current\_round\};minimum rounds before stopping:\{minimum\_rounds\}This is the final allowed round:\{final\_round\}Accumulated evidence candidates:[⬇](data:text/plain;base64,e2V2aWRlbmNlfQ==)\{evidence\}Setsufficient=trueonly when every material facet of the question is directly supported by the retrieved evidence\.Do not stop merely because the evidence suggests a plausible answer\.Treat required people, events, time constraints, causal links, comparisons, and cross\-device facts as separate facets when they matter\.For every facet, cite one or more candidate IDs\. A fused summary is valid evidence only when it directly contains the needed fact\.Before round\{minimum\_rounds\},sufficientmust remain false even when coverage appears complete\.Emit a focused verificationnext\_planthat seeks independent direct evidence for the covered facets\.This prevents a single retrieval pass from authorizing its own early stop\.If any required facet lacks direct evidence, setsufficient=false, list it inmissing\_facets, and emit onenext\_plantargeting the most important missing facts\.Its focus and rewrites must preserve all relevant people, dates, time ranges, devices, answer shape, and other constraints from the original question\.Do not repeat a plan already present in the executed plan history\.On the final allowed round, do not claimsufficientunless all facets are actually covered; still return the best available selection when coverage is incomplete\.selected\_idsis an ordered priority shortlist and does not need to contain\{top\_k\}IDs\.The retrieval system will fill any remaining slots from the accumulated candidate pool\.When another round is allowed andsufficient=false,next\_planmust be a plan object following the rules and schema below\. Whensufficient=trueor this is the final round,next\_planmust be null\.\[The same planning\-field mapping and complete Query Planner decision rules shown in the initial\-round call are inserted here verbatim\.\]next\_plan schema:\[The same round\-plan JSON schema shown in the initial\-round call is inserted here verbatim\.\]Output exactly:[⬇](data:text/plain;base64,ewogICJjb3ZlcmFnZSI6IFsKICAgIHsKICAgICAgImZhY2V0IjogInJlcXVpcmVkIGZhY3QiLAogICAgICAiY292ZXJlZCI6IHRydWUsCiAgICAgICJldmlkZW5jZV9pZHMiOiBbImNhbmRpZGF0ZV9pZCJdCiAgICB9CiAgXSwKICAic3VmZmljaWVudCI6IHRydWUsCiAgIm1pc3NpbmdfZmFjZXRzIjogW10sCiAgInNlbGVjdGVkX2lkcyI6IFsiY2FuZGlkYXRlX2lkIl0sCiAgIm5leHRfcGxhbiI6IG51bGwKfQ==)\{"coverage":\[\{"facet":"requiredfact","covered":true,"evidence\_ids":\["candidate\_id"\]\}\],"sufficient":true,"missing\_facets":\[\],"selected\_ids":\["candidate\_id"\],"next\_plan":null\}

### Evaluation Prompts

#### Reader

##### Full\-context system prompt\.

This prompt tells the reader how to answer when the entire event stream is available as context\.

Full\-Context System PromptYou are a household smart assistant\. The following is an event stream recorded by smart devices in the home, including cameras, watches, speakers, and sensors\.Each event record is formatted as: \[time\] \[device\] \[location\] event description\.Answer the user’s question accurately and completely based on these event records\.When useful for answering, include relevant concrete details from the records, especially times, dates, numbers, device/app names, locations, people involved, and actions taken\.Use only information from the event records\. Do not fabricate or infer unsupported content\.If the event records are insufficient for a complete answer, answer as well as possible based on the available information\.

##### Retrieved\-context system prompt\.

This prompt tells the reader how to answer when only retrieved evidence is available\.

Retrieved\-Context System PromptYou are a household smart assistant\. The following event records may be relevant to the user’s question and were retrieved from smart devices in the home\.Each event record is formatted as: \[time\] \[device\] \[location\] event description\.Answer the user’s question accurately and completely based on these event records\.When useful for answering, include relevant concrete details from the records, especially times, dates, numbers, device/app names, locations, people involved, and actions taken\.Use only information from the event records\. Do not fabricate or infer unsupported content\.If the provided information is insufficient for a complete answer, answer as well as possible based on the available information\.

##### Shared reader user prompt\.

This prompt provides the retrieved context, questioner identity, question time, and question to the shared reader\.

Shared Reader User PromptEvent Records:[⬇](data:text/plain;base64,e2NvbnRleHR9)\{context\}Questioner: \{question\_user\}Question Time: \{question\_time\}Question: \{question\}

#### LLM\-as\-judge

##### Judge system prompt\.

This prompt instructs the judge to evaluate checklist coverage and output JSON only\.

Judge System PromptYou are a rigorous evaluation expert responsible for judging answer checklist coverage\. Always output JSON\.

##### Judge user prompt\.

This prompt supplies the question, system answer, and checklist items to the judge\.

Judge User PromptYou are an evaluation expert\. Determine whether the system answer covers each key information point\.Question: \{question\}System Answer:\{system\_answer\}Judge each item below for whether it is covered by the system answer \(directly stated or clearly implied both count as covered\)\.Evaluation criteria: be tolerant of wording differences, but strict about factual correctness\. If the system answer contains the core meaning of the item, it counts as covered even with different wording\.Checklist Items:\{checklist\_text\}Output strictly as a JSON array and do not output anything else:[⬇](data:text/plain;base64,WwogIHsKICAgICJpbmRleCI6IDEsCiAgICAicG9pbnQiOiAiY2hlY2tsaXN0IGl0ZW0gdGV4dCIsCiAgICAiY292ZXJlZCI6IHRydWUsCiAgICAicmVhc29uIjogImJyaWVmIGV4cGxhbmF0aW9uIgogIH0sCiAgLi4uCl0=)\[\{"index":1,"point":"checklistitemtext","covered":true,"reason":"briefexplanation"\},\.\.\.\]