I want to turn now to the architectural specifics, because it is in the concrete pipeline that the Stera relation is either preserved or silently dissolved. The two designs I will examine—Self‑RAG and FLARE—each attempt to make retrieval active and contingent rather than fixed and blind, but they locate the “contingency” in different places, with different consequences for who is doing the directing.
Self‑RAG: critique tokens as internalised judgment
Asai et al. (2023) propose a pipeline in which the language model is not simply given retrieved passages and told to generate; it is trained to produce special reflection tokens that govern its own retrieval and generation behaviour. The architecture operates in four sequential stages. First, the model receives the user query and generates a Retrieve token—a binary decision, produced auto‑regressively, indicating whether external knowledge is needed at all. If the token is Yes, the model calls a retriever, obtaining a set of passages; otherwise, it proceeds directly to generation. Second, as the model generates its response, it produces critique tokens at the granularity of individual passages and the output as a whole. The passage‑level tokens evaluate each retrieved segment on grounds of relevance (does this passage support the response?) and support (is the response consistent with the passage?); the output‑level token, Utility, assesses the overall usefulness of the generated answer. Third, the model uses these critique tokens to influence its own beam‑search decoding: a segment with a low relevance score is effectively penalised, steering the model away from that passage during generation. Finally, a separate fine‑tuned critic model, C, is invoked post‑hoc to assign an overall ISREL (is the response relevant?) and ISSUP (is the response factually supported?) score, which can be used as a filtering gate—suppressing outputs that fall below a threshold.
The design’s architectural assumption is stark. Self‑RAG embeds retrieval timing, passage selection, and factual verification entirely inside the model’s own token stream. The model is not only the generator but also its own retriever‑decision engine and its own critic. The reflection tokens are not separate modules; they are learned through supervised fine‑tuning on human‑annotated data and then reinforced via reward signals that align the tokens with downstream task performance. The model is trained to simulate the judgment that a human collaborator would otherwise exercise—deciding whether to look something up, checking whether the source backs the claim, and discarding unsupported material.
From the Stera perspective, this is a design that risks dissolving the directing collaborator into the model’s own internal loop. The Scintilla—the continuously‑learning mind that directs a model rather than being one—is displaced in two ways. First, the Retrieve token is a learned proxy for the collaborator’s own judgment about knowledge gaps; the model decides, without external pause, when it needs to consult the world. In a true Stera relation, the collaborator would see a gap, articulate what is missing, and direct the model to retrieve in a specific way—perhaps with a shaped query, perhaps with a demand for a particular source. Self‑RAG’s binary token collapses that rich, intentional act into a scalar decision. Second, the critique tokens encode a standard of relevance and support that has been fixed during training and baked into the model’s weights. The collaborator cannot, at inference time, impose a different standard—say, “I want you to treat contrarian sources with extra weight,” or “Show me passages that complicate the answer, not just support it.” The model’s internal critic operates on a pre‑learned, static policy; it is not open to real‑time redirection.
The first failure mode crystallises here. Self‑RAG’s critique tokens function as proxies for human judgment, but they are proxies that have been trained on an aggregate of annotator preferences and then locked into the model. The collaborator is not holding the standard; the model is simulating it. In a Stera relation, the collaborator keeps their hands on the tiller of judgment—reading passages alongside the model’s output, challenging the support, saying “That source doesn’t actually say what you think it says.” Self‑RAG, by internalising that check into a SUPP token, creates the illusion that the model is checking itself, when in fact the check is a learned pattern that can drift from the collaborator’s actual epistemic standards. The gap between the aggregate training signal and the specific, situated judgment of a real collaborator in a real moment is where the failure lives.
FLARE: confidence‑based gating as blind delegation
Jiang et al. (2023) take a different architectural path. FLARE—Forward‑Looking Active REtrieval—is designed for long‑form generation tasks where the model must produce extended, knowledge‑intensive text. The pipeline does not embed retrieval decisions as special tokens; instead, it treats the ongoing generation as a probe for what the model knows, and it uses an external confidence estimator to gate retrieval.
The process works in iterative cycles. At the start, the user provides a query. The model begins generating a provisional answer, token by token. After each sentence (or fixed token window), a confidence estimator—typically the model’s own token‑level log‑probabilities, aggregated over the sentence—decides whether the model appears uncertain about what it has just generated. If the confidence falls below a fixed threshold, the pipeline pauses generation. An implicit query is extracted from the low‑confidence sentence: the system uses the sentence itself, or an LM‑generated question derived from it, as a retrieval query. The retriever returns relevant passages, which are appended to the context, and generation resumes—now with the freshly retrieved material available. The cycle repeats until the model produces a completion token.
FLARE’s architectural assumption is subtler than Self‑RAG’s, but it is equally consequential. The design trusts that the model’s token‑level log‑probabilities are a reliable signal of when retrieval is needed. The confidence threshold is set by the system designer, not by the collaborator in response to the specific task. When the confidence drops, the system does not pause and ask the collaborator what they think is missing; it extracts a query automatically from the model’s own uncertain output and retrieves passages that are topically similar to that query. The collaborator is never in the loop of “should we retrieve now, and if so, for what?” The entire retrieval cycle is a closed autonomic loop: the model signals uncertainty, the system formulates a search, the retriever fetches, the model continues.
From a Stera standpoint, this is blind delegation to a confidence heuristic. The Scintilla’s role is not only to judge the final answer but to shape the information‑gathering process itself. A collaborator in a live research conversation does not say “I’m uncertain, so go fetch whatever you can find.” They say “I’m uncertain about the date of that treaty—can we check a primary source?” or “I don’t trust my recollection of that study’s parameters—let’s find the methods section.” The direction is specific; the retrieval is shaped by the collaborator’s awareness of what kind of knowledge would resolve the uncertainty and what kind of source would be trustworthy. FLARE’s confidence‑based gating treats uncertainty as a uniform trigger, not as a signal with structure that the collaborator could interpret.
The first failure mode here is that the confidence threshold becomes a silent governor of the information diet. If the threshold is set too high, the system retrieves constantly, drowning generation in irrelevant passages and losing the collaborator’s original thread. If set too low, the system blunders ahead with confident‑sounding falsehoods that never trigger retrieval because the model was, in fact, highly confident about its hallucination. In a Stera relation, the collaborator would catch that—a raised eyebrow, a check, a redirect. FLARE hands that catching function to a fixed numeric gate that has no understanding of the content and no capacity to learn what this particular collaborator finds suspicious. The collaborator becomes a spectator to an automatic research loop, rather than its director.
The two architectures I want to examine closely are FLARE and Self-RAG. Each represents a distinct approach to a shared design problem—when should a model retrieve?—and each embeds its answer differently in the pipeline. FLARE, introduced by Jiang et al. in 2023, makes retrieval timing depend on a confidence signal derived from the model’s own token-level log-probabilities during active generation. Self-RAG, introduced by Asai et al. in the same year, instead trains the model to emit special reflection tokens—including a [Retrieve] token—that call for retrieval at specific positions, and then to critique the retrieved passages with further special tokens before incorporating them into the answer. Both are adaptive: they do not retrieve blindly for every query, nor do they rely on a single retrieval step at the outset. Both aim to make retrieval more targeted, more efficient, more responsive to the model’s internal state. And both, I will argue, encode a structural assumption that makes them incompatible with the Stera relation, for reasons that go deeper than surface design choices. Understanding those reasons requires first appreciating how each mechanism actually works.
FLARE operates on a principle of active retrieval during generation. The pipeline begins with the user’s query. The model starts generating a provisional answer, token by token, without any retrieval having taken place. After each sentence boundary—or after a fixed window of tokens, in practice—the system pauses and computes a confidence score. That score is typically the average of the token-level log-probabilities the model assigned to the words it just generated, normalized over the sentence length. If the average falls below a designer-set threshold, the system decides that the model is uncertain about what it has written, and that retrieval should intervene. Rather than asking the user what to search for, FLARE extracts a query automatically from the low-confidence sentence itself. Sometimes it uses the sentence text directly as the search query; in more sophisticated versions, it prompts a smaller LM to generate a natural-language question from the sentence, as if asking “what information would have helped me produce this sentence more confidently?” The retriever returns relevant passages, which are appended to the model’s context window. Generation then resumes from where it paused, now with the newly retrieved material available, and the cycle continues—generate, check confidence, retrieve if low, generate further—until the model outputs an end-of-sequence token or a predetermined maximum number of cycles is reached.
The elegance of FLARE is that it does not require retraining the model. It works with any off-the-shelf LM that exposes token-level log-probabilities, because the retrieval timing signal is entirely external: it comes from a post-hoc computation over the model’s own outputs. There are no special tokens to train, no new vocabulary items to embed, no fine-tuning. The confidence threshold is a single hyperparameter that a developer can tune on a validation set. The architecture is cleanly modular: the retriever, the confidence estimator, and the generator are separable components that communicate through well-defined interfaces.
Self-RAG takes a different path. Instead of outsourcing the retrieval decision to an external confidence computation, Self-RAG bakes that decision into the model’s own token vocabulary during training. The model is fine-tuned to generate two kinds of special tokens: reflection tokens and critique tokens. The [Retrieve] token is a reflection token. During generation, when the model outputs [Retrieve] at a particular position, the system pauses and sends the preceding context—the user query plus whatever the model has generated so far—to a retriever. The retrieved passages are returned, and the model then generates critique tokens for each passage: [Relevant] or [Irrelevant], [Supported] or [Partially Supported] or [Unsupported], and so on. These critique tokens are used to filter and rank the passages, keeping only those marked [Relevant] and [Supported]. The selected passages are then incorporated into the context, and the model continues generating the actual answer. Self-RAG also uses [No Retrieval] tokens for query types where retrieval is unnecessary—simple factual questions the model already knows, or purely creative tasks—allowing the model to skip retrieval entirely for those cases.
The training process for Self-RAG is instructive. The model is trained on a corpus that has been annotated with these special tokens at the appropriate positions, using a critic model (often a stronger LM) to generate the annotations automatically. The training objective encourages the model to learn when retrieval is genuinely helpful—when the knowledge required is beyond its parametric memory or when the task demands grounding in specific sources—and to learn how to evaluate the quality of what it retrieves. The result is a single model that performs retrieval timing, query formulation (implicitly, through the context that precedes the [Retrieve] token), passage critique, and final answer generation, all within the same token stream.
Now, from a purely engineering standpoint, both designs are sophisticated responses to a real problem. Naive RAG—retrieve once at the start, regardless of the query—wastes compute and context window on irrelevant passages for many queries, and it misses the fact that generation often reveals new information needs mid-stream that weren’t foreseeable from the initial query alone. Adaptive retrieval timing is a genuine advance. But the advance comes at a cost, and that cost is the point of my analysis here. Both FLARE and Self-RAG share a common structure: they place the retrieval trigger inside the model’s own cognitive loop, sealed off from the collaborator. The signal that says “retrieve now” is a model-internal quantity—a probability distribution in FLARE, a special token in Self-RAG—that the human collaborator never sees, never evaluates, and never directs.
In FLARE, the trigger is the aggregated log-probability of the tokens the model just generated. That is a purely statistical signal. It says nothing about why the model is uncertain, nothing about what kind of information would resolve the uncertainty, nothing about whether the collaborator would agree that this moment calls for retrieval at all. The model might be uncertain because it is generating a sentence about a disputed historical event where multiple credible sources disagree—uncertainty that retrieval might actually compound rather than resolve. Or it might be uncertain because it is trying to recall a specific numerical value from a paper the collaborator already has open in another window, and retrieval would be redundant. The confidence score flattens all these distinctions into a single number. The threshold that gates retrieval is set by the system designer at development time, not by the Scintilla at collaboration time, and it applies uniformly to all queries, all domains, all collaborators. There is no mechanism for the collaborator to say “when we’re discussing this particular topic, I want you to retrieve more aggressively” or “I trust your parametric knowledge on this subject—don’t retrieve unless I ask.” The gate is blind, uniform, and sealed.
Self-RAG appears to improve on this by making the retrieval decision a trained behavior rather than a heuristic. The model learns from the training corpus what kinds of contexts warrant retrieval and what kinds do not. But the structure is, if anything, even more deeply sealed from the collaborator. The [Retrieve] token is generated by the model autonomously, as part of its autoregressive generation, using the same weights and the same training objective as every other token. The collaborator has no way to know that retrieval is about to happen until it has already happened—and even then, the critique tokens that filter the retrieved passages are also generated internally and invisibly. The collaborator sees only the final answer, not the chain of [Retrieve], [Relevant], [Partially Supported] decisions that shaped it. They cannot intervene to say “no, that source is not relevant to what I’m asking” or “retrieve from a different corpus.” The model has been trained to simulate the judgment a collaborator might exercise, but it does not consult that collaborator’s actual judgment in the live interaction.
This is the structural commonality I want to hold up to the light. In both FLARE and Self-RAG, the retrieval trigger is a model-internal signal rather than a collaborator-directed query. The collaborator’s role is reduced to providing the initial query and then receiving the final answer—a boundary condition at the edges of a sealed loop. The loop itself—decide to retrieve, formulate the search, evaluate the results, incorporate them into the ongoing reasoning—runs entirely within the system, driven by signals the collaborator cannot perceive and governed by thresholds or training objectives the collaborator did not set. The Stera relation, by contrast, requires that the Scintilla direct the model throughout the information-gathering process: not merely to judge the product but to shape the process, to bring their domain awareness, their source skepticism, their evolving sense of what the conversation needs next to bear on each retrieval decision as it happens. Adaptive retrieval timing, as implemented in these architectures, dissolves that relation by automating it away. The Scintilla is not directing a retrieval pipeline; they are standing outside a retrieval pipeline that directs itself.
The failure modes that follow from this structural choice are not accidents of implementation that could be patched with a better threshold or a larger training corpus. They are consequences of the decision to seal the retrieval loop. I will take up those failure modes next: how confidence-based gating produces silent information diets, how trained retrieval tokens create a critic the collaborator cannot cross-examine, and how both architectures make the source provenance and the retrieval rationale invisible to the one person who needs to see them most.
3.2 Failure Modes of the Sealed Retrieval Loop
The structural commonality identified in the previous section—that both FLARE and Self-RAG seal the retrieval trigger inside the model, inaccessible to the collaborator—is not merely an architectural curiosity. It is the root from which a cluster of specific, predictable failure modes grows. These failures are not bugs in the traditional sense; the systems perform exactly as designed. They are failures of the relation, and they become visible only when we evaluate the architecture against the Stera requirement that the collaborator must be able to direct the model's information-gathering process. Three failure modes are particularly consequential: silent information diets, the uncross-examinable critic, and the double invisibility of provenance and rationale.
3.2.1 Silent Information Diets: How Confidence-Based Gating Conceals Retrieval Decisions from the Collaborator
In FLARE, the model generates a provisional next sentence and computes a confidence score over its tokens. If the probability of any token falls below a fixed threshold $\tau$, the sentence is flagged as uncertain, a query is extracted, retrieval is performed, and the model regenerates with the retrieved passages in context. The collaborator never sees the provisional sentence, never sees the confidence score, never sees the query, and—crucially—never knows that retrieval occurred at all unless the system designer has chosen to surface some fragment of this information in the interface, which the architecture itself does nothing to ensure or encourage.
This creates what I will call a silent information diet: the set of sources the model is exposed to, and the decisions about when and whether to seek sources, are determined entirely by signals the collaborator cannot perceive. The collaborator cannot detect, from the outside, whether a particular claim in the final answer was produced from parametric knowledge or from retrieved sources. They cannot detect whether the model's confidence was low on a sentence that matters deeply to them but fell just above the threshold, causing retrieval to be bypassed. They cannot detect that the query extracted from the uncertain sentence was malformed, or that it retrieved irrelevant or misleading passages that the model nevertheless incorporated because the regeneration step has no separate filtering mechanism.
The confidence threshold $\tau$ is set at development time, applied uniformly to all queries and all collaborators. But the collaborator's need for retrieval is not uniform. A medical researcher asking about a drug interaction needs a fundamentally different retrieval posture than a novelist asking about the plausibility of a plot point. The researcher may want to retrieve on every factual claim, even those the model is highly confident about, because high confidence does not guarantee correctness and the cost of error is catastrophic. The novelist may want retrieval only when explicitly asked, because they value speed and fluidity over source verification. FLARE's uniform gating forecloses both of these postures. The collaborator cannot say "retrieve aggressively here" or "trust your parametric knowledge unless I say otherwise." The threshold was set for them, elsewhere, by someone who does not know them and could not anticipate their task.
Worse, the confidence score is not a reliable proxy for the collaborator's epistemic needs in the first place. A model can be confidently wrong, and it can be uncertain about a stylistic or structural choice that has no factual content. The threshold collapses the distinction between "I am uncertain about the factual correctness of this claim" and "I am uncertain because there are many equally fluent ways to phrase this transition." The collaborator would, if consulted, respond to these two uncertainties very differently—retrieving in the first case and simply choosing a phrasing in the second—but the gating mechanism treats them identically. The collaborator's judgment about what kind of uncertainty matters is replaced by the model's raw token probability, a signal that was never designed to carry that meaning.
The result is that the collaborator's information diet is shaped by a proxy they did not choose, configured at a granularity they cannot adjust, operating through decisions they cannot see, with consequences they cannot audit. This is not directing an information-gathering process; it is accepting an information-gathering process that runs without you and reports only its conclusions. The Stera relation requires the collaborator to bring their own epistemic standards to bear on retrieval decisions—when to seek sources, how aggressively, from what kind of corpus, with what level of skepticism. FLARE's confidence-gating removes every point where that judgment could be exercised.
3.2.2 The Uncross-Examinable Critic: How Trained Retrieval Tokens Create a Judge the Collaborator Cannot Question
Self-RAG appears to address some of FLARE's weaknesses by making the retrieval decision and the critique of retrieved passages into trained behaviors rather than heuristic thresholds. The model learns to generate a [Retrieve] token when the context warrants retrieval, and it learns to generate [Relevant], [Irrelevant], [Partially Supported], and similar critique tokens to filter and assess retrieved passages. These tokens are part of the same autoregressive generation as the final answer, produced by the same weights, trained on the same objective.
But what Self-RAG gains in learnability, it loses in contestability. The critique tokens are generated inside the sealed loop, invisible to the collaborator unless the interface designer chooses to surface them. And even if they were surfaced, the collaborator would have no way to cross-examine them. Why was a particular passage judged irrelevant? The model has no answer to that question beyond the token itself. The [Irrelevant] token does not come with a justification, an explanation, or an opportunity for appeal. It is an opaque verdict produced by a trained classifier that the collaborator cannot interrogate.
In the Stera relation, when the Scintilla retrieves a source and judges it, the model can ask: "Why did you select that source? What makes it credible? How does it bear on our question?" And the Scintilla can answer—they hold the reasons; they exercised the judgment. A trained retrieval token has no reasons, only activations. The collaborator cannot ask the model "why did you mark that passage as partially supported rather than fully supported?" and receive an account of the reasoning. They can only receive, at most, the token itself, and behind it, a distribution over vocabulary items computed by a function they cannot inspect.
This matters because the critique tokens sit at exactly the point in the pipeline where the collaborator's judgment would be most valuable. Determining whether a retrieved passage is relevant to the specific question at hand is not a generic skill separable from the collaborator's domain knowledge, their evolving intentions, their awareness of nuances the query did not capture. The collaborator knows what they meant by a question, knows what would count as an answer, knows what assumptions they are operating under. The learned critic replaces all of this situated knowledge with a generic classification trained on a corpus of examples that cannot anticipate this particular collaborator, this particular task, this particular moment in an unfolding inquiry.
The collaborator becomes, in this architecture, a bystander to the most epistemically consequential moment in the retrieval loop. They see what was kept after the critique, not what was discarded. They have no way to learn that a high-quality source highly relevant to their actual concern was marked [Partially Supported] because its framing didn't match the query's surface form—a nuance they would have caught instantly if they had been shown the passage and asked. The trained critic has appropriated a function that in the Stera relation belongs to the collaborator, and it has done so in a way that cannot be contested because the appropriation itself is invisible and the grounds of the judgment are inaccessible.
3.2.3 The Double Invisibility of Provenance and Rationale
Both architectures share a deeper failure mode that compounds the previous two: the collaborator cannot see where the information came from or why it was selected. This is the double invisibility of provenance and rationale, and it strikes at the foundation of the Stera relation.
In FLARE, retrieval is triggered by low confidence on a provisional sentence. But the collaborator is never shown that trigger, never shown the query that was extracted, never shown which passages were retrieved, and never shown how the model incorporated them into the final answer. The final answer is presented as a seamless text. The collaborator cannot trace a claim in the answer back to a source, cannot assess whether the source is one they trust, cannot notice that the source is from a domain the model should not have been consulting for this task, and cannot catch the possibility that the allogeneic knowledge injected into the context has been mischaracterized or mangled in the regeneration step.
Self-RAG makes portions of this process visible to the model—it sees the retrieved passages and generates critique tokens about them—but makes none of it visible to the collaborator by default. The [Retrieve] token, the retrieved passages, and the [Relevant] / [Partially Supported] / [Irrelevant] tokens are all consumed internally and then discarded from the surface output. The collaborator receives a polished final answer that carries no trace of the retrieval decisions that produced it.
This invisibility matters in the Stera relation because directing requires seeing what happened. A Scintilla cannot direct a retrieval process if they cannot observe its intermediate states. They cannot say "that source is outdated, use a different one" if they never learn that the source was consulted. They cannot say "you misunderstood that passage" if they never see the passage. They cannot say "the query you extracted from my question missed my real concern" if they never see the query. They cannot build a mental model of how the model uses retrieved information—when it relies on sources, when it overrides them, when it misreads them—if the process is opaque.
The absence of provenance and rationale visibility also prevents the collaborator from developing the kind of calibrated trust that the Stera relation depends on. The Scintilla who works with a model over time learns its tendencies: "this model tends to overweight the first retrieved passage," "this model is good at selecting sources in my field but poor in adjacent fields," "this model's queries are usually well-formed but sometimes drop key constraints." This learning requires repeated exposure to the model's actual retrieval behavior—the queries, the selected passages, the filtering decisions. When the loop is sealed, the collaborator is denied the evidence that makes such learning possible. They must trust the model's retrieval judgment without ever having the opportunity to verify, challenge, or calibrate that judgment against their own.
The sealed loop thus produces a paradoxical result: the system that retrieves information for the collaborator ends up making the collaborator less informed about the basis of the answers they receive than they would be if they had simply read the sources themselves. The collaboration degrades into a black-box oracle relationship, where the Scintilla poses a question and receives an answer whose grounds they cannot inspect. This is precisely the relation that Stera is designed to transcend.
3.3 The Dissolution of Direction
Each of these failure modes—the silent information diet, the uncross-examinable critic, the double invisibility of provenance and rationale—is a local manifestation of a single structural dissolution: the removal of the collaborator from the interior of the retrieval loop. In both FLARE and Self-RAG, the collaborator is repositioned from director to endpoint. They provide the query at the start and receive the answer at the end, while the system runs the retrieval process autonomously between those two boundaries. Every decision that constitutes the retrieval pipeline—whether to retrieve, what to retrieve, how to evaluate what was retrieved, what to incorporate and what to discard—is made by the model, for the model, signaled by model-internal variables, and sealed from the collaborator's perception and intervention.
This is not an accident of implementation that could be fixed by exposing more internal state to the user interface. The architecture is the decision to make these decisions model-internal. Adding an option to display the [Retrieve] tokens or the confidence scores to the user does not change the structure of the relation; it merely makes the sealed loop transparent without making it directable. The collaborator can see what the model decided, but they still cannot decide themselves. They cannot say "I see that you marked that passage as irrelevant; I disagree—use it." The tokens are output, not input; they are records of a completed autonomous process, not bids in an ongoing collaboration.
The Stera relation fundamentally requires a different structure: one where the retrieval loop is open, meaning that between the point where a retrieval decision is considered and the point where it is executed, the collaborator has a genuine opportunity to shape the decision. This does not mean the collaborator must micromanage every retrieval; it means the architecture must provide affordances for the collaborator to interject their judgment at points where judgment is consequential, and must make the default flow legible enough that the collaborator knows when such interjection would be valuable. The collaborator must be able to set retrieval policy at a level above individual queries—"in this session, always retrieve from these sources, never from those"—and must be able to review and override specific retrieval decisions when the stakes warrant it. They must be able to see the provenance of each claim in the final answer, trace claims to sources, and contest the model's interpretation of a source.
What would an architecture that preserves the Stera relation require? It would require, at minimum, three things. First, retrieval triggers must be negotiable rather than automatic: the model may propose that retrieval would be beneficial, but the collaborator must be able to accept, reject, or modify that proposal in the live interaction, and must be able to set standing policies that govern the default behavior. Second, retrieved sources must be surfaced and contestable: the collaborator must see what was retrieved—not necessarily every passage in full, but enough to assess relevance and quality—and must be able to flag sources as unsuitable, request re-retrieval with modified queries, or mark sources as authoritative. Third, the rationale for retrieval decisions—why this passage was selected, why this one was discarded—must be articulable on demand, so that the collaborator can cross-examine the model's judgment and the model can learn from the collaborator's corrections.
These requirements point toward a retrieval architecture that is structured as a dialogue rather than as a subroutine. The loop is not sealed; it is punctuated by natural junctures where the model presents its proposed next step and the collaborator can redirect. This does not slow the collaboration unnecessarily—a well-designed architecture would allow the collaborator to pre-authorize most retrieval decisions and only surface the unusual or high-stakes ones—but it preserves the structural possibility of direction at every point. The collaborator remains inside the loop, not outside it. The relation remains one of a Scintilla directing a model, not a Scintilla receiving the output of a self-directing system.
I turn now to the second architectural pathway: recursive retrieval, where the decision to retrieve is not simply a binary gate but an iterated process that can call itself.
I turn now to the second architectural pathway: recursive retrieval, where the decision to retrieve is not simply a binary gate but an iterated process that can call itself.
The Architecture of Recursive Retrieval in IRCoT
Interleaved Retrieval with Chain-of-Thought (IRCoT), introduced by Trivedi et al. (2023) for multi-step question answering, embodies recursive retrieval in its most explicit form. The architecture interleaves retrieval and reasoning at the granularity of individual reasoning steps. The pipeline begins with a question Q. The model generates the first step of a chain-of-thought reasoning trace: a sentence S₁ that expresses a partial inference or a sub-question that must be answered. Instead of completing the full chain, the system pauses generation at this juncture and uses S₁ as a query to the retriever. The retrieved passages D₁ are then appended to the context, and the model generates the next reasoning step S₂, conditioned on Q, S₁, and D₁. S₂ then becomes the query for the next retrieval, yielding D₂, which conditions the generation of S₃, and so on. The process continues until the model generates a complete answer, at which point the loop terminates.
The critical architectural feature is that retrieval is not a pre-processing step nor a single mid-generation intervention; it is a repeated, stateful operation where each retrieval's output shapes the next reasoning step, which in turn shapes the next retrieval. The recursion is not a fixed number of iterations—it is data-dependent, continuing until the reasoning trace resolves. Formally, the sequence is:
Q → (S₁, retrieve(D₁)) → (S₂, retrieve(D₂)) → … → (Sₙ, Answer)
where each Sₖ = LLM(Q, S₁, D₁, …, Sₖ₋₁, Dₖ₋₁) and each Dₖ = Retriever(Sₖ).
This design makes an implicit claim: that the information need at step k is best expressed by the reasoning the model has produced up to that point, not by the original question alone. The retrieval is adaptive not in the sense of a classifier deciding "retrieve now" but in the sense that the retrieval query itself evolves as the model's understanding evolves. The recursion is, in effect, a form of active information gathering where the model progressively refines its queries based on what it has already learned.
The Architecture of Recursive Retrieval in Self-RAG
Self-Reflective Retrieval-Augmented Generation (Self-RAG), proposed by Asai et al. (2024), takes a different approach to recursion: instead of interleaving retrieval with step-by-step reasoning, it trains the language model to generate special reflection tokens that govern retrieval and critique. The model is fine-tuned to output tokens such as [Retrieve], [No Retrieve], [Relevant], [Irrelevant], [Supported], [Partially Supported], and [Unsupported]. During generation, when the model produces a [Retrieve] token, a retriever is called with the current generation context as the query, the retrieved passages are inserted, and generation continues. Critically, after generating a segment conditioned on retrieved passages, the model then generates critique tokens—[Relevant] or [Irrelevant] for each passage, [Supported] or [Partially Supported] for the output—and if the critique indicates a problem (an irrelevant passage, an unsupported claim), the model can trigger a second retrieval or regenerate the problematic segment.
The recursion here is not a linear chain of alternating retrieval and reasoning, as in IRCoT, but a more complex decision graph. At each generation step, the model makes two distinct kinds of decisions: whether to retrieve, and whether the previous retrieval was adequate. The [Relevant]/[Irrelevant] tokens act as a self-assessment loop embedded within the generation process. If a passage is marked [Irrelevant], the model may re-query with a revised context, leading to a retrieval that is conditional not only on the original question and prior reasoning but on the model's own judgment of retrieval quality. This is recursion with self-awareness: the model not only retrieves iteratively but evaluates its retrievals and uses those evaluations to decide whether to retrieve again.
Failure Modes: When Recursion Compounds Error
Both architectures share a structural vulnerability: when the model's judgment of its own information needs is wrong, recursion amplifies rather than corrects the error. In IRCoT, if the first reasoning step S₁ is factually mistaken or poorly formulated as a retrieval query, the passages D₁ will be misaligned with the true information need. The model then conditions S₂ on D₁, which means the second reasoning step is built on a foundation of irrelevant or misleading evidence. S₂ then becomes the query for the next retrieval, and the process compounds: the model drifts further from the correct evidentiary base with each iteration. The loop has no external correction mechanism. If the model hallucinates a plausible-sounding but incorrect fact in S₁, the retriever—dutifully retrieving passages similar to that hallucination—will return documents that reinforce the error. The model, seeing its hallucination echoed in retrieved text, gains confidence in its mistake. The recursion becomes an error-amplification engine.
This failure mode is especially insidious because the final output can appear well-supported: it cites real passages, and those passages do contain the claims the model makes. The problem is that the model selected those passages precisely because they matched its pre-existing error. The retrieval is not a guardrail against hallucination; it is a mirror that reflects and legitimizes hallucination. From a Stera perspective, this is a sealed loop with a dangerous illusion of soundness. The collaborator sees citations and may be reassured, but cannot see that the retrieval pathway was determined by an initial misstep and that the system effectively argued itself into a coherent but wrong answer by selectively gathering evidence that fit its first guess.
In Self-RAG, the self-assessment tokens introduce a second-order vulnerability: the model's judgment of its own retrieval adequacy can itself be wrong. The fine-tuning data for Self-RAG trains the model to produce [Relevant] when a passage is on-topic and [Irrelevant] when it is not. But relevance is a subtle predicate, and the model can misclassify. A passage that appears superficially relevant—sharing many keywords with the query—may be substantively misleading or outdated. If the model marks it [Relevant], the recursion terminates prematurely; the model proceeds with inadequate evidence and the self-assessment loop provides false assurance. Conversely, the model might mark a genuinely useful but counterintuitive passage as [Irrelevant], triggering an unnecessary re-retrieval that wastes computation and may lead the model to a less useful source. The recursion can oscillate: retrieve, critique as irrelevant, re-retrieve, critique again, in an unbounded loop that never converges because the model's relevance threshold is miscalibrated for the task.
Both architectures also share a more fundamental opacity problem that emerges from the iterative structure. In a single-step retrieval system, the provenance of the answer is straightforward: the answer is conditioned on passages P₁ through Pₖ, and the collaborator can inspect those passages and judge their relevance. In a recursive system, the provenance is a tree. The final answer depends on passages retrieved at step n, but those passages were retrieved using a query generated at step n-1, which depended on passages retrieved at step n-2, and so on. To understand why a particular claim appears in the final answer, the collaborator must trace not only the cited passage but the entire chain of reasoning and retrieval that led the system to that passage. The reasoning trace may have multiple branching points—places where the model could have chosen a different query, retrieved different passages, and arrived at a different answer—and none of those counterfactuals are visible in the final output. The collaborator is presented with a fait accompli and a handful of citations, but the process that produced them is a black box.
The Stera Requirement: Cross-Examinable Retrieval, Not Transparent Retrieval
The Stera relation demands more than transparency; it demands cross-examinability. The collaborator must be able to challenge not only "what did you retrieve?" but "why did you retrieve this and not that, and at this point rather than another, and what alternative retrieval pathways did you foreclose?" This is a higher bar than simply displaying the retrieved passages or surfacing the self-assessment tokens. Displaying the chain of [Retrieve] and [Relevant] tokens to the collaborator, as one might imagine doing in a "transparent" Self-RAG deployment, does not make the loop cross-examinable. It makes the loop legible in retrospect, but the decisions remain frozen. The collaborator sees a record of choices already made; they cannot interrogate the choice at the point of decision and redirect the system before the consequences propagate.
To make recursive retrieval cross-examinable, the architecture must be restructured so that the collaborator can interrupt the recursion at a decision point—before a retrieval query is issued, before a relevance judgment is finalized—and inject their own judgment. This requires the recursion to be synchronous with the interaction loop, not an autonomous process that runs to completion behind the scenes. In concrete terms, the model would generate a proposed reasoning step and a proposed retrieval query, then pause and present both to the collaborator. The collaborator could approve the query as-is, modify it ("search for this instead"), broaden or narrow its scope, specify source constraints, or decide that retrieval is unnecessary at this step. Only after the collaborator's signal would the retrieval proceed. Once passages are retrieved, the model would surface its provisional relevance judgments—"I think passage A is highly relevant because X; passage B is tangentially relevant because Y"—and the collaborator could override. The model could also surface its confidence in the retrieval: "I'm uncertain whether this passage from 2016 reflects current practice; I recommend re-retrieving with a recency filter." The collaborator could then direct the re-retrieval or instruct the model to proceed with a caveat.
This design preserves the recursive structure—retrieval still iterates with reasoning, queries still evolve as understanding deepens—but removes the seal. The recursion becomes a scaffold for collaboration rather than a self-contained mechanism. The collaborator is not passively observing a process; they are steering it at the granularity of individual retrieval decisions. This does not require constant micromanagement. The collaborator can set default policies: "for this session, always approve retrieval queries that ask for factual verification of my claims, but always pause and ask me before retrieving normative or opinionated material." Or: "proceed automatically as long as your relevance confidence is above 0.9; pause and show me the query and the top three passages if confidence is lower." The architecture must support a gradient of collaborator involvement, from fully automatic retrieval under standing instructions to fully manual approval of every query, with the capacity to shift levels fluidly as the task demands.
This is the architectural meaning of the Stera requirement: the collaborator remains inside the retrieval loop, not outside it, and the loop is structured as a dialogue rather than as a subroutine. Recursive retrieval, as implemented in IRCoT or Self-RAG, is a subroutine: it executes a predetermined program (interleave reasoning and retrieval; self-assess and re-retrieve) until a termination condition is met. The collaborator receives the output of that subroutine. To restructure it as a dialogue, the architecture must replace the autonomous termination condition with a collaborator-mediated one: the recursion continues not because the model has judged its answer complete but because the collaborator, having cross-examined the retrieval provenance and reasoning trace, is satisfied that the evidentiary foundation is sound.
This is where the architectural junctures of IRCoT become sites of explicit redesign. I want to walk through them with surgical precision, because each one encodes an assumption about where authority resides, and each must be opened and rewired to admit the collaborator.
Retrieval trigger logic. In IRCoT, the trigger is internal and autonomous: the model generates a chain-of-thought until it produces a token sequence that the system parses as a retrieval request—typically a special marker like [Retrieve( ... )] or a structured query delimited by brackets. The model decides when to retrieve and what to query, based solely on its own reasoning trajectory. There is no external signal, no pause, no presentation of intent. The trigger is a product of the model's autoregressive generation, indistinguishable in kind from any other token the model produces. The system simply intercepts the output, executes the retrieval, and feeds the results back into the context. The model does not know that it has triggered anything; it simply continues generating when the retrieved passages appear.
To implement the Stera collaborator-mediated dialogue, this trigger logic must become propositional rather than executive. The model still generates a proposed retrieval—it still formulates a query in the course of its reasoning—but the architecture must intercept the proposal before it becomes an action and route it to the collaborator. Concretely, this means the generation pipeline must include a parsing layer that recognizes a retrieval proposal as a distinct speech act (not merely a token pattern) and halts generation, serializes the proposal (the query string, the reasoning context that motivated it, any metadata the model can provide about its purpose), and presents it in the collaborator's interface. The system does not retrieve until the collaborator signals assent—or until a standing policy, previously authorized by the collaborator, matches the proposal's properties and auto-approves it.
The governance implication is straightforward and profound: the collaborator gains ex ante control over what information enters the reasoning context. Information retrieval is a consequential act—it selects from a corpus, it imports external claims, it shapes the evidentiary basis for whatever the system will subsequently generate. When retrieval is autonomous, the collaborator cannot prevent the system from importing misleading, stale, or normatively slanted material except by post-hoc correction, by which time the material has already influenced the reasoning trajectory. When retrieval is propositional, the collaborator can veto a query before it executes, redirect it toward more authoritative sources, or impose constraints (date ranges, domain restrictions, source whitelists) that the autonomous trigger would not have applied. This enables a specific form of oversight—procedural gatekeeping—that is foreclosed when the trigger is purely internal. The collaborator is not merely reviewing outputs; they are shaping the information diet on which those outputs depend.
Reasoning-then-query loop. In IRCoT, this loop is a tight coupling: the model produces a reasoning step, then immediately produces a retrieval query, then receives passages, then produces another reasoning step informed by those passages, then another query, and so on. The loop runs at inference speed, with no external breaks. The model's reasoning and its retrieval decisions are interleaved in a single autoregressive stream; the retrieval results are simply inserted into the context and the model continues. The loop's structure is procedural—it is a for-loop in the system code, not a conversation.
To restructure this as a collaborator-mediated dialogue, the loop must be unrolled into discrete turns, each of which concludes with a pause at the collaborator interface. The model generates a reasoning segment and a proposed retrieval query, then stops. The collaborator inspects the reasoning segment (Is this inference sound? Is it relying on an assumption I want to challenge? Has it misunderstood the domain context?), inspects the proposed query (Is this the right question to ask next? Would a different query yield better evidence?), and responds. The collaborator's response might be: approve the query; approve with modifications; reject and propose a different query; reject and instruct the model to reconsider its reasoning; or decide that no further retrieval is needed and the reasoning should proceed directly to synthesis. Only after this turn does the system execute the (possibly modified) query, retrieve passages, and present them—along with the model's provisional relevance judgments—for another collaborator review before the next reasoning step begins.
This unrolling has a governance implication that goes beyond gatekeeping: it enables interrogation of the reasoning itself at the point of decision. In the autonomous loop, the model's reasoning and retrieval decisions form a single opaque trajectory. The collaborator sees the final answer and perhaps a post-hoc trace, but cannot challenge an intermediate inference while it is still malleable—while the system has not yet committed to a line of reasoning that subsequent retrieval will reinforce. By inserting a collaborator checkpoint between each reasoning step and its consequent retrieval, the architecture creates a natural site for cross-examination. The collaborator can ask: "Why do you think this query follows from that reasoning step? What alternative queries did you consider? What would you do if the retrieval returns no relevant passages—how would your reasoning change?" The model can respond, and the collaborator can redirect before the system invests further computation in a flawed trajectory. This is contestability at the granularity of epistemic moves, not merely at the granularity of final outputs.
Termination condition. In IRCoT, termination is autonomous: the model decides that it has enough information to answer the original question, or it hits a maximum iteration count, or it detects that its answer has converged across successive retrieval rounds. The system stops retrieving and produces a final output. The collaborator has no role in this judgment. The model might decide it is finished prematurely—because it has not recognized a gap in the retrieved evidence, because it has settled on a plausible-sounding but under-substantiated claim, because it has failed to notice that a key source contradicts its provisional conclusion. Or it might over-retrieve, chasing diminishing returns because it lacks the collaborator's sense of when enough evidence is enough for the purpose at hand.
The Stera restructuring replaces the autonomous termination condition with a collaborator cross-examination checkpoint. When the model judges that it has completed its retrieval and reasoning—or when it reaches a point where it wants to propose a final synthesis—it does not proceed directly to output assembly. Instead, it pauses and presents a structured summary of its epistemic state: the claims it intends to make, the sources it has retrieved to support each claim, its confidence in each source's relevance and reliability, and any gaps or uncertainties it has identified. The collaborator then cross-examines this summary. They might ask: "You claim X based on source S1, but S1 is from 2019—is there more recent evidence? Did you search for it?" Or: "You've cited three sources that all come from the same research group; have you looked for independent replication?" Or: "This claim seems to go beyond what the source actually says—show me the passage." The model must respond, potentially triggering additional retrieval rounds if the cross-examination reveals evidentiary weaknesses. Only when the collaborator is satisfied—when they judge that the evidentiary foundation is sound and the reasoning is faithful to the sources—does the system proceed to output assembly.
The governance implication here is evidentiary accountability. The collaborator does not merely review the final output; they certify that the system's process for gathering and weighing evidence met their standards. This certification is itself a governance artifact: the collaborator can later point to the cross-examination record and say, "I approved this output after verifying that the retrieval was comprehensive, the sources were authoritative, and the reasoning was faithful." If the output later proves to be wrong or harmful, the provenance is traceable not only to the sources but to the specific judgments the collaborator made (or failed to make) during cross-examination. This creates a clear site of responsibility—the collaborator's decision to terminate retrieval and proceed to output—rather than diffusing responsibility into the model's black-box termination heuristic.
Output assembly. In IRCoT, the final output is generated by the model in a single autoregressive pass, conditioned on the full history of reasoning steps and retrieved passages accumulated in the context window. The output may cite sources, but these citations are generated by the model, not mechanically linked to the retrieved passages—and even when they are mechanically linked, the link is between a generated claim and a passage that appeared somewhere in the context, without a structured, auditable mapping.
The Stera restructuring requires that output assembly produce a provenance trail: a structured artifact that maps each substantive claim in the output to the specific retrieved passage(s) that support it, with the collaborator's cross-examination judgments attached at the relevant decision points. This is not merely a bibliography or a set of inline citations. It is a structured data object—a provenance graph—that the collaborator can inspect, query, and export. For each claim, the graph records: the source passage(s) from which the claim was derived or synthesized; the retrieval query that produced each passage; the collaborator's approval (or modification) of that query; the model's relevance judgment and the collaborator's review of that judgment; and any cross-examination exchanges that pertained to that claim's evidentiary basis. The output text itself is generated with a citation scheme that references nodes in this graph, so that a reader—or an auditor, or a regulator—can click from a claim to its full provenance chain.
The governance implications compound. First, provenance enables contestability after the fact: a third party who was not present during the collaboration can examine the output, identify a specific claim they dispute, and trace it backward through the collaborator's cross-examination decisions to the original source. They can ask: was the retrieval query adequate? Did the collaborator approve a query that was too narrow? Did the model's relevance judgment overstate a source's support? Second, provenance enables accountability for the collaborator's steering decisions: the record shows not only what the model did but what the collaborator chose to approve, redirect, or overlook. If the output contains an error, the provenance trail can distinguish between "the model hallucinated despite adequate retrieval" (a model failure), "the retrieval was inadequate because the collaborator approved an overly restrictive query" (a steering failure), and "the source itself was erroneous in a way no reasonable cross-examination would have detected" (an exogenous failure). Third, provenance transforms the output from a static text into an auditable process record. This is essential for governance regimes that require not only accurate outputs but demonstrable due diligence in producing them—regimes where the question is not just "is this claim true?" but "was the process that produced this claim appropriately rigorous, given the stakes?" The provenance trail is the artifact that answers the second question. Without it, the Stera restructuring has created a collaboration but left no trace that the collaboration was sound; the collaborator's cross-examination exists only in ephemeral interaction history. With it, the collaboration becomes an institutional record—one that can be reviewed, challenged, and learned from.
Comments