Ovia Inc — Artificial Intelligence

Foundations

Models, tokens, and context — what the technology is, what the technology is not, and why those facts decide everything built on top.

What a model is

A model is a very large pattern learned from very many examples. During training, the model reads text, images, sound, or code and adjusts billions of internal numbers until the patterns of the material settle into the weights. Nothing inside works like a database: no sentence sits stored on a shelf waiting to be retrieved. What the model holds is a compressed sense of how language and the world tend to go together, and every answer is generated fresh from that sense, one piece at a time. Understanding that single fact explains most of what the technology does well and most of where the technology fails. A model reasons by resemblance. A model guesses, fluently. Fluency and truth are different properties, and keeping the two apart is the beginning of judgment in this field.

Tokens: the unit of thought

Models do not read words; models read tokens, small chunks of text that range from a single character to a common word. Every prompt is converted into tokens, every answer is produced token by token, and the size of the work a model can hold at once is measured in tokens as well. Costs, speeds, and limits all follow from that unit. When a vendor quotes a context window of so many tokens, the quote describes how much material the model can consider in a single pass: an instruction, a contract, an hour of transcribed conversation. Generation order matters too. The classic approach writes left to right, one token after another. Newer diffusion approaches draft whole blocks in parallel and refine them, which turns generation order from a fixed law into a design choice. What agents can attempt changes when a page can be drafted as a whole and then corrected.

Context: the working memory

Context is everything the model is given for one task: the instruction, the documents, the history of the conversation, the outputs of tools. The model has no memory beyond the context of the moment, so the quality of an answer is largely decided before generation begins, by what was selected, ordered, and shaped for the model to see. That discipline has a name in our practice: context engineering. A longer context window helps, but length is not the same as relevance. A short, well-built context beats a long, careless one, and a model surrounded by the wrong material produces confident answers about the wrong subject. Foundations matter here: anyone who pictures context as a magic memory will design systems that fail quietly. Anyone who pictures context as a desk, cleared and arranged on purpose for each task, designs systems that can be trusted.

What the technology is not

The technology is not a database, not a search engine, and not a colleague. A model does not look facts up; a model reconstructs plausible answers, which is why facts that matter must be supplied, checked, or retrieved by tools around the model. A model also carries no responsibility: the model cannot approve, sign, or answer for an outcome. Open weights have shifted where responsibility can sit. When a release such as Mistral Large 4 can be downloaded and run on private infrastructure, sovereignty and cost move in-house, and so does the duty to evaluate, secure, and monitor the system. The cloud has also shrunk to desk size: a 64GB machine can now run serious models locally with the same runtime later used in deployment, which makes honest measurement possible before a single invoice arrives.

Speed is a craft choice

Performance in this field is often presented as weather: something that happens to a project. The published decoding research tells a different story. Gains come from decisions made early, in the design phase: how tokens get generated, how much work happens in parallel, where a model runs, what the first token costs versus what the full answer costs. Teams that treat speed as a design decision ship systems that feel responsive; teams that treat speed as an afterthought tune forever. Foundations, in the end, are not trivia for beginners. Foundations are the set of facts that decide whether a system should exist, what shape the system should take, and how honestly the limits get stated. Every guide in this repository stands on the ground covered here.

Reading the announcements

Foundations also supply a filter for the weekly flood of releases. When a new model appears, four questions cut through the launch language. How large is the context, and does the task actually need that much material held at once? What does generation cost in time, because decoding choices decide whether a system feels instant or sluggish? Where can the model run: rented cloud, private infrastructure under open weights, or a desk machine that keeps sensitive material at home? And what evidence accompanies the claims: a measured deployment, or a benchmark chart with no workload attached? A release that answers those four questions plainly deserves attention. A release that answers none of them is marketing with a parameter count. The ground does not change when the headlines do, and teams anchored in the ground evaluate each wave in hours instead of reorganising around every announcement.