Domain-Specific Encoding
The CAD File Is a Pidgin Too
Configurations, assemblies, and the information density wars
In post one, I showed how shop floor language compresses knowledge. In post two, I argued codebases develop the same pidgin dynamics. Now I want to bring it home to where I actually work: CAD systems, engineering drawings, and the daily decisions about how to structure information.
This is where the compression problem gets visceral. Get it wrong and parts don't fit, drawings confuse, and production grinds to a halt.
The Configuration Question
Here's a debate I've had a hundred times:
Should this be one part file with multiple configurations, or separate part files?
On the surface, it's a question about file management. But underneath, it's the same compression problem we've been circling.
Configurations are high-density encoding. One file contains many variants — different sizes, materials, mounting options. Changes propagate automatically. The file count stays low. It's elegant.
Separate files are low-density, explicit. Each variant lives independently. Relationships are documented rather than implicit. More files, more redundancy, but less mystery.
The textbook answer is "use configurations for variations of the same part." But that just pushes the question back: what counts as "the same part"?
The Car Door Problem, Redux
I keep coming back to this thought experiment:
Ask ten people to picture a car door. They'll all picture something different, but recognizably a door. Now push on the edges: Is a Lamborghini scissor door a car door? A Tesla falcon wing? A pickup tailgate? The sliding door on a minivan?
At some point you stop debating doors and start debating the boundary of the concept.
This happens constantly in CAD work. Is a motor with a different shaft length "the same motor"? What about a different mounting pattern? Different voltage? At what point does a "configuration" become a lie — a claim of sameness that obscures meaningful difference?
The answer isn't in the geometry. It's in how people think about the parts and whether they share that thinking.
When Compression Fails
I've watched configuration-based systems fail in specific, predictable ways:
The nested configuration 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 literally watched team members stare at these files in confusion. They know something's wrong. They don't know which of the seventeen interdependent parameters to change. So they work around it — export a static copy, modify that, break the link. The compression becomes a wall.
The boundary drift. A configuration family starts clean: three sizes of the same bracket. Then someone adds a variant with a different hole pattern. Then another with a mounting tab. Then one that's actually a completely different part but "it was easier to just add a config."
Now the file name is a lie. "Bracket_Standard" contains twelve things, four of which aren't brackets and two of which aren't standard. The compression has been corrupted by convenience.
The tribal knowledge dependency. "Oh, you need to use Config 7 for that customer, but make sure you 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
Here's a framing I've found useful:
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, top-down. Call it the arborescent structure: a tree with clear roots, branches, and leaves.
The actual system — what the shop floor does. Workarounds, adaptations, tribal knowledge, parts that fit even though the drawing says they shouldn't. Emergent, networked, improvised. Call it the rhizomatic structure: a tangle with no clear hierarchy.
The interesting work happens at the boundary between these systems. The drawing says one thing. Reality says another. Someone has to reconcile them.
CAD configuration choices encode assumptions about where that boundary falls. A configuration-heavy approach assumes the ideal system dominates — variants are predictable, controlled, top-down. A file-per-variant approach acknowledges the rhizomatic reality — things diverge, evolve independently, need explicit tracking.
Neither is wrong. The question is which assumption matches your actual situation.
Information Density and Team Cognition
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 will destroy another. The difference isn't technical — it's cognitive.
Some teams have deep shared context. They've worked together for years. They finish each other's sentences. They can handle dense, implicit encodings because they share the codebook. For them, a parametric model with complex configurations is efficient.
Other teams are looser. Higher turnover. Mixed experience levels. Cross-functional collaboration. They need explicit, redundant, low-compression structures. Separate files with clear names. Relationships documented rather than implied.
I've seen managers try to impose "best practices" from one team onto another and watch it fail. The practice wasn't wrong. The codebook didn't transfer.
This is why the "were the wing plates true" question lands differently depending on who's asking. The words compress more or less information depending on shared context. CAD structures work the same way.
Drawing Boundaries Deliberately
Some principles I try to apply:
Compress what's stable. Explicit what's volatile. If a dimension varies frequently, don't bury it in a configuration table. Bring it to the surface. Compression works for patterns that repeat; explicitness works for things that change.
Match the structure to the audience. Who will use this file? Just me? My immediate team? The shop floor? An outside vendor? Each audience has a different codebook. The further the file travels, the more explicit it should be.
Name the concept, not just the file. A file called "Motor_Assembly_Config_7" encodes almost nothing. A file called "Drive_Motor_24V_ShortShaft_FlangeMountB" expands the compression. It costs bytes but saves confusion.
Watch for boundary disputes. When people argue about whether something should be a configuration or a separate file, they're really arguing about conceptual boundaries. That's valuable information. Pay attention to it. The disagreement itself tells you the compression scheme isn't shared.
Document the codebook. This is the hardest one. What do your configuration names mean? What assumptions are baked in? What incantations are required? Writing this down feels tedious, but it's the only way compression survives team changes.
The Meta-Question
Here's what I keep circling back to:
We put enormous effort into version-controlling geometry. Revisions, approval workflows, 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 are just as important. Maybe more. A drawing with the wrong conceptual boundary causes more problems than a drawing with a wrong dimension. The dimension error gets caught. The boundary error propagates invisibly until it becomes everyone's problem.
Maybe that's what design documentation should really 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 — anti-fragile information systems and the meta-skill of adaptive density.