Domain-Specific Encoding
Wing Plates and Head Frames: How Shop Floor Language Encodes Centuries of Knowledge
On the compression algorithms hiding in plain sight
Last week, I overheard a question on the shop floor:
"Were the wing plates true before he bolted down the head frame?"
Eleven words. To an outsider, it's nearly meaningless — something about plates, something about bolts. But to the people in that conversation, this sentence unpacked into:
- A specific structural assembly on a machine we've built hundreds of times
- The sequence of operations required to assemble it correctly
- A known failure mode where skipping a step causes downstream problems
- An implicit accusation that someone might have cut corners
- A reference to at least three different engineering drawings
If you tried to write out everything encoded in that question, you'd fill pages. Maybe a chapter.
This isn't jargon in the pejorative sense — insider language used to gatekeep or obscure. It's something more interesting: a naturally evolved compression algorithm, developed over years of repeated practice, that allows experts to communicate at extraordinarily high bandwidth.
The Pidgin of Practice
Every workplace develops its own dialect. Not a foreign language, but a pidgin — repurposed English words serving as shorthand for patterns encountered over and over again, across projects, machines, customers, and years.
Consider another phrase I wrote down:
"Let me know what for rod they used to fill at the bottom edge of the doghouse side panels."
"Doghouse" isn't in any engineering specification. It's what we call a particular enclosure shape because, well, it looks like a doghouse. Everyone knows. The term probably predates anyone currently working here. It encodes not just a geometry but a whole family of related parts, common problems, typical weld sequences, and customer expectations.
This is language doing real work. The cognitive load of saying "the rectangular enclosure with the peaked roof profile that we use for the Model 7400 series control housings" every time would be crushing. So the language compresses.
Compression Has Rules
What makes a term stick? Not every shorthand survives. I've noticed a few patterns:
Frequency matters. Terms emerge for things you encounter constantly. Nobody invents jargon for a one-off. The compression only pays off if you amortize the learning cost across many uses.
The boundary has to be stable. "Doghouse" works because everyone agrees on what it means. When conceptual boundaries get fuzzy — when people start arguing whether something counts as a doghouse or not — the compression breaks down. You have to fall back to explicit description.
It has to survive transmission. New hires learn the pidgin through exposure. If a term is too arbitrary, too hard to remember, or too easy to confuse with something else, it dies. The terms that survive are the ones that pass through the bottleneck of human memory and social learning.
This is natural selection operating on language, optimizing for information density within a specific environment.
The Car Door Problem
Here's a thought experiment I've been mulling over:
Ask ten people to draw a "car door." They'll all draw something different — two-door coupe, four-door sedan, maybe a minivan slider. But they're all recognizably car doors.
Now ask: Is a Lamborghini scissor door a car door? Most would say yes, with some hesitation. What about the weird half-door on a Mazda RX-8? A pickup truck tailgate? The falcon-wing doors on a Tesla Model X?
At some point, you stop debating car doors and start debating the boundary of the concept. Where do you draw the line around "door"?
This isn't philosophical navel-gazing. It's a practical problem I deal with constantly in CAD work. When do two parts count as "the same part with different configurations" versus "two different parts"? When does a family of assemblies deserve a single model with variants versus separate files?
These questions are really about information compression. A configuration-based approach is higher density — one file encodes many variants. But it only works if the conceptual boundary is stable and shared. When team members disagree about what counts as "the same part," the compression fails catastrophically. You get confusion, errors, rework.
The most elegant compression scheme is useless if the people using it can't reliably decompress.
The Decompression Problem
This is where things get interesting for anyone thinking about knowledge management, training, or organizational resilience.
Shop floor pidgins are incredibly efficient — but they're also fragile. The compression only works when:
- Both parties share the codebook
- The codebook is accurate and up-to-date
- There's enough context to disambiguate
When an expert retires, they take part of the codebook with them. When teams split, the dialect forks. When practices change but the language doesn't update, you get dangerous mismatches — people using the same words to mean different things.
I've watched new engineers struggle for months, not because the work is hard, but because they can't parse the pidgin. They hear "wing plates" and "head frames" and have no idea what's being communicated. The information is right there, in the air, but they lack the decompressor.
We don't think of onboarding as "teaching a compression scheme," but that's what it is.
What This Means
I don't have a grand unified theory here. But I've been thinking about a few implications:
Documentation is decompression. When we write things down formally, we're trading information density for accessibility. Good documentation isn't just "writing things down" — it's expanding compressed knowledge into a form that doesn't require the local codebook.
Some knowledge resists documentation. The hardest things to write down are exactly the things most compressed in the pidgin — the tacit, the embodied, the "everyone knows." This is why knowledge transfer is so hard. The most valuable stuff is the most compressed.
Compression is a design choice. When you're building systems — CAD libraries, databases, organizational structures — you're implicitly choosing a compression scheme. How much do you collapse into a single structure versus keep explicit and separate? The right answer depends on who needs to use it and what codebook they carry.
The fabricators asking about wing plates and head frames have solved an information problem that organizations spend millions trying to address with knowledge management software. They just did it the old-fashioned way: through years of shared practice, accumulated in language.
The question I keep coming back to: can we do this deliberately? Can we design compression schemes for knowledge, rather than just waiting for them to evolve? And if we can — should we?
This is the first post in a series on domain-specific encoding. Next: Your Codebase Is a Pidgin — how the same ideas apply to software.