Write–Manage–Read Loop

• The Write–Manage–Read loop is a design pattern where new state is written, then managed through controlled transformations, and finally read efficiently.
• It spans diverse applications—from FeRh magnetic memory and search engine indexing to LLM memory systems—highlighting its versatility.
• The management phase is crucial, mediating between raw writes and reliable reads by addressing issues like write amplification, state reset, or data migration.

The Write–Manage–Read loop is a recurrent systems pattern in which new state is first written, then stabilized, reorganized, or migrated by an intermediate management phase, and finally exposed to a read mechanism. In the cited literature, this pattern appears in materially different substrates: B2-ordered FeRh antiferromagnetic memory uses Joule heating and field cooling to set a Néel vector before anisotropic-magnetoresistance readout; large-scale search engines interpose merges, compactions, and index-structure builds between ingest and query serving; explicit-memory LLMs insert and retrieve relational triples; a 3T-1R MRAM true random number generator couples analog write, reset, and digital read within a single period; and Application Read-Only Memory shifts Long-term RAM management into the operating system through copy-on-write migration (Moriyama et al., 2015, Liang et al., 2 May 2026, Modarressi et al., 2024, Modarressi et al., 2023, Egler et al., 2022, Shim et al., 18 Jun 2026). This suggests a cross-domain abstraction in which the central design problem is not merely storing information, but controlling the intermediate transformations that make stored state reliable, queryable, or physically realizable.

1. Phase structure and formalization

In the search-engine formulation, the loop is explicitly decomposed into writes, management tasks, and reads. Documents are first placed into an in-memory buffer of capacity $M$ and flushed as immutable segments of size $S_0 \approx M \cdot s_p$; management then performs merges whose total work over $N$ documents is $W_m = O(N \cdot s_p \cdot \log(N/M))$ with write amplification $WAF \approx L$, where $L = \lceil \log_2(N/M) \rceil$; the read phase intersects postings from up to $O(L)$ active segments, with $$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$ (Liang et al., 2 May 2026). That formulation makes the intermediate phase explicit: management is the mechanism that bounds downstream read cost, but it is also the source of contention.

The broader record shows that the same three-part decomposition persists even when the management stage is not a merge. In the MemLLM-style MAuLLM description, writes add triples to an external memory, but the management phase does not rewrite stored triples; instead it removes a read call from prompt context when the retrieved set is empty, when $|\mathcal E| > Q_{\mathrm{thr}} = 30$, or when a new MEM_READ begins (Modarressi et al., 2024). In RET-LLM, management is defined by append or overwrite policy plus index maintenance over three LSH tables (Modarressi et al., 2023). In AROM, management is page migration, write protection, dirty-bit scanning, and token-bucket wear leveling rather than direct data-structure optimization (Shim et al., 18 Jun 2026). In FeRh memory, management is thermal stabilization of the Néel vector after the write pulse (Moriyama et al., 2015). In the 3T-1R MRAM TRNG, management is a deterministic reset that restores the device to anti-parallel state before the next stochastic write (Egler et al., 2022).

Domain	Write	Manage	Read
FeRh antiferromagnetic memory	Joule-heating AF$\rightarrow$F transition with field cooling	Thermal lock-in of the AF state	AF-AMR measurement
Search engines	Index updates and segment flushes	Merges, compactions, index-structure builds	Query processing over active structures
Explicit-memory LLMs	Triple extraction and insertion into external memory	Prompt pruning, overwrite/append policy, index maintenance	Memory retrieval and continuation
3T-1R MRAM TRNG	Analog STT pulse	Deterministic reset to AP	Comparator and DFF readout
AROM	Application store triggers CoW migration path	Page scanning, remapping, wear pacing	DRAM or LtRAM load

A common misconception is that “management” must denote a persistent rewrite of the same state representation. The cited systems show otherwise. Management may instead be thermal relaxation, prompt-context pruning, reset-to-known-state, or OS-level remapping. What is invariant is the insertion of an intermediate control phase between production of state and its subsequent observation.

2. Physical realizations in magnetic devices

In B2-ordered FeRh, the write phase exploits the antiferromagnetic-ferromagnetic phase transition near room temperature. The staggered moment is defined as $S_0 \approx M \cdot s_p$0, and a minimal phenomenological free energy is written as

$S_0 \approx M \cdot s_p$1

with $S_0 \approx M \cdot s_p$2 as the bulk AF–F transition temperature. A current pulse $S_0 \approx M \cdot s_p$3 raises the temperature by

$S_0 \approx M \cdot s_p$4

and in the reported $S_0 \approx M \cdot s_p$5 wire the AF$S_0 \approx M \cdot s_p$6F transition begins at $S_0 \approx M \cdot s_p$7 and is complete by $S_0 \approx M \cdot s_p$8, corresponding to $S_0 \approx M \cdot s_p$9. While the wire is in the ferromagnetic phase, a $N$0 in-plane field $N$1 sets the moment direction; the current is then reduced to $N$2, and cooling below $N$3 freezes an AF state with $N$4 (Moriyama et al., 2015).

The management phase in FeRh is thermal and anisotropy-governed rather than algorithmic. The barrier is approximated by $N$5, with relaxation time

$N$6

The supplied description states that even with modest $N$7, $N$8 reaches days to years, and that the written Néel order is unchanged by in-plane disturbing fields $N$9. The read phase uses antiferromagnetic AMR,

$W_m = O(N \cdot s_p \cdot \log(N/M))$0

implemented as a crossed-wire ratiometric measurement of $W_m = O(N \cdot s_p \cdot \log(N/M))$1. The total $W_m = O(N \cdot s_p \cdot \log(N/M))$2 between the “parallel” and “perpendicular” AF states is $W_m = O(N \cdot s_p \cdot \log(N/M))$3, the AF-AMR after subtracting residual ferromagnetic background is approximately $W_m = O(N \cdot s_p \cdot \log(N/M))$4, and the single-read accuracy is better than $W_m = O(N \cdot s_p \cdot \log(N/M))$5. The proof-of-concept demonstrates more than $W_m = O(N \cdot s_p \cdot \log(N/M))$6 sequential write-read cycles with no degradation of contrast. Heating and cooling in the present experiment take order $W_m = O(N \cdot s_p \cdot \log(N/M))$7 for full thermal stability, while the device physics is stated to allow sub-nanosecond pulses with optimized thermal design (Moriyama et al., 2015).

The 3T-1R analog-write/digital-read MRAM TRNG instantiates a different physical loop. A single period $W_m = O(N \cdot s_p \cdot \log(N/M))$8 contains a stochastic analog write of duration $W_m = O(N \cdot s_p \cdot \log(N/M))$9–$WAF \approx L$0, a deterministic reset of duration $WAF \approx L$1–$WAF \approx L$2, and a digital read of duration $WAF \approx L$3, for a total period of approximately $WAF \approx L$4 and a bit rate of about $WAF \approx L$5. The write uses $WAF \approx L$6, $WAF \approx L$7, and $WAF \approx L$8 to set a switching probability near $WAF \approx L$9; reset applies reverse polarity with high reliability; read senses the mid-node voltage

$L = \lceil \log_2(N/M) \rceil$0

under $L = \lceil \log_2(N/M) \rceil$1 and compares it to $L = \lceil \log_2(N/M) \rceil$2. The reported energy is approximately $L = \lceil \log_2(N/M) \rceil$3, the entropy is approximately $L = \lceil \log_2(N/M) \rceil$4, and the output passes NIST STS with no post-processing (Egler et al., 2022).

Taken together, these two magnetic implementations illustrate opposite roles for the management phase. In FeRh, management preserves a written state; in the MRAM TRNG, management intentionally erases it by resetting to a known starting point for the next cycle.

3. Operating-system enforcement in Application Read-Only Memory

AROM defines a Write–Manage–Read loop for Long-term RAM in which LtRAM pages are read-only to applications and written only by the operating system during page migrations. The mechanism is PTE-level write protection enforced by copy-on-write. When an application store targets a virtual address mapped to an LtRAM page with its write bit cleared, the MMU raises a protection fault; the kernel allocates a fresh DRAM page, copies $L = \lceil \log_2(N/M) \rceil$5 from the old LtRAM page to DRAM, updates the PTE to point to the DRAM page with PROT_READ|WRITE, flushes the TLB entry, frees the old LtRAM page back to the LtRAM zone’s free list, schedules a $L = \lceil \log_2(N/M) \rceil$6 erase during idle, returns from the fault, and allows the CPU to re-execute the store into DRAM (Shim et al., 18 Jun 2026).

The management phase is carried largely by the kernel. A background migrator scans DRAM PTEs every interval $L = \lceil \log_2(N/M) \rceil$7; if a page’s dirty bit remains clear for the entire scan window, it becomes a candidate for migration back to LtRAM. For each candidate, the token-bucket wear leveler grants permission, then the kernel allocates a fresh LtRAM page, erases its block if needed, copies $L = \lceil \log_2(N/M) \rceil$8 from DRAM to LtRAM, updates the PTE to the LtRAM PFN with its write bit cleared, flushes the TLB, and frees the DRAM page. The DIMM-side controller is deliberately thin: read granularity is $L = \lceil \log_2(N/M) \rceil$9, write granularity is $O(L)$0, per-block health metadata is exposed, and there is no on-DIMM AIT, no read-modify-write merge logic, and no opaque wear-level migrations (Shim et al., 18 Jun 2026).

The cost model centers on the probability

$O(L)$1

with average access time

$O(L)$2

The supplied description sets post-migration DRAM reads at approximately $O(L)$3, projects AROM LtRAM reads at approximately $O(L)$4–$O(L)$5, and contrasts this with Optane-style reads at approximately $O(L)$6–$O(L)$7, identifying $O(L)$8 plus removal of RMW and tail latencies. In a read-mostly tier, where $O(L)$9, the text states that $$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$0 can be driven to $$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$1 or smaller (Shim et al., 18 Jun 2026).

AROM is significant because it redefines the management stage as an OS responsibility rather than a hidden controller function. The loop therefore becomes both a memory-management policy and an interface contract: application writes are redirected into migration, while application reads are allowed to observe either DRAM-resident or LtRAM-resident data under a read-only invariant.

4. Decoupling in large-scale search engines

In large-scale search engines, the Write–Manage–Read loop is presented as the central source of write-read contention: writes inject documents or updates, management performs segment merges, compactions, or structure builds, and reads traverse the current index structures to answer queries. In the dominant Lucene-derived model, those phases share CPU, memory, and I/O bandwidth, so management work inflates query latency and P99 variability. The survey identifies five principal decoupling patterns: node-level read-write separation, compute-storage separation, full in-memory indexing, log-structured write paths, and in-place partial updates (Liang et al., 2 May 2026).

Node-level separation moves indexing and merges to write nodes while search nodes load immutable snapshots; LinkedIn Galene is reported to achieve stable latency with freshness around $$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$2–$$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$3 minutes. Compute-storage separation places authoritative segments in shared object storage; Quickwit uses immutable $$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$4–$$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$5 splits in S3, while Elasticsearch Serverless is described as using S3, multi-tiered caching, and batch-commit I/O reduction of $$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$6. Full in-memory indexing eliminates disk and page-cache interference at the expense of memory overhead $$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$7–$$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$8 raw data size; Algolia reports $$\mathrm{CPU}_{\mathrm{read}} \approx O(P_q + L \cdot C_{\mathrm{seek}})$$9, and Ximalaya is reported to reduce average query latency from $|\mathcal E| > Q_{\mathrm{thr}} = 30$0 to $|\mathcal E| > Q_{\mathrm{thr}} = 30$1. Log-structured paths append updates to Kafka or Pulsar and build optimized structures asynchronously; Milvus exposes growing segments searchable in under $|\mathcal E| > Q_{\mathrm{thr}} = 30$2. In-place partial updates store scalar attributes in forward arrays with $|\mathcal E| > Q_{\mathrm{thr}} = 30$3 in-RAM writes and immediate visibility; Vespa Proton is the cited exemplar (Liang et al., 2 May 2026).

System	Pattern	Freshness / latency / WAF
ES (shared-nothing)	Coupled	1 s, variable spikes, 10–30×
LinkedIn Galene	Node separation	minutes, stable \<50 ms, 10–30×
Quickwit	Compute-storage separation	minutes–hrs, 60–200 ms, 0
Algolia	In-memory	≈1 s, \<10 ms, 0
Milvus	Log-structured	\<1 s (growing), \<50 ms, 0
Vespa	In-place updates	instant(attr.), \<5 ms, 0 (attr)

The survey’s unifying synthesis is ScaleSearch. It combines compute-storage separation with full in-memory search and dedicated write nodes, and adds per-field update routing through Kafka topics. For scalar fields in CF-realtime, each field $|\mathcal E| > Q_{\mathrm{thr}} = 30$4 receives its own topic $|\mathcal E| > Q_{\mathrm{thr}} = 30$5, and search nodes perform in-place updates update_array[fieldID] [docID] ← new_value in $|\mathcal E| > Q_{\mathrm{thr}} = 30$6 CPU and $|\mathcal E| > Q_{\mathrm{thr}} = 30$7 memory per field, with immediate visibility and no merge. For CF-text, write nodes build immutable segments, upload them to S3, and search nodes poll, download, and merge them in RAM with $|\mathcal E| > Q_{\mathrm{thr}} = 30$8 and freshness approximated by upload latency plus poll interval, for example under $|\mathcal E| > Q_{\mathrm{thr}} = 30$9 (Liang et al., 2 May 2026).

The search-engine case gives the most explicit statement of why the intermediate phase matters. Management is both necessary and dangerous: without it, read cost grows; with it, contention grows unless the architecture isolates or reshapes the loop.

5. Explicit read-write memory for LLMs

RET-LLM and MemLLM-style MAuLLM instantiate the loop as an explicit memory interface around an LLM rather than as a latent parameter update. RET-LLM stores knowledge in triplets $\rightarrow$0 inspired by Davidsonian semantics, with $\rightarrow$1 as subject, $\rightarrow$2 as predicate, and $\rightarrow$3 as object. Each element is embedded as a mean hidden representation,

$\rightarrow$4

and inserted into a memory table together with metadata, while each slot representation is added to a locality-sensitive hashing index. Read queries specify one or more filled slots of $\rightarrow$5; retrieval first attempts exact matching, then falls back to fuzzy match via LSH if needed, and ranks candidates by

$\rightarrow$6

The joint training objective is

$\rightarrow$7

The design is explicitly described as scalable, aggregatable, updatable, and interpretable, with update policy implemented either as latest-wins overwrite or append (Modarressi et al., 2023).

The supplied MemLLM description presents a MemLLM-style system denoted MAuLLM. Its memory $\rightarrow$8 is a set of relational triples $\rightarrow$9 stored in entity and relation tables with fixed-dimensional embeddings produced by Contriever, and indexed by HNSW over all entity and relation embeddings. During the write phase, the model is fine-tuned so that an input sentence is converted into a token sequence of the form ({MEM_WRITE–> ... }), with

$S_0 \approx M \cdot s_p$00

At inference time, a late-stopping hack suppresses premature emission of the closing token )} until it reappears with high log-probability or patience $S_0 \approx M \cdot s_p$01 is exhausted. During reading, the model may emit ({MEM_READ( and generate queries of the form $S_0 \approx M \cdot s_p$02 or $S_0 \approx M \cdot s_p$03; the memory module forms candidate sets by cosine thresholding on entities and relations and returns all matching entities satisfying the specified average similarity criterion, after which the LLM continues generation with the retrieved entities literally present in context (Modarressi et al., 2024).

MAuLLM’s management phase is narrow but explicit: after each MEM_READ, the call is removed from prompt context if the retrieved set is empty, if the result size exceeds $S_0 \approx M \cdot s_p$04, or if a new MEM_READ starts. Training on DOCRED is divided into a memory-write pass and a memory-read pass. On the DOCRED validation set, the memory-enabled model reports OVERALL PPL 1.606 versus 1.774 for base Mistral-7B, TARGET-ENTITY PPL 1.009 versus 1.180, and ALL-ENTITY PPL 1.322 versus 1.420, described as approximately $S_0 \approx M \cdot s_p$05 lower perplexity on newly introduced entities. An ablation with gold read positions and gold queries reduces target perplexity to 0.337, and the description identifies the read phase as the main bottleneck (Modarressi et al., 2024).

These systems are significant because they externalize state that would otherwise remain implicit in parameters. The loop is therefore not merely a retrieval interface; it is a training-time and inference-time protocol for deciding when the model should write structured knowledge, how that knowledge should be indexed or pruned, and when it should be reintroduced into the context window.

6. Recurring design principles, asymmetries, and open problems

Across the cited systems, the write and read phases are rarely symmetric. Search engines show that writes can incur $S_0 \approx M \cdot s_p$06 amortized management work while queries are sensitive to segment proliferation and P99 interference (Liang et al., 2 May 2026). FeRh memory requires a threshold current density of approximately $S_0 \approx M \cdot s_p$07 to rewrite a state whose electrical read contrast is only $S_0 \approx M \cdot s_p$08 before background subtraction (Moriyama et al., 2015). In AROM, writes to LtRAM are not writes in the ordinary sense at all; they are traps into migration, after which the actual store lands in DRAM (Shim et al., 18 Jun 2026). In MemLLM-style MAuLLM, imperfect retrieval rather than memory storage capacity is identified as the main bottleneck, since gold-position and gold-query ablations sharply reduce target perplexity (Modarressi et al., 2024). This suggests that the decisive engineering difficulty often lies in the management and mediation layer rather than in raw storage or raw readout.

The literature also corrects a second misconception: the management phase is not merely overhead. In the search-engine setting, it controls write amplification, freshness, and query fan-out; in FeRh it provides stability against thermal reversal and disturbing fields; in MRAM TRNG it restores statistical independence between cycles through deterministic reset; in AROM it enforces the invariant that applications never write LtRAM directly; and in LLM memory systems it keeps retrieved context or indexed knowledge within operational limits (Liang et al., 2 May 2026, Moriyama et al., 2015, Egler et al., 2022, Shim et al., 18 Jun 2026, Modarressi et al., 2023).

Open directions are stated most explicitly for search. The survey highlights hybrid vector-and-full-text retrieval, serverless and edge deployments, and AI-integrated search as the next frontier, with vector-index rebuilds and cold-start fetches introducing new management pressure (Liang et al., 2 May 2026). A plausible implication is that the Write–Manage–Read loop will remain useful as a unifying systems vocabulary precisely because it isolates the intermediate control problem. Whether the substrate is a magnetic order parameter, a segment hierarchy, an external triple store, or an LtRAM page map, the operative question is how a written state is transformed into a state that can be read repeatedly, efficiently, and under bounded interference.