PaperlayerView exact revision on arXiv

Source-linked AI summary

Personalized State-Transition-Aware Memory for Clinical Agents

Maryam Haghifam, Zahra Rajabi, Yizhou Sun, Carlos Morato

arXiv:2609.38490v1cs.CLcs.AI

TL;DR

Longitudinal clinical memory must track which information still describes a patient’s current state without losing history needed to understand treatment changes and clinical trajectories. STAM combines semantic retrieval with typed clinical relations to update affected memories and selectively serve history. Across four benchmarks, it shows improved state-maintenance diagnostics and several significant gains over memory and retrieval baselines at approximately matched context lengths, with no significant decreases.

  • Problem

    Clinical memory must distinguish information that still describes a patient’s current state from prior information needed to understand treatment history and clinical trajectories.

    Source: §1 · pp. 1–2

  • Method

    STAM combines semantic retrieval with typed clinical-relation graph discovery to identify affected memories, preserves superseded or resolved information in HISTORY, and uses a query-dependent gate to selectively serve it.

    Source: §1 · p. 2, §3.2 · p. 4

  • Results

    Across four benchmarks, STAM improves supersession tracking and lowers false archival versus simpler controls, with significant gains in several approximately context-matched baseline comparisons and no significant decreases.

    Source: §1 · p. 2, §5.1 · p. 7, §7 · p. 9

  • Takeaways & Limitations

    The results support evaluating longitudinal memory by both state maintenance and evidence serving, since downstream performance also depends on which maintained memories are exposed to the reader.

    Source: §7 · p. 9

    The local write path is evaluated only with Qwen3-1.7B, the relation vocabulary is handspecified, and deletion relies on LLM-derived rather than clinician-validated endurance labels.

    Source: §7 · p. 10

Abstract

from arXiv · show

Large language model (LLM) agents that reason over clinical records must track changes in a patient's state while preserving the history needed to understand them. Simply accumulating memories leaves it unclear which information still applies, whereas overwriting earlier memories can erase evidence needed to reconstruct treatment history and clinical trajectories. We introduce STAM, a state-transition-aware memory framework that records state changes as new clinical entries arrive. STAM combines semantic retrieval with typed clinical relations to identify affected memories, maintaining current information in Active and superseded or resolved information in History. At read time, a query-dependent gate selectively serves historical memory. Across four longitudinal clinical benchmarks, we evaluate STAM with downstream question answering, direct state-maintenance diagnostics, and comparisons at approximately matched context lengths.

1 INTRODUCTION

Longitudinal clinical memory must distinguish information that still describes a patient’s current state from history needed to understand treatment changes and clinical trajectories. STAM maintains these state changes over time and evaluates both state maintenance and downstream question answering.

1 INTRODUCTION

  • Similarity-based retrieval can return an earlier dose alongside an updated one, although the earlier dose remains relevant to treatment history rather than the current regimen.MedCache reports outdated evidence as the largest error category for seven of eight systems in its error analysis (Chan et al., 2026).Source: §1 · p. 1
  • Because temporal order alone cannot determine whether new evidence supersedes, qualifies, or coexists with an earlier fact, state maintenance must consider clinical content and relationships.A new medication may supplement an existing regimen, and treatment changes may affect related monitoring plans.Source: §1 · pp. 1–2
  • STAM combines semantic retrieval with typed clinical-relation graph discovery to identify memories affected by new evidence, keeping applicable information in ACTIVE and superseded or resolved information in HISTORY.A query-dependent decision governs whether historical memories are included when answering.Source: §1 · p. 2
  • Across four longitudinal clinical benchmarks, STAM improves supersession tracking and lowers false archival versus simpler state-maintenance controls; at approximately matched context lengths, it has significant gains in several baseline comparisons and no significant decreases.Evaluation includes direct state-maintenance diagnostics and downstream question answering.Source: §1 · p. 2

2 RELATED WORK

Prior work addresses general LLM memory organization, evolving-state tracking, and longitudinal clinical reasoning. STAM focuses on identifying clinically related memories affected by new evidence and directly evaluating write-time state decisions.

2.1 LONG-TERM MEMORY SYSTEMS FOR LLM AGENTS

  • General LLM memory systems organize, retrieve, or update memories, while STAM targets changing clinical state by identifying earlier memories affected by new evidence and preserving prior states for historical questions.The cited systems include A-MEM, Mem0, LightMem, MemOS, MemRL, and Memory-R1 (Xu et al., 2025; Chhikara et al., 2025; Fang et al., 2026; Li et al., 2025; Zhang et al., 2026a; Yan et al., 2026).Source: §2.1 · p. 2
  • STAM’s store gate decides whether historical memory should be included for a query, rather than selecting a retrieval strategy based on query complexity.Self-RAG and Adaptive-RAG are cited as related adaptive retrieval approaches (Asai et al., 2024; Jeong et al., 2024).Source: §2.1 · pp. 2–3

2.2 TEMPORAL VALIDITY AND EVOLVING STATE IN AGENT MEMORY

2.3 LONGITUDINAL CLINICAL MEMORY AND REASONING

  • Compared with MedCache’s temporal curation, specialty-based organization, and query routing, STAM emphasizes write-time identification of clinically related memories whose status may change.Both approaches are evaluated for downstream question answering; STAM also evaluates write-time processing under controlled evidence lengths.Source: §2.3 · p. 3

3 METHOD

STAM represents longitudinal clinical memory as current and historical stores linked by a relation graph, then updates affected memories as new entries arrive. At read time it selectively serves history, while permanent deletion is handled separately.

3.1 SETTING AND FRAMEWORK OVERVIEW

  • STAM represents memory after each update as ACTIVE and HISTORY stores plus a relation graph, with update order distinct from the clinical time described by an entry.ACTIVE represents maintained current state, while HISTORY preserves superseded or resolved memories.Source: §3.1 · p. 3

3.2 WRITE PATH: MEMORY CONSTRUCTION AND STATE UPDATE

  • The write path extracts atomic memories, links them to relevant ACTIVE memories, retrieves potentially affected memories, and updates their states rather than reconsidering the entire memory after each entry.The relation vocabulary includes restatement, same condition thread, drug interaction, systemic link, causal, treatment for, and monitoring for; the framework does not require this fixed vocabulary.Source: §3.2 · pp. 3–4
  • Impact retrieval unions semantic retrieval with one-hop graph discovery to find affected memories, including dependency-mediated effects that may be less semantically similar to new evidence.The search considers both ACTIVE and HISTORY; graph discovery can surface related monitoring plans or interaction constraints.Source: §3.2 · p. 4
  • The updater uses clinical content and temporal relations to decide whether incoming information belongs to the current or a prior state and whether affected ACTIVE memories remain current.Superseded or resolved memories move to HISTORY with a reason for the transition and, when applicable, a link to newer memory; proposed deletion is separate from permanent removal.Source: §3.2 · p. 5

3.3 READ PATH: STATE-AWARE EVIDENCE SELECTION

  • At read time, retrieval searches ACTIVE and HISTORY separately, and a store gate chooses whether the answering model receives ACTIVE candidates alone or candidates from both stores.The gate uses query–memory similarity signals; agreement between serving arms proxies for whether HISTORY is needed because the benchmarks do not annotate that need.Source: §3.3 · p. 5, §3.4 · p. 5

3.4 SELECTIVE HISTORY SERVING

  • The history-serving threshold is selected using replayed answer quality on training folds and fixed before evaluation; λ controls the trade-off between answer quality and serving efficiency.The benchmarks do not label whether a question requires HISTORY.Source: §3.4 · p. 5

3.5 CONSERVATIVE MEMORY DELETION

  • Because HISTORY grows over follow-up, STAM separates state updating from permanent removal and applies a conservative deletion gate only to archived memories.Deletion labels, calibration, and diagnostics are reported in Appendix F.Source: §3.5 · p. 5, §3.2 · p. 5

4 EXPERIMENTAL SETUP

The experiments use four clinical benchmarks spanning synthetic longitudinal interactions, MIMIC-grounded dialogues, structured EHR events, and clinical notes. They compare persistent memory systems under benchmark-specific scoring and reader configurations.

4 EXPERIMENTAL SETUP

  • The four benchmarks cover synthetic longitudinal interactions, MIMIC-grounded synthetic dialogues, structured EHR event sequences, and clinical notes.They include MedMemoryBench, MedLoCoMo, MIMIC-QA, and ClinicalBench.Source: §4 · p. 5
  • The local write path uses Qwen3-1.7B, final answer generation uses Qwen3-4B-Instruct-2507, and dense retrieval uses BGE-small-en-v1.5.GPT-5 evaluations use the fixed gpt-5-2025-08-07 snapshot.Source: §4 · p. 6
  • Full Context serves temporally ordered raw records up to each reader’s context limit, truncating oldest entries first when needed; Flat RAG retrieves semantically ranked chunks without structured memory construction.On MedMemoryBench, 329 of 496 GPT-5 Full Context inputs require truncation.Source: §4 · p. 6
  • Scoring is benchmark-specific: macro accuracy for MedMemoryBench, type-macro F1 for MedLoCoMo, mean token-level F1 for MIMIC-QA, and pooled accuracy for ClinicalBench.Table 1 reports answer quality under Qwen3-4B-Instruct and GPT-5 readers.Source: §4 · p. 6, Table 1 · p. 6

5 RESULTS

Across matched-context comparisons, STAM gains significantly in several comparisons without significant decreases, while results on temporal questions and against reference strategies vary by dataset and reader. Serving volume, evidence selection, and selective access to HISTORY also affect measured performance.

5.1 COMPARISON WITH MEMORY SYSTEMS

  • Six of 17 Qwen3-4B context-matched comparisons significantly favor STAM, with no significant decreases.The comparisons include a +7.15 Token-F1 difference over Flat RAG on MIMIC-QA and gains over several memory baselines.Source: §5.1 · p. 7

5.2 STATE- AND TEMPORAL-QUESTION ANALYSIS

  • With Qwen3-4B-Instruct, STAM exceeds Full Context in all four reported state- and time-oriented categories; GPT-5 results are mixed across datasets.For GPT-5, STAM scores 68.0 vs. 66.0 on MedMemoryBench state-update questions and 24.8 vs. 28.9 on MedLoCoMo longitudinal progression.Source: §5.2 · p. 7

5.3 EVIDENCE SERVING AND SELECTIVE HISTORY

  • On MedMemoryBench, all-memory serving reaches 63.84 macro accuracy versus 63.17 for Full Context; on MedLoCoMo, 4,500-word ranking reaches 40.75 type-macro F1 versus 42.53.The MedMemoryBench diagnostic is not context matched, and Full Context is truncated for 329 of 496 questions; on MedLoCoMo, the ranked condition serves 4,494 versus 25,157 median words.Source: §5.3 · p. 7
  • The Store Gate omits HISTORY for 1.0%–79.0% of queries across selected local-reader configurations, with no significant answer-quality change and lower prompt length and prefill TTFT.The benchmarks do not annotate whether questions require HISTORY; the gate uses agreement between serving arms as a proxy.Source: §5.3 · pp. 7–8

5.4 REFERENCE STRATEGIES AND MEMORY CONTROLS

  • Against Full Context and Flat RAG, STAM’s relative performance varies by dataset; with GPT-5, Full Context leads on three datasets, while STAM’s MIMIC-QA edge is nonsignificant.For Qwen3-4B-Instruct, STAM is higher than Full Context on MedMemoryBench and MIMIC-QA but lower on MedLoCoMo and ClinicalBench; it is lower than Flat RAG on MedMemoryBench and higher on the other three benchmarks.Source: §5.4 · p. 8
  • At the calibrated threshold, deletion removes 2.3% of MedMemoryBench memories with 92.9% safe-to-forget precision and 0.3% never-forget loss, without evidence of aggregate QA degradation.Paired evaluation yields 20 improved and 14 regressed answers (p = .39).Source: §5.4 · p. 8

6 ABLATION STUDIES

Historical evidence helps some dataset–reader settings but not others, while write-time comparisons favor state-aware updating and relation-aware impact discovery over simpler controls. The component results also show that typed relations affect both archival decisions and downstream answer quality.

6.1 HISTORICAL MEMORY ACCESS

  • The contribution of HISTORY depends on dataset and answering configuration: access improves results in some settings, is negligible on MedLoCoMo with Qwen3-4B-Instruct, and slightly reduces results in two GPT-5 settings.The matched-volume refill control is used to separate effects of historical content from reduced serving volume.Source: §6.1 · p. 8

6.2 WRITE-TIME STATE MAINTENANCE

  • STAM is numerically higher than append-only memory on all four benchmarks, testing the benefit of state-aware updating beyond retaining earlier information.The paired comparison uses the Qwen3-4B-Instruct reader; Table 4 reports score-point deltas by benchmark-specific metric.Source: §6.2 · p. 8, Table 4 · p. 9
  • At the same candidate budget, the full pipeline reaches 53.9% supersession-pair recall and 7.6% false archival, versus 51.6% and 12.3% with semantic retrieval alone.A deterministic supersession rule yields 28.6% recall and 17.6% false archival; the comparison is a pipeline-level control, not an attribution to one component.Source: §6.2 · p. 9, Table 5 · p. 9
  • Removing typed relations raises the archived fraction from 23.6% to 63.3% and lowers MIMIC-QA Token-F1 from 55.3 to 52.1.Reference evidence items placed in HISTORY rise from 253 to 531, a count interpreted alongside the larger archived fraction.Source: §6.2 · p. 9, Table 5 · p. 9

7 CONCLUSION

STAM separates current clinical information from superseded or resolved memories while preserving transitions. The reported evidence supports assessing longitudinal memory through both state maintenance and evidence serving, with limitations in writer capacity, relation design, and deletion labels.

7 CONCLUSION

  • STAM separates current from superseded or resolved information while preserving transitions between them.The framework’s results support evaluating longitudinal memory by both state maintenance and evidence serving.Source: §7 · p. 9
  • At approximately matched evidence lengths, STAM has several significant improvements and no significant decreases, while performance also depends on which maintained memories reach the reader.State-maintenance diagnostics show improved organization of evolving state, and append-only comparisons show numerically higher downstream performance.Source: §7 · p. 9
  • The local write path is evaluated only with Qwen3-1.7B; the relation vocabulary is hand-specified, and deletion uses LLM-derived rather than clinician-validated endurance labels.The paper does not characterize how state-maintenance quality changes with writer capacity.Source: §7 · p. 10

A DATASET AND EVALUATION PROTOCOLS

The evaluation uses four clinical benchmarks with distinct cohort construction and record representations. It applies benchmark-specific scoring and paired controls for reader variation and statistical comparisons.

A DATASET AND EVALUATION PROTOCOLS

  • MedMemoryBench evaluation uses questions from five personas across 505 sessions, while MedLoCoMo uses a stratified 320-question subset spanning 12 patients.MedMemoryBench contributes 496 questions; MedLoCoMo’s full collection contains 17,892 QA items.Source: A DATASET AND EVALUATION PROTOCOLS · p. 12
  • MIMIC-QA contains 2,000 template-based QA pairs from 100 patients, with patient-level 70/10/20 train, validation, and test splits; ClinicalBench uses its full 400-question release.MIMIC-QA questions are recomputed from supporting rows and verified against recorded answers; all 2,000 pass the check.Source: A DATASET AND EVALUATION PROTOCOLS · pp. 12–13
  • Complete per-person records range from 3.4K to 815.0K tokens, with MIMIC-QA lengths measured on the pipeline’s deterministic rendering of structured rows.Token counts include record content supplied to the memory system, not prompt scaffolding; benchmark record-length statistics use the experimental subsets.Source: A DATASET AND EVALUATION PROTOCOLS · p. 13

A.1 EVALUATION SCORING

  • Scoring follows benchmark-specific protocols, and LLM-based evaluation uses the fixed gpt-5-2025-08-07 judge snapshot.Table 7 summarizes scoring by benchmark.Source: §A.1 · p. 13, Table 7 · p. 13

A.2 READER REPEATABILITY AND STATISTICAL CONTROLS

  • Reader repeatability is checked on byte-identical evidence packets, while paired tests use exact McNemar tests or paired-bootstrap intervals and sign-flip permutation tests as appropriate.MIMIC-QA repeat answering of identical packets spans 0.04 Token-F1 points; score differences are tested within the corresponding evaluation pass.Source: §A.2 · pp. 13–14

B IMPLEMENTATION DETAILS AND REPRODUCIBILITY

The appendix specifies model and baseline configurations, context and evidence protocols, write-module training, and diagnostic analyses of retrieval and serving.

B IMPLEMENTATION DETAILS AND REPRODUCIBILITY

  • The headline configurations distinguish the answering backbone from STAM’s local write modules, while baselines use specified implementations and adaptations.Ablation scores use separate paired evaluation passes and configuration-specific serving settings, so they should not be compared directly with Table 1.Source: B IMPLEMENTATION DETAILS AND… · p. 14

B.1 FULL-CONTEXT TRUNCATION

  • Full Context answers from the ordered raw record, truncating oldest entries when needed; truncation affected some MIMIC-QA and MedMemoryBench cases.MIMIC-QA truncation affected 179/400 questions under Qwen3-4B and 21/400 under GPT-5; retrieval counts do not imply matched context-token budgets.Source: §B.1 · p. 14, Table 8 · p. 15, Table 9 · p. 15

B.2 WRITE-MODULE FINE-TUNING

  • Separate LoRA adapters train the extractor, relation linker, and updater, with benchmark-specific data separation and five-fold evaluation for ClinicalBench.MIMIC-QA omits the extractor; ClinicalBench keeps training, validation, and evaluation patients disjoint within each fold.Source: §B.2 · p. 16, Table 10 · p. 16

C ADDITIONAL EXPERIMENTAL ANALYSIS

  • The additional analysis examines retrieval coverage, context budgets, and downstream answer quality under controlled serving configurations.The analyses include serving-budget diagnostics, which are not used as headline results.Source: C ADDITIONAL EXPERIMENTAL ANALYSIS · p. 16, §C.1.4 · p. 17

C.1.1 RETRIEVAL COVERAGE AND CONTEXT BUDGET

  • Retrieval coverage results describe the evaluated configurations, not matched-budget rankings, because methods supply different context amounts.The table’s recall uses dataset-specific gold annotations and is not comparable across datasets; ClinicalBench lacks evidence-level gold annotations.Source: §C.1.1 · p. 16, Table 11 · p. 17

C.1.2 EVIDENCE DEFINITIONS

  • Evidence coverage uses benchmark-specific gold definitions, and retrieval recall reflects both stored evidence coverage and read-time retrieval on MedMemoryBench.ClinicalBench has no evidence-level annotations and is excluded from retrieval-coverage analysis; the authors emphasize recall alongside served context size.Source: §C.1.2 · pp. 16–17, Table 11 · p. 17

C.1.3 EVIDENCE COVERAGE AND FULL-CONTEXT PERFORMANCE

  • MIMIC-QA selective serving achieved 0.959 gold-evidence recall and 87.22 Token-F1 versus 85.59 for raw Full Context (p = .18).MedMemoryBench had 0.802 downstream evidence recall; exposing more stored memory substantially improved answer quality.Source: §C.1.3 · p. 17

C.1.4 GPT-5 SERVING-BUDGET ANALYSIS

  • Serving all maintained memories raised MedMemoryBench macro accuracy from 52.90 to 63.84, versus 63.17 for raw Full Context.On MedLoCoMo, ranked serving improved type-macro F1 by 2.41 points at k = 240 and 3.87 points with 4,500 words; the latter scored 40.75 versus 42.53 for Full Context while serving about 5.6× less text.Source: §C.1.4 · pp. 17–18, Table 12 · p. 18

C.2 EVALUATION AT MATCHED CONTEXT LENGTHS

The section compares systems at approximately matched rendered-context lengths, then reports retrieval, serving-gate, and historical-memory diagnostics.

C.2 EVALUATION AT MATCHED CONTEXT LENGTHS

  • STAM had six significant improvements among 17 paired comparisons, with no significant decreases, including gains against MemRL on two benchmarks and four baselines on MIMIC-QA.Comparisons use approximately matched median rendered context; nonsignificance does not establish equivalence.Source: §C.2 · p. 18, Table 13 · p. 19
  • On ClinicalBench, STAM scored 50.0 accuracy at 890 median tokens versus 51.0 for Full Context at 15,619 tokens; removing retrieval reduced accuracy to 31.5.The comparisons with Flat RAG and the flat retrieval control were not statistically significant.Source: §C.2 · p. 18, Table 13 · p. 19
  • MedMemoryBench judge evaluations varied by approximately 1–2 macro-accuracy points, and expanded-context rows used one judge evaluation.The STAM result at the 1,312-token reference context was averaged over three fresh evaluations.Source: §C.2 · p. 19

C.3 RETRIEVAL DEPTH AND EVIDENCE RENDERING

  • MedMemoryBench retrieval recall rose from 0.709 at k = 30 to 0.849 at k = 240, while answer quality changed modestly and the k = 240 decrease was nonsignificant.At k = 60 and k = 120, answer-quality scores were 36.97 and 37.86; retrieval was rerun independently at each depth.Source: §C.3 · p. 19, Table 15 · p. 20
  • On MedLoCoMo, adding source spans to the same k = 60 memories kept recall at 0.822 and raised type-macro F1 from 34.93 to 36.13.At similar context cost, k = 120 raised recall to 0.863 but reached 34.69 F1.Source: §C.3 · p. 20, Table 15 · p. 20

D.1 PAIRED STORE-GATE EVALUATION

  • The store-gate analysis varies λ while holding the memory store, retrieval packets, and answering configuration fixed, reporting HISTORY skips and paired quality changes.The published gate selects between the original ACTIVE+HISTORY packet and that packet with HISTORY removed.Source: §D.1 · p. 20, Table 16 · p. 20

D.2 HISTORICAL-MEMORY DEPENDENCE

  • The refilled ACTIVE-only comparison tests whether historical evidence remains useful when ACTIVE-only serving receives comparable capacity.History-critical questions are correct with A+H but incorrect with refilled ACTIVE-only; History-harmful questions have the reverse outcomes.Source: §D.2 · p. 20, Table 17 · p. 21
  • History dependence varied by question type: GPT-5 showed pronounced dependence on HISTORY for MIMIC-QA temporal queries and MedMemoryBench temporal-localization and state-update questions.The corresponding rates were much smaller for the local system, and HISTORY’s value was concentrated in particular questions and query types.Source: §D.2 · pp. 20–21, Table 18 · p. 21

D.3 STORE-AWARE RETRIEVAL AND RENDERING CONTROLS

These controls test store-aware retrieval and rendering alongside write-time state maintenance and conservative deletion. They find no clear independent benefit from retrieval allocation or store labels, while temporal-state and deletion controls expose important limits on what should be archived or removed.

D.3 STORE-AWARE RETRIEVAL AND RENDERING CONTROLS

  • None of the isolated retrieval-allocation or store-label contrasts is statistically significant; the +2.15 Token-F1 difference is also nonsignificant (p = 0.08).Joint ranking on MIMIC-QA is numerically higher by 0.90 Token-F1 (p = 0.52), but that condition also changes evidence rendering.Source: §D.3 · p. 21, Table 20 · p. 22, Table 19 · p. 22

E WRITE-TIME STATE-MAINTENANCE DIAGNOSTICS

  • The write-time ablations assess supersession-pair recall and false archival on MedMemoryBench, and archival, gold-evidence placement, and Token-F1 on MIMIC-QA.These diagnostics characterize state organization and downstream answering; evidence placement and answer-level dependence on HISTORY are evaluated separately.Source: E WRITE-TIME STATE-MAINTENANCE… · p. 22, §E.1 · p. 22

E.2 ADDITIONAL WRITE-PATH CONTROLS

  • The deterministic rule limited to measurements and doses archives 6.8% of memories and reaches 16.4% supersession-pair recall.The semantic-only B = 24 control changes both channel availability and candidate budget, so it is not the controlled graph-channel comparison.Source: §E.2 · p. 22, Table 21 · p. 23

F.1 ENDURANCE LABELS

  • Deletion labels distinguish safe-to-forget, never-forget, and uncertain memories; the rule protects both never-forget and uncertain classes.This defines which memories are eligible for removal, not merely whether they are currently historical.Source: §F.1 · p. 22

F.2 DELETION SCORER AND OPERATING POINT

  • At τ = 0.988, the gate removes 2.3% of the deployment store with 16.1% safe-to-forget recall, 92.9% safe precision, and 0.3% never-forget loss.The strict criterion controls marginal expected deletion loss over concept types at α = 0.01 under exchangeability with the calibration distribution, not per-memory clinical risk or medical safety.Source: §F.2 · p. 23, §F.3 · p. 23

F.4 WHY THE STRICT LOSS IS NECESSARY

  • The never-forget-only diagnostic deletes 23.4% of never-forget memories, while its deployment operating point has 8.1% never-forget loss.The comparison illustrates why the protected class in calibration must match the operational deletion rule: a marginal bound can be weak when a safety-critical class is rare.Source: §F.4 · pp. 23–24, Table 22 · p. 24

F.5 DELETION CANDIDATE AND SAFETY ABLATIONS

  • The temporal-status heuristic removes 26.4% of the store and captures 83.4% of safe-to-forget memories, but its safe precision is 42.3% and it removes 264 never-forget memories.Temporal status alone does not establish removability under the endurance-labeling scheme.Source: §F.5 · p. 24

F.6 QUALITATIVE EXAMPLES AND THRESHOLD LIMITATIONS

The deletion examples show that transient descriptions can be removed while clinically useful longitudinal baselines may remain difficult to classify. The accompanying evaluations report paired deletion outcomes and characterize how selective HISTORY serving affects reader cost, subject to the stated measurement scope.

F.6 QUALITATIVE EXAMPLES AND THRESHOLD LIMITATIONS

  • Removed examples include temporary humidifier settings and short-lived symptoms, while retained examples include ongoing medication use and longitudinal monitoring states.Fasting C-peptide, six-minute walk distance, CPAP settings, and prior shortness-of-breath reports are protected examples near the deletion threshold.Source: §F.6 · p. 24

F.7 END-TO-END EFFECT OF DELETION

  • Across 496 questions, 20 answers improve and 14 regress after deletion (exact McNemar p = 0.39), with no clear aggregate loss in downstream answer quality.The authors do not interpret the nominal increase after deletion as an improvement; 287 answers are byte-identical.Source: §F.7 · p. 25, Table 24 · p. 25

G.1 MEASUREMENT PROTOCOL AND SCOPE

  • The latency measurements use sequential batch-one requests on one A100 with prefix caching disabled, and exclude memory construction, retrieval, and gate evaluation.Controlled wall-clock comparisons against other memory systems are not reported because baseline runtimes use different hosts and serving configurations.Source: §G.1 · p. 25

G.2 SERVING-ARM LATENCY

  • MedMemoryBench ACTIVE-only serving reduces mean prompt length from 4,482 to 1,876 tokens and mean TTFT from 228.7 to 97.3 ms.On MedLoCoMo, prompt length changes from 1,680 to 1,478 tokens, with a correspondingly smaller latency difference.Source: §G.2 · p. 26, Table 25 · p. 26

G.3 POLICY-LEVEL TTFT SAVINGS

  • Selective HISTORY serving yields larger TTFT benefits when the gate chooses ACTIVE-only and HISTORY accounts for a large share of the prompt.The benefit is smaller when the two serving arms have similar context lengths.Source: §G.3 · p. 26

G.4 DECODE AND END-TO-END BEHAVIOR

  • Decode throughput remains approximately 120–150 tokens/s under both serving actions, so store selection’s direct computational benefit is primarily a prefill effect.ClinicalBench’s shorter completion (189.5 to 146.5 tokens) means its shorter decode time is not interpreted as a pure serving-efficiency gain.Source: §G.4 · p. 26

G.5 READER FLOP ACCOUNTING

  • On MedMemoryBench, ACTIVE-only uses 58.2% fewer prompt tokens than BOTH and has 61.9% lower estimated prefill computation.The FLOP reduction exceeds the token reduction because shorter prompts also reduce attention computation.Source: §G.5 · p. 27, Table 27 · p. 27

G.6 KV-CACHE CAPACITY AND OCCUPANCY

  • Across 40 requests, measured-to-expected KV-cache occupancy has median 1.0019 and range 0.9976–1.0100.Prompt-only capacity estimates exclude generated tokens and block rounding, so they are capacity estimates rather than throughput measurements.Source: §G.6 · p. 27, Table 28 · p. 27

G.7 WRITE-TIME CONSTRUCTION COST

Write-time construction cost varies substantially across benchmarks and is not proportional to raw record length. On the published MedMemoryBench stores, relation linking accounts for the largest reported share of model compute.

G.7 WRITE-TIME CONSTRUCTION COST

  • MedMemoryBench records exceeding 600K source tokens take 0.69–0.81 seconds per 1K tokens to process, versus 16.0–29.1 seconds per 1K tokens on ClinicalBench.The difference reflects the number and structure of write-time model operations induced by a record, rather than source-token volume alone.Source: §G.7 · p. 28, Table 29 · p. 28
  • On the published MedMemoryBench stores, atomic extraction, state updating, and relation linking require 37.75, 4.21, and 50.04 PFLOP, respectively, totaling 92.00 PFLOP.These are one-time memory-construction costs; practical amortization depends on update frequency and subsequent queries served.Source: §G.7 · p. 28, Table 29 · p. 28

Related papers

Loading 2609.38490v1…