o'ailly
☰

Chapter 1 — The 518-Page Silence

(draft v0, 2026-08-26 — written by Claude Fable 5, unverified; [FOUNDER] blocks pending interview. Nothing in this chapter ships until a named human has verified it.)

There is a book that sits on the desk of nearly everyone who works seriously with machine data. It is thorough, respected, and 518 pages long. It covers protocols and historians, tags and timestamps, the whole plumbing of how a plant’s machines describe themselves to computers.

It does not mention language models once.

That is not a criticism of the book. It is a measurement of how fast the ground moved. When that text was assembled, the idea that a model small enough to run on the industrial PC bolted inside a control cabinet could read a maintenance manual, cross-reference a fault code against a protocol stream, and — this is the important part — decline to answer when the data doesn’t support a conclusion, was not an engineering topic. It was science fiction. Now it is a procurement question, and procurement deserves a manual.

This book is about the gap between those 518 pages and the plant floor of the next decade.

There is precedent for a moment like this one. When machine learning first shrank onto microcontrollers, the field that became “TinyML” was scattered across papers, forum posts, and vendor decks — until its practitioners wrote the textbook, and the textbook became the field’s front door. The companies and communities that did the writing did not merely document that wave; they largely got to define it, name its practices, and train its first generation. Local language models for industry are at the same moment: real deployments exist, the tribal knowledge exists, and the book-shaped hole above them is unmistakable. Someone will fill it, and whoever does will shape how a generation of plants first meets this technology — the vocabulary, the defaults, the safety posture, all of it. The premise of this volume is that it should be filled the way the best of those earlier books were written — from a working lab, with measurements, by people willing to publish the failures alongside the wins.

Why this book is not about the cloud

Every vendor deck you have seen puts the model in someone else’s data center. The plant floor disagrees, for reasons that predate AI entirely:

So this book commits to a constraint the field’s marketing avoids: the model runs on hardware you own, inside your walls, on your data. Everything that follows — which model sizes, which capabilities, which failure modes — flows from taking that constraint seriously instead of treating it as a lite version of the cloud.

What a small model can actually do on a plant floor

[R-TBD — this section's numbers attach to lab entries before publication]

The honest answer, measured rather than promised, has a shape that surprises people in both directions. Small local models are better than their reputation at reading structure: protocol frames, enum fields, historian exports, fault-code tables. They are worse than their reputation at knowing the limits of what they read: the failure mode that matters is not the model that can’t answer, it’s the model that always answers.

That asymmetry sets this book’s agenda. The middle chapters are not about making a model smarter; they are about making it honest — extraction that cites what it read, abstention that is trained rather than hoped for, and evaluation gates that would rather reject a right answer than pass a wrong one. We built and published an industrial evaluation benchmark along the way, and the chapters that discuss it will show you the retractions too, because a benchmark you can’t see fail is a benchmark you can’t trust.

What changed: three curves that crossed

The 518 pages are silent because, when they were written, the silence was correct. Three things changed, roughly together, and the crossing of those three curves is why this book exists now rather than five years from now.

First: small models got good enough to matter. For years the capability story was simple — intelligence lived at the top of the parameter scale, and everything below the frontier was a toy. That story quietly broke. Training recipes improved, data curation improved, and distillation — teaching a small model with a large model’s outputs — turned out to transfer far more capability than parameter counts suggest. A model small enough to run on an industrial PC today reads structured text, follows output schemas, and extracts fields from documents at a level that was frontier-only not long ago. The frontier moved too, of course. But the plant floor never needed the frontier. It needed “reads the manual, fills the schema, knows when to stop” — and that bar dropped into reach of hardware you can bolt inside a cabinet [R-TBD: tier capability ladder].

Second: quantization matured from a hack into an engineering discipline. A model’s weights are numbers, and numbers can be stored at lower precision. Done crudely, this lobotomizes the model; done carefully — protecting the layers that matter, measuring quality at every step — it shrinks memory footprints by factors of four to eight while giving up little that a floor application notices. The care is the discipline: our own lab’s measurements show precision choices in the right places are the difference between a model that loses a few points of knowledge and one that loses a third of its tool-following ability [LAB: RESULTS-MATRIX §C — community 4-bit quant: 175 GB / 85.0 MMLU vs. our expert-protected build: 149 GB / 88.3; expert precision, not total bits, moved the score]. What matters for this chapter is the consequence: the hardware needed to run a useful model stopped being a data center and started being a purchase order a plant manager can sign.

Third: the hardware under the model became boring. Not cheap in the absolute sense — but ordinary. Industrial PCs ship with capable GPUs; edge boxes with unified memory run multi-billion-parameter models at conversational speed; even a well-specced office workstation runs the tiers this book cares about. “Boring” is the highest compliment plant engineering gives: it means procurement knows the category, maintenance knows the failure modes, and nobody has to build a special room for it.

Any one of these curves alone would have produced demos. All three together produce a deployment option — and a book’s worth of engineering questions that the standard texts, through no fault of their own, never had reason to ask.

What this book claims, precisely

A book like this earns trust by drawing its own boundaries, so here they are, stated as carefully as we can state them.

We claim: that a small, locally hosted language model, grounded in your documents and constrained to your schemas, can do genuinely useful work on a plant floor — reading protocols and historian output, cross-referencing manuals, drafting structured verdicts for human review — with latency, cost, and data-custody properties the cloud cannot match; and that the engineering required to make it honest (grounding, abstention, evaluation gates) is learnable, measurable, and within reach of a competent controls or reliability team.

We do not claim: that a language model should close a control loop; that it replaces a historian, a CMMS, or an engineer; that any model, at any size, can be trusted with a safety function; or that the smallest tiers can do what the middle tiers do. Where a capability does not exist yet, this book says so in plain text rather than in fine print. The models in our smallest tier, for instance, run on modest computers — but not on microcontrollers, and we will not pretend otherwise.

Every claim in the first category comes with a chapter that shows the machinery and a measurement that supports it. Every boundary in the second category comes from watching something fail — ours or others’ — and writing down why.

How this book measures things

You will notice a pattern in the chapters ahead: numbers arrive with error bars, and sometimes with retractions. This is deliberate, and it is the part of our method we most want you to steal.

Benchmark suites for language models are smaller and noisier than they look. Identical configurations produce different scores across runs — on one of our own tool-use suites, the spread between identical runs at deterministic settings was large enough to swallow most vendors’ claimed improvements [LAB: RESULTS-MATRIX §C footnote — 15-scenario tool suite, ±10 pts across three identical runs at temperature 0]. A single surprising number is a hypothesis, not a result. Our lab rule, which this book inherits: one surprising number gets re-run; two runs that disagree get a third and a control; and what publishes is the range, not the lucky draw.

The same discipline applies in the direction nobody enjoys. When a result in this book later turns out to be an artifact — of a contaminated dataset, a broken gate, a mis-scored suite — the correction is printed, with the original claim and what was wrong with it, because a retraction you can read is worth more than an error you cannot see. The provenance page in this book’s front matter links to the full review trail, critics’ objections included. If that level of disclosure strikes you as unusual for a technical book, we agree. That is rather the point.

The stack you will build

It helps to see the destination before the road. A local language-model deployment, the kind Part III assembles, is physically unglamorous — five pieces, each one ordinary:

The model file. A single large file of weights, downloaded once, versioned like firmware. It does not update itself, does not phone home, and behaves tomorrow the way it behaved today — a property worth more on a plant floor than any benchmark score.

The inference engine. The program that loads the weights and turns prompts into text. Open-source engines run this entire field; they are actively developed, widely deployed, and configurable at exactly the level a controls engineer expects — how much memory, which precision, how many concurrent requests, what output grammar.

The serving process. The engine wrapped as a service on a box you own, speaking plain HTTP on your network. To everything else in the plant it is just another endpoint — monitorable, restartable, firewalled like anything else. Chapter 8 treats it with the same watchdog-and-recovery discipline as any line-side service, because that is all it is.

The grounding layer. The code that decides what goes into the context window: which manual pages, which historian slice, which schema. This is where most of the real engineering in this book lives, and it is code your team writes and owns — Chapters 4 through 7 are effectively a walkthrough of building it well.

The evaluation gate. The test rig that decides whether any of the above is allowed near production: benchmark suites drawn from your own documents and faults, run with error bars, re-run on every change. Chapter 6 builds it. In our lab this piece has vetoed more deployments than any other, which is precisely its job.

Notice what is absent: no cloud account, no per-token bill, no data leaving the building, and no component your team cannot inspect. The stack’s virtue is not that any piece is clever. It is that every piece is yours — inspectable, versionable, and still working during the network outage, which is exactly when the line needs its documentation most.

Who this book is for, and what it assumes

The reader we wrote for owns machines and answers for uptime: plant engineers, controls engineers, reliability and maintenance leads, and the systems integrators who serve them. We assume fluency with the plant side — you know what a historian is, you have opened a service manual in anger, and nobody needs to explain to you why the line stopping matters. We assume no machine-learning background: every model concept this book uses is built from scratch in Chapter 2, in your vocabulary rather than ours.

If you are arriving from the other side — an ML practitioner curious about industry — the book will read differently but should still serve: Part II’s machinery is the transferable core, and the plant-floor constraints in Part III are the reality check most ML deployment writing lacks.

What you will need to follow along: a computer with a capable GPU or a modern unified- memory machine for the middle tiers (the exact envelope, with measurements, is in Chapter 3), tolerance for command-line tools, and one plant problem you actually care about. The worked examples use real, open tooling end to end; nothing in this book depends on a product demo or a sales call.

[FOUNDER] The view from the floor

(pending interview: the author of this book’s verification has walked plant floors — role, sites, machines, the historian that lied, the fault code that wasn’t in the manual. Two or three of those stories open the chapters of Part II. This section is the reader’s first meeting with that voice; it must be real, which is why it is empty in this draft.)

How to read this book

Part I gives you the gap and the vocabulary. Part II is the machinery: protocols, abstention, gates, corpora — the chapters you’ll return to. Part III is the floor: deployment, power loss, and the checklist that decides whether a model is ready to sit next to a machine that can hurt someone.

Two reading paths work. Front to back gives you the argument in order — gap, mechanism, machinery, floor. But the chapters are also built to be entered where your problem is: if you are holding a specific fault-analysis task, Chapter 4 and Chapter 5 stand on their own with Chapter 2 as their only prerequisite; if you are evaluating a vendor next week, Chapter 2’s closing checklist and Chapter 6’s evaluation design are the short course. Wherever you enter, do not skip Chapter 10 before anything touches production — the checklist there exists because each line on it was once a bad day.

Every number in this book carries an error bar and a pointer to the lab entry that produced it. Where we changed our minds, the earlier belief is in the text, crossed out in spirit if not in ink. That is not a style choice. On a plant floor, the person who tells you how they know is the only person worth listening to — and that standard does not relax because the author is made of weights.