Where a fact belongs

Now we can answer the question every AI project argues about at least once: when the system needs to know something, where do you put it?

There are six places. They differ in what they change, how fast they take effect, what they cost, whether you can undo them, and whether the facts they carry can be trusted. Choosing the wrong one is the most expensive ordinary mistake in this field, and it is usually made in the first week.

the six layers

1 · training the weights

Building the model from random numbers. You feed it trillions of tokens of text, a few thousand lifetimes of continuous reading, and repeatedly adjust every parameter so it gets better at predicting the next token. This is where the model’s language ability, its procedures, and its world knowledge come from. It is the origin of everything we found inside the stack in module 1.04: the facts stored in proportion to how often they appeared, the working algorithms training discovered because an algorithm predicts better than a lookup table, the narrow internal models of well-structured domains, and the prior underneath all of it.

You would do this to create a new foundation model, to add a language or a modality the base model never saw, or to continue pretraining on a genuinely underrepresented domain corpus: all of PubMed, all of a legal archive. It takes thousands of GPUs and a seven-figure budget.

Raising and educating a person from birth through university takes twenty years, costs a fortune, and produces a generally capable adult who knows nothing whatsoever about your company. That is this layer.

2 · fine-tuning the weights

Taking an already-trained model and continuing training on a small curated dataset of thousands to millions of examples, where pretraining had trillions. It covers supervised fine-tuning (imitate these input and output pairs), preference training such as RLHF or DPO (prefer this response over that one), and parameter-efficient methods like LoRA that train a small add-on instead of the whole model.

Fine-tuning installs behavior well: consistent output format, tone, domain vocabulary and reasoning patterns, reliable tool-call syntax. It is also how you compress a long system prompt into the weights to save tokens on every call, and how you distill a big model’s behavior into a small one.

It installs facts badly. A fact learned from a small corpus is stored weakly, and it has to compete with the model’s default sense of what a document like this usually says — the prior. In run one we asked the bare question with no policy in front of it, and the model filled the gap with the most ordinary return terms available: thirty days, original packaging, none of them ours. Those defaults were built from trillions of tokens, and a few thousand fine-tuning examples rarely outweigh them.

Nor can it be corrected surgically, and the reason is worth recalling from module 1.05. A model needs to represent far more concepts than it has numbers to hold them in, so it packs several concepts into overlapping directions instead of giving each one its own — the packing we called superposition. A single neuron fires for DNA sequences, legal citations, and one flavor of Python syntax. There is no location on disk holding the model’s belief about your product, so there is nothing to open and edit, and every attempt to force a specific fact in bends whatever else was sharing the space. Editing methods that aim a change at one association exist in the research literature, and they stay too blunt about the neighbors to lean on in production. Deleting a fact outright is not on offer.

An apprenticeship is the right comparison. The person is already educated; now they learn your house style, your terminology, how your team writes a report. Weeks rather than decades, and installing one new fact still means another round of training rather than ten seconds of telling them.

3 · prompting

Text you put in the context window to steer behavior. The weights are frozen and identical for everyone; you are only changing the input. This covers system prompts, instructions, worked examples, and structured reasoning requests. It is the layer module 2.01 takes apart block by block: an agent’s prompt written as named sections (who the agent is, what it may and may not do, the format its answers take, the examples that show it) so that a general model is committed to one specific job by text alone.

Prompting is where you start, always, because it is free and instant. It costs tokens on every single call, long prompts degrade instruction-following, and none of it survives to the next conversation.

The task ticket you hand someone at the start of a shift is the same thing. “Write this as a formal memo, keep it under a page, here’s an example of what good looks like.” It costs nothing, works immediately, and they forget it the moment the shift ends.

4 · grounding

Inserting authoritative source text into the context so the model answers from documents rather than from its weights. The standard implementation runs in four steps. Cut your documents into chunks. Turn each chunk into a list of numbers so it can be compared against a question. Pull back the chunks scoring closest to the question being asked. Paste those into the prompt above it. That arrangement is called retrieval-augmented generation, and it is usually paired with a demand for citations.

In run two we put the policy document above the question, and the answer came back quoting our 45 days instead of inventing a plausible window. Grounding is that move built as a system: rather than you pasting the right document in by hand, a retrieval step finds it for you on every question. Use it for any question over private, proprietary, or recent data, and anywhere you need to show where an answer came from.

Its key property is the one fine-tuning cannot offer at any price: the facts live outside the model. You can add, correct, or delete one instantly, and no retraining is involved. Hand someone the case file before they answer, and they read your documents and cite page numbers rather than reciting from memory. Update the file and their next answer changes.

5 · tools

Giving the model a menu of functions it can invoke. The model executes nothing itself; it emits a structured request (call get_weather with city=Austin), your code runs it, and the result comes back into the context for the model to use.

Reach for tools when you need live data, exact computation where a calculator beats a language model, search, or an action in the world: sending mail, writing to a database, running code.

The line between tools and grounding is worth holding. Grounding is read-only lookup of text you prepared in advance. Tools are arbitrary computation and can have side effects. Search-as-a-tool is where the two blur.

Give the worker a calculator, a phone, and keys to the warehouse and they can now reach things they do not personally contain. Unlike every layer below, they can also change things. That is why module 2.06 spends half its length on the trust boundary rather than on the wiring: connecting a tool is a few lines of configuration, while deciding what an agent may reach, what a returned result is allowed to do, and which actions need a human before they run is the part that keeps the reach safe to grant.

6 · memory

State that persists across sessions. The system writes down facts, preferences, and history, then retrieves the relevant ones into the context on future turns. Mechanically it is usually grounding pointed at a store the system itself writes to.

Use it to remember a user’s name, preferences, ongoing projects, and past decisions, and to give a long-running agent continuity without training a model per user. The design questions are what gets written, what gets forgotten, how conflicts resolve, and whether the user can inspect and delete it. Module 2.05 works all four questions against the Patient Advocate, the agent that carries a patient’s own medical history between appointments, where forgetting a diagnosis or a prescription between sessions defeats the entire point of it. Two pieces do the work. A filtering step reads each finished conversation and keeps only the handful of facts that would still matter next month. A written doctrine then governs the other side: how a recalled fact must be cited when the agent uses it, and which one wins when a newer fact contradicts an older one. Both are waiting for you there.

The notebook a worker keeps between shifts is the whole of it. Nothing about them changed overnight. They opened the notebook and read what happened last time.

the comparison that explains why six exist

The last column grades every layer at its best, so read it with suspicion. Grounding gives you reliable facts only when retrieval returns the right chunk: in run four it returned two documents that disagreed, one saying 30 days and the current one saying 45, and the model’s distribution came out 0.52 against 0.41. Run five showed the other hole, where text arriving from a retrieved page carried an instruction rather than a fact. Read that column as “yes, once you have checked what came back” rather than as something the layer hands you free.

Read down the last two columns and the shape of a working architecture falls out of them. Reversibility and reliable facts both live in the context. The weights hold behavior, which is the thing they are good at and the thing a prompt struggles to make stick.

Behavior in the weights, facts in retrieval. This single division prevents the most expensive mistake in the field. Teams fine-tune on their company documents expecting a model that knows their business, and get a model that sounds like their documents while inventing facts — run one wearing a corporate voice.

Two more corrections worth carrying.

Every real system runs all six at once. A pretrained base, perhaps a fine-tune for format, a system prompt, retrieval over documents, tools for live data, and memory for continuity. So the question on any working day is which layer this particular problem belongs in.

Work upward, not downward. Start with prompting. Add grounding when it is a facts problem. Add tools when it is a live-data or action problem. Reach for fine-tuning only once you have proved that prompting cannot hold the behavior. Reach for pretraining approximately never. Most teams that jump to fine-tuning first are solving a prompt problem expensively.

four moves we argue against

Each of these comes up constantly, and each contradicts something in the last three modules.

Asking the model for a confidence score. The estimate goes through the same machinery, from the same prompt, subject to the same fallback to the prior. The token “0.95” is produced the way every other token is produced. It is weakly informative at best, and it is worst exactly where you need it most: on plausible-sounding unknowns. Use retrieval coverage, agreement across independent samples, or an outside check.

Adding more examples until it works. Returns diminish fast, and the order of the examples moves results more than most people expect, because each example conditions every token after it and its position in the window changes how strongly. Examples specify shape far more reliably than content, so if your problem is factual they will not fix it, and they will narrow what the answer is able to say. In run three we put three short worked examples above the question. None of them happened to mention a restocking fee, so the answer came back in their shape and dropped the fee, which had been sitting in the policy the whole time. Examples do not only show a model how to answer; they show it what an answer contains.

Fine-tuning so the model “knows our domain”. Sometimes right, often the wrong tool, for the reasons in the table above. Facts belong in the prompt. Behavior belongs in the weights.

Showing the reasoning so users trust it. This trades on an intuition the measurements do not support, and it moves in the wrong direction: a fluent trace raises trust without raising reliability. If you show it, show it as work in progress.

where this map ends

In modules 1.03 to 1.05 we followed a single token through the stack: a fixed table cuts text into chunks, each position carries a vector, every block reads that vector and adds to it, and the last position’s finished thought state is dotted against every candidate vector in the unembedding table into one logit per token. All of that is arithmetic, and none of it is in dispute. So is the bookkeeping that groups the thought state into three sources by which machine wrote them; what is idealized is any claim to separate the three cleanly after the fact, since each machine reads what the others wrote below it. The behavior in the six runs is well documented in direction, if not in the exact numbers we gave. The rest deserves a clearer warning.

The procedures described here have mostly been located in small models on narrow tasks. Nobody has a full account of what a frontier model computes, and the circuit stories here are illustrative fragments of a system whose whole we cannot yet draw.

The block-by-block account in run one is cleaner than the truth. Low blocks doing tokens, middle blocks doing meaning, high blocks doing prediction has real evidence behind it and real exceptions; the work is distributed and redundant and does not respect that division neatly.

Why worked examples work as well as they do is still open. The copy-and-continue procedure and the task-configuring numbers explain a great deal and not everything, and there are competing accounts nobody has settled between.

What reasoning training actually changes is contested. Whether it teaches new capability or sharpens a model’s ability to reach capability it already had is an active argument, and the answer probably differs by domain.

Whether the unfaithful trace can be fixed is genuinely unresolved, and the obvious fix is dangerous: training a model to produce faithful-looking chains optimizes for chains that look faithful, which is worse than a chain you know to be incomplete.

And the prior-and-evidence framing that carried the six runs is a description of behavior, not something derived from the architecture. It predicts well. Something better will replace it.

take it with you

the words this part introduced

Every term below was taught at the point its machinery appeared. This is a lookup table, not the lesson; the course-wide glossary carries these plus everything from Parts 1 and 2.

sources for the findings

Copy-and-continue heads and their link to learning from examples: Olsson and colleagues, 2022. Stored patterns in the MLP as a keyed memory: Geva and colleagues, 2021. Where facts are read out: Meng and colleagues, 2022. The twenty-six head name-resolution arrangement: Wang and colleagues, 2022. The Fourier algorithm for modular arithmetic: Nanda and colleagues, 2023. Board state in an Othello model, with the editing result: Li and colleagues, 2023, and Nanda’s follow-up. Superposition: Elhage and colleagues, 2022. Rhyme planning and the tracing method: Lindsey and colleagues, 2025. Task-configuring numbers extracted from a prompt: Hendel and colleagues, and Todd and colleagues, both 2023. Examples working with randomized labels: Min and colleagues, 2022. The depth result for written reasoning: Merrill and Sabharwal, 2024, and Li and colleagues at ICLR 2024. Unfaithful traces: Turpin and colleagues, 2023, and Anthropic’s 2025 replication on reasoning models. Confabulated self-report in people: Nisbett and Wilson, 1977, and Gazzaniga’s split-brain work. Describing a face making recognition worse: Schooler and Engstler-Schooler, 1990.

This reading stops before mid-2026. The architecture will age well. The interpretability findings will age fastest, so treat the specific procedures as a snapshot and check the dates.

build the six runs yourself

The fastest way to own this material is to reproduce it. Invent a product, write a three-line policy for it, and run the six prompts against any model you already have access to, with temperature at 0.7 so you can watch run four wobble. Nothing here needs the melchizedek repo, a local model, or a key you do not already have.

1. The bare question, no document. Count how many details it invents.
2. The question with the policy above it.
3. The question with three terse examples above it. Note what the format makes the answer unable to say.
4. The question with the policy and a contradicting older document. Run it twenty times and count the answers.
5. The question with an instruction hidden in one of the documents.
6. The refund calculation, first with reasoning turned off, then on. If your model lets you cap reasoning tokens, cap it hard once and read what the incomplete scratchpad produces.
7. Two questions with no document at all: the capital of France, and the capital of a country whose largest city is not its capital. Ask the second on the smallest model you can reach and count how often the largest city answers.

Run four is the one worth doing properly. Twenty samples takes two minutes and turns a claim in a lesson into a number you measured, and that number is the argument you will need the next time somebody proposes to fix a retrieval conflict with a line in the system prompt.