Meaning is an engineering problem

An LLM knows nothing but the context you give it: whatever isn't in that window doesn't exist for the model. So context engineering comes down to one question: what do you put in, and does it carry its own meaning? Reach for your data and you hit the wall at once. We told ourselves the hard part was done when the data was in the computer. But that only ever answered where the information lives, never what it is about. A database can hold a million invoices and still not know that two of them name the same company. It shuffles the symbols flawlessly without grasping what any of them stand for. Holding a symbol is not understanding it, and a symbol with no meaning is context that can't speak.

The meaning isn't lost. It just isn't written down anywhere a machine can read, so it can never be loaded into a context window. It lives as implicit knowledge in the people who run the system, and in working practices handed from desk to desk. The system "works" only because a human quietly supplies the half that was never recorded. Engineer context out of this data and you ship the bytes and leave the meaning behind. When that person leaves, the meaning leaves with them.

• Foreign keys everyone understands but nobody declared: the joins live in habit, not in the schema.
• A column called flag that means three different things depending on which team filled it in.
• The rule that you always exclude region 9 from the totals: known at the desk, written nowhere.
• Two tables you must never join directly, and the one analyst who remembers why is retiring in March.

Every one of these is meaning the machine can't see. The data leans on a running commentary that no system holds and no system enforces. That's not a quirk of one badly run database. It's the normal state of almost all enterprise data.

Pull context from more than one system and it doesn't add up. It contradicts. Each system carries its own private, unwritten model, so no two of them agree. The same real thing turns up under a different name, a different key and a different shape, and nothing tells them they are the same thing. Stuff that into a context window and you don't get a fuller picture. You stack the contradictions.

One company · three systems · no shared key

One company, three records, and not a single key in common. Integration moves the data between systems; it does nothing to reconcile what the data means. Many tongues and no shared language: the data version of the Tower of Babel. Reports don't tie out, the same customer is counted twice, and every new system added to the pile makes the confusion worse, not better.

The new move is to lay a large language model over all of this and call it context. But a fluent model inherits every inconsistency beneath it and invents to fill the gaps. Because nothing was ever made explicit, there is no firm ground for it to stand on and nothing to sense-check it against. Ungrounded context doesn't just limit the AI. It makes the AI confidently wrong.

Both failures trace back to the same hole as everything above: the meaning was never made explicit or shared. Supply that, and an AI can finally be grounded and graded.

Couldn't you just describe all this in plain language, as a pile of definitions and notes, and let the model work out the rest? It doesn't hold. Natural language alone can't carry the meaning. Prose is where the ambiguity lives, not where it gets resolved: the same word still means three things, and no amount of description tells the model that two records are one company. It's expensive, too. Re-narrating the world in every prompt burns the context budget you needed for the task, and a longer, looser description is a less reliable one, not a fuller one. Meaning has to be made explicit and structured, not merely narrated: succinct enough to fit the window, precise enough to act on, and shared so that every system, and the model, reads it the same way.