Wing Plates and Head Frames
Domain-Specific Encoding
Wing Plates and Head Frames
Last week, I overheard this on the shop floor:
"Were the wing plates true before he bolted down the head frame?"
Eleven words. To you, probably meaningless. To the two guys having this conversation, that sentence unpacked into:
- A specific structural assembly on a machine we've built hundreds of times
- The correct sequence of operations to assemble it
- A known failure mode when you skip a step
- An implicit accusation that someone cut corners
- At least three engineering drawings
If you wrote out everything encoded in that question, you'd fill a chapter. They said it in the time it takes to sip coffee.
This isn't jargon in the pejorative sense. It's a compression algorithm, evolved over years of repetition, that lets experts communicate at bandwidth that would make a fiber optic cable jealous.
The Pidgin
Every workplace develops this. Not a foreign language — a pidgin. English words repurposed as shorthand for patterns repeated across years, machines, customers, and mistakes.
Another one 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 on any drawing. It's what we call a particular enclosure shape because it looks like a doghouse. The term probably predates anyone here. It encodes not just a geometry but a whole family of parts, common weld problems, and customer expectations.
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. Automatically. Nobody designed this. It just happened.
What Makes a Term Stick
Not every shorthand survives. The ones that do follow rules:
Frequency. Nobody invents jargon for a one-off. The compression only pays for itself if you amortize the learning cost across hundreds of uses.
Stable boundaries. "Doghouse" works because everyone agrees what it means. The moment people start arguing about whether something counts as a doghouse, the compression breaks. You fall back to pointing at drawings.
Survivable transmission. New hires learn the pidgin through exposure. If a term is too arbitrary or too easy to confuse, it dies. Natural selection, operating on language.
The Car Door Problem
Ask ten people to draw a car door. They'll all draw something different but recognizably a door. Now push: Is a Lamborghini scissor door a car door? A Tesla falcon wing? A pickup tailgate?
At some point you stop debating doors and start debating the boundary of the concept.
This isn't philosophy. I deal with this daily in CAD. When do two parts count as "the same part with different configurations" versus "two different parts"? When does a family of assemblies deserve one model or separate files?
These are compression decisions. A configuration is high-density encoding — one file, many variants. It only works if the boundary is shared. When team members disagree about what counts as "the same part," the compression fails catastrophically. Confusion, errors, rework.
The most elegant compression scheme is useless if the people using it can't decompress it.
The Fragility
Shop floor pidgins are incredibly efficient. They're also fragile. The compression only works when both parties share the codebook, the codebook is current, and there's enough context to disambiguate.
When an expert retires, part of the codebook leaves with them. When teams split, the dialect forks. When practices change but language doesn't, you get people using the same words to mean different things. That's where the real damage happens — not from misunderstanding, but from the illusion of understanding.
I've watched new engineers struggle for months. Not because the work is hard. Because they can't parse the pidgin. The information is right there, in the air, and they can't hear it.
We don't think of onboarding as "teaching a compression scheme." But that's exactly what it is.
So What
The fabricators asking about wing plates and head frames solved a knowledge management problem that enterprises spend millions on. They just did it through years of shared practice, accumulated in language, transmitted by proximity.
The question I keep coming back to: can we do this deliberately? Can we design compression schemes instead of waiting for them to evolve?
And if we can — should we? Or does the act of designing it kill the thing that makes it work?