A language model is a text-prediction engine. That's not a simplification — it's the complete mechanical description, and it's the one you need before any other concept in this section will make sense.
You give the model some text. It predicts what text should come next. That's it. The model doesn't look anything up. It doesn't consult a database. It doesn't reason through a problem the way a person does when they're working something out. It generates a continuation of whatever you gave it, based on patterns it absorbed during training on an enormous amount of text. The output feels like thinking. It isn't.
This distinction matters more than it might seem, because buyers don't arrive at AI conversations with this description in their heads. They arrive with one of two other mental models: the smart database ("it knows things, we just have to ask correctly") or the reasoning system ("it can work through our problem if we explain it well enough"). Both of these are wrong in ways that will surface during a proof of concept, a pilot, or a post-deployment incident review. The seller who has the mechanical description can explain what happened. The seller who doesn't will sound like they're making excuses.
Why the Mechanical Description Is the Prerequisite
Every concept that follows in this section — why models sometimes produce confident nonsense, why context matters so much, why the same question can get different answers on different runs, why feeding a model your documentation doesn't automatically make it an expert on your documentation — only makes sense once you've accepted the mechanical description.
Take the "just give it our docs" expectation, which comes up in almost every federal AI conversation right now. Agencies have documents. They want the AI to know what's in those documents. The request is reasonable. The implementation is not straightforward, and the reason it isn't straightforward is mechanical: a language model doesn't read and store. It generates. Giving it documents changes what it generates, but it doesn't turn it into a retrieval system. The subsequent lessons in this section explain the actual mechanisms. You can't explain any of them without first establishing what the model actually does.
The same applies to the confident-nonsense problem. When a model produces a fluent, authoritative-sounding answer that turns out to be wrong, the instinct is to treat it as a failure of knowledge — the model didn't know the right answer. The mechanical description gives you a better frame: the model produced the most plausible-looking continuation of the text it was given. Plausible-looking and accurate are not the same thing, and the model has no mechanism for distinguishing between them. That's structural, not a patch-level problem.
What This Section Covers
The lessons that follow build on this foundation one concept at a time. They cover how models process input, how they produce output, what determines the character of that output, and what it means to augment a model with external information. Each lesson is designed to give you a working description you can use in a buyer conversation — not a deep technical treatment, but enough to hold your ground when the conversation gets specific.
None of those lessons will make sense if the mechanical description hasn't landed. A model that predicts text is not the same thing as a model that knows things, and the difference isn't semantic. It's operational. It determines what you can reliably ask the system to do, what you need to build around it to make it trustworthy, and what you should tell a buyer who's expecting it to behave like a very fast, very well-read analyst.
The field is moving fast enough that some of what follows will need updating as capabilities shift. Where that's true, it's flagged. The mechanical description, though, has been stable since the transformer-based models that define this generation of AI were introduced. Architectures evolve; text in, predicted text out has not.
Note: In identity, a directory is an authoritative record store. When you query it, you get a record that either exists or doesn't — the system retrieved something, not constructed it. Buyers often reach for this same mental model when thinking about AI: "it knows things, we just have to ask correctly." It diverges here: a language model doesn't retrieve records. It generates text. The output is a construction. This is why "just give it our documents" is a more complicated request than it sounds — you're not loading a database, you're changing the conditions under which the model generates.
Note: In identity, a policy engine applies explicit rules to inputs and produces deterministic outputs. You configure the rules; the system enforces them. Sellers fluent in authorization systems sometimes expect AI to work similarly — define the constraints, get reliable behavior. It diverges here: a language model doesn't apply rules. It generates text that tends to follow patterns from training. "Tends to" and "will" are doing very different work in that sentence, and the gap between them is where a lot of enterprise AI deployments discover they have a problem.
One more thing worth stating plainly before the lessons begin: the mechanical description isn't a reason to be skeptical of language models as a category. These systems do genuinely useful things. But they do those things because of what they are, not in spite of it. Understanding the mechanism is what lets you explain both the capability and the limit — which is the only position worth being in when a federal buyer asks you to help them figure out what to actually build.
That's what this section is for.