Read The Stack Sideways
A language-model claim stays unfinished until it names the dataset, the interface, the measurement, the user, the failure mode, and the cost of an error.
A language-model claim has six parts, and a benchmark score is one of them. A claim that reports only the score is unfinished.
The other five sit in layers the benchmark never reaches, and each of them changes what the number means.
A Model Is A Corpus, An Objective, And A Deployment Surface
Count the parameters and you describe one part of the object. The same model is a training corpus, a tokenizer, an objective, and a compute plan. It is also a deployment surface and a set of institutional consequences.
Each of those parts gets a note of its own later in this unit. The corpus belongs to the data note, the tokenizer to the modeling note, the objective to the training note. Compute lands in the parallelism and scaling notes, and the consequences land in the harms, security, and legality notes.
The weights are the cheapest part of the object to describe. They predict the least about what the system does once it reaches users. A strong benchmark score sits next to weak data governance, an unsafe deployment, a privacy leak, or a serving bill nobody checked.
The Sequence Runs Behavior, Responsibility, Machine Room, Frontier
The first two notes ask what a language model is and what it does. Next-token prediction is a small objective, and the behavior it produces does not stay small once the training run gets large. Both notes treat the model as a probability machine that became a general interface.
The middle notes turn to the world around the model. Bias, toxicity, disinformation, data provenance, security, privacy, and law arrive here. Each one asks who benefits and who carries the risk when the model is wrong.
The back half opens the machine. Tokenization and Transformers set the shape of the model, and training objectives and optimization set what it practices. Parallelism and scaling laws turn frontier training into an infrastructure problem with a bill attached.
The last stretch covers scale, sparsity, adaptation, and cost. Selective architectures and adaptation make a system more useful without a bigger dense model. The environmental note prices what the whole plan consumes.
Read The Stack Sideways
The stack reads better sideways than top to bottom. A choice made in one layer arrives as a bill in another, and the other layer usually belongs to a different note.
The tokenizer is a modeling decision. Split text into finer pieces and every sequence gets longer. Longer sequences cost memory, and the parallelism note plans around that memory.
A corpus filter is a data decision. The filter decides which text disappears, and what disappears returns later as the subgroup the first harms note finds inside an average.
Give a model tool access and you make a deployment decision. The model then reads untrusted text while it holds tools and private context, which the security note treats as prompt injection. The duty to disclose what leaked belongs to the legality note.
Whenever A Model Surprises You, Name The Layer
Name the layer and the surprise turns into work you can price. Once the layer has a name, you can inspect it and change it. I keep this rule because a layer with a name has an owner, and you can ask an owner for a number.
The capabilities note opens on one of these surprises. You put examples in the prompt, the model follows the pattern, and the result looks like a new task learned on the spot.
Two layers produced that. Scale is one, because the capability appears only after the model gets big enough. The interface is the other, because the examples inside the context window write a temporary task specification.
Change the prompt format and the capability moves while the weights stay the same. One of those two layers costs a training run to change. The other costs a prompt edit. Name the layer and you know which bill you are about to pay.
A Finished Claim Names Six Things
A behavior starts in data and objective choices. It appears through an interface, an evaluation judges it, and then it reaches real users under real constraints. Each step in that chain leaves something the claim has to name.
- The dataset says where the behavior came from.
- The interface records how you asked, because a different prompt is a different claim.
- The measurement fixes what counted as success and what counted as failure.
- The user is the person who meets the output, under whatever pressure they already carry.
- The failure mode names what goes wrong and on which slice of the traffic.
- The cost of an error is what the wrong answer takes from the person who receives it.
A benchmark score stays true while five of the six stay missing, which makes it easy to report and hard to act on.
The Builder Test
Take one deployment claim you already make about a system you run. Trace it from the source data through the objective and the training run.
Continue through the evaluation contract and the user interface, then the monitoring loop. Stop at the rule that changes a launch decision, and write that rule down.
If the interface you measured under has no name in your notes, stop and write it down. The trace fails at the first step where you cannot name an owner. That step is the layer to fix first.
What Carries
You cannot separate model quality from the stack that made it, serves it, and absorbs its mistakes. Read each layer as its own discipline and every risk looks smaller than it is, because the hardest failures cross boundaries.
The first layer to open is the one every other layer conditions on. Read the next-token distribution first, because every layer above it inherits its shape.