The CAD File Is a Pidgin Too
Domain-Specific Encoding
The CAD File Is a Pidgin Too
In post one, shop floor language compresses knowledge. In post two, codebases do the same thing. Now I want to bring it home — to CAD systems, engineering drawings, and the daily decisions about how to structure information where I actually work.
This is where the compression problem gets visceral. Get it wrong and parts don't fit, drawings confuse, and production stops.
The Configuration Question
A debate I've had a hundred times:
Should this be one part file with multiple configurations, or separate part files?
Sounds like file management. It's not. It's the same compression problem.
Configurations are high-density encoding. One file, many variants. Changes propagate automatically. File count stays low. Elegant. Dense. Dangerous.
Separate files are low-density. Each variant lives alone. Relationships documented, not implied. More redundancy, less mystery.
The textbook says "use configurations for variations of the same part." That just pushes the question: what counts as "the same part"?
The Car Door Problem, Again
Is a motor with a different shaft length "the same motor"? Different mounting pattern? Different voltage? At what point does a "configuration" become a lie — a claim of sameness that hides meaningful difference?
The answer isn't in the geometry. It's in how people think about the parts and whether they share that thinking. Two engineers can look at the same model and disagree about whether it's one thing or two. They're not wrong. They have different codebooks.
When It Fails
I've watched configuration-heavy systems fail in specific, predictable ways:
The nested trap. Someone builds a beautiful parametric model: configurations within configurations, driven by design tables, linked to external spreadsheets. Elegant. Powerful. And completely unmaintainable by anyone except its creator. I've watched team members stare at these files in confusion. They know something's wrong. They don't know which of seventeen interdependent parameters to touch. So they export a static copy, modify that, break the link. The compression becomes a wall.
Boundary drift. A config family starts clean: three sizes of the same bracket. Then someone adds a variant with a different hole pattern. Then a mounting tab. Then something that's actually a completely different part but "it was easier to add a config." Now "Bracket_Standard" contains twelve things, four of which aren't brackets and two of which aren't standard. The name is a lie. The compression has been corrupted by convenience.
Tribal knowledge dependency. "Oh, use Config 7 for that customer, but suppress Feature 23 first, and don't forget to update the linked drawing." This is shop floor pidgin leaking into CAD structure. The file only works if you know the incantations.
Two Systems, One Boundary
There are two information systems running in parallel in any manufacturing operation:
The ideal system — what engineering specifies. Drawings, BOMs, part numbers, revision control. Formal, hierarchical. A tree with clear roots and branches.
The actual system — what the shop floor does. Workarounds, adaptations, parts that fit even though the drawing says they shouldn't. Emergent, networked, improvised. A tangle with no hierarchy at all.
The interesting work happens at the boundary. The drawing says one thing. Reality says another. Someone reconciles them. Usually without updating the drawing.
CAD configuration choices encode assumptions about where that boundary falls. Configuration-heavy assumes the ideal dominates — variants are predictable, controlled. File-per-variant acknowledges reality — things diverge, evolve independently, need explicit tracking.
Neither is wrong. The question is which assumption matches your actual situation. And most people never ask.
The Team Is the Codec
Here's the principle I keep learning the hard way:
The optimal compression level is not a property of the geometry. It's a property of the team.
A configuration system that works beautifully for one team destroys another. The difference isn't technical. It's cognitive.
Teams with deep shared context — years together, finishing each other's sentences — can handle dense, implicit encodings. For them, a parametric model with complex configurations is efficient.
Teams with higher turnover, mixed experience, cross-functional collaboration — they need explicit, redundant, low-compression structures. Separate files. Clear names. Relationships documented rather than implied.
I've seen managers impose "best practices" from one context onto another and watched it fail. The practice wasn't wrong. The codebook didn't transfer.
The Thing We Don't Version-Control
We put enormous effort into version-controlling geometry. Revisions, approvals, change orders. But we barely version-control the conceptual structure — the decisions about what counts as one thing versus another, what gets compressed versus kept explicit, where the boundaries fall.
Those decisions matter more. A drawing with a wrong dimension gets caught. A drawing with a wrong conceptual boundary propagates invisibly until it becomes everyone's problem.
Maybe design documentation should capture not just what parts exist, but what concepts they encode. Not just the geometry, but the pidgin.
Previously: Wing Plates and Head Frames | Your Codebase Is a Pidgin Next: Knowing When Not to Compress