image. Given this image, we generate sessions through a dual-model simulation with GPT-5.1 [2]
as the user and Gemini-3-Pro [59] as the assistant, producing multi-turn dialogues that incorporate
the selected images into interleaved image-text sequences [60]. Because image selection precedes
dialogue generation, image–text alignment is a structural property of the data rather than a post-hoc
filter. The image retrieval pipeline (§C.5), full topic ontology (§C.2), and image diversity statistics
(§C.6) are detailed in the Appendix.

Question-Answer Pair. Question generation follows a four-step pipeline. (i) A topic is sampled
from the hierarchical ontology, and a LVLM generates a background paragraph containing salient
named-entities, for instance, a paragraph about San Francisco landmarks that mentions the Golden
Gate Bridge. (ii) One entity is selected as the visual anchor for the question. A text query derived
from the entity is issued to the same web-crawling and multi-model scoring pipeline used for haystack
images (§C.5), yielding a high-relevance image [61]; the anchor may range from a famous landmark
to a specific product model. (iii) Cross-modal dependency is enforced through entity abstraction [62–
64]: the entity in the background paragraph is replaced with a higher level concept drawn from
a dictionary spanning 55 entity categories (e.g., “Golden Gate Bridge” → “the bridge shown in
<image>”). After replacement, the paragraph no longer names the entity, and only the evidence
image can resolve the reference. (iv) The abstracted paragraph, evidence image, and original entity
name are provided to Gemini-3-Pro [59], which generates a (question, answer) pair together with
atomic evidence facts. The generation prompt constrains the question to require both the image and
the surrounding text, closing the text-only shortcut documented in prior work [16]. The full pipeline
and per-subtype generation routes appear in Appendix C.4.

Evidence session. Directly inserting evidence statements into the conversation history creates
abrupt semantic shifts that make the evidence trivially locatable by similarity-based retrieval. Prior
work has shown that increasing contextual similarity between evidence and distractors raises retrieval
difficulty, a design principle also adopted by LongMemEval [14]. Accordingly, each evidence fact
is wrapped in a complete evidence session generated using the same pipeline as haystack sessions
but grounded on the evidence fact rather than a sampled topic. Consequently, the evidence facts
match the topical and stylistic profile of the surrounding haystack, so that evidence cannot be located
by surface-level shortcuts. To further increase the difficulty, we also prompt the user model to
mention the facts indirectly without stressing them: To embed the fact “I started a new job last
month,” the user turn might open by asking about updating the tax withholding and mention the job
change incidentally later. When an evidence fact carries an evidence image, the image is placed
adjacent to the corresponding textual mention within the session, preserving unambiguous image-text
co-reference after entity abstraction.

Conversation history assembly. For each question, evidence              Table 2: Dataset statistics.
sessions are inserted into a timestamp-ordered history of haystack
sessions, with positions chosen uniformly at random (for KU, we Statistic                        Value
preserve the evidence-session order; Appendix C.8). Haystack Questions                              789
sessions are curated to be contextually related but uninformative Types / Subtypes                 5/9
for the question, and never include answer-relevant details. We Evidence sessions                 2,145
vary the number of haystack sessions to produce four standardized Avg. turns/session               ∼10
context lengths (32K/64K/128K/256K tokens) using the cross- Avg. images/session                   ∼1.5
modal counting scheme of MMLongBench [11] (Table 2). To Tokens/image                           ∼2,000
avoid revealing evidence positions via image clustering, we keep                          32K → 256K
a fixed text-per-image ratio across the history, padding with text- Sessions/instance         14 → 93
only filler sessions from ShareGPT and UltraChat [65]. A post- Images/instance              20 → 138
hoc classifier achieves only marginally above-chance accuracy
when separating evidence from haystack text (Appendix G.8), and the generator scales beyond 256K.

3.3   Quality Control

Automated filtering. Each candidate question is screened by two automated checks. A rule-based
pre-filter removes images from the question and evidence and drops cases where the remaining text
already determines the answer. An LLM judge (GPT-5.1 [2]) then sees only the question text (without
evidence or conversation history) and removes items solvable from parametric knowledge alone [66].


                                                  5
