The item-code system behind modular manufacturing

Every modular project is described twice: once in the drawing and once in the words next to it. The drawing is usually excellent. The words are usually a mess — "tall unit, oak-ish, with the light" — and the mess is where money leaks out. A factory reads "the light" one way, the designer meant another, and the difference shows up as a re-make three weeks later.

The fix is not more careful prose. It is a code. IN65 gives every item on a keyplan a structured item code that encodes the four things that actually determine what gets built and what it costs: function, dimensions, material, and lighting.

Four axes, one unambiguous string

Each axis answers a question that a factory would otherwise have to ask on the phone. Function says what the unit is. Dimensions say how big. Material says what it is made of and finished in. Lighting says whether and how it is lit. Put together in a fixed order, they form a single string that means exactly one thing to everyone who reads it.

• Function — the unit type: base cabinet, tall unit, wall panel, island, wardrobe carcass.
• Dimensions — the governing width, height, and depth that drive material take-off.
• Material — the substrate and finish, tied back to a real catalog entry with a price.
• Lighting — none, integrated LED, sensor-triggered, or a named lighting spec.

Because the code is structured rather than free text, software can act on it. The catalog knows which materials are valid. The price engine reads the material and dimensions and returns a number. The factory reads the same code off the keyplan and builds without a single clarifying email.

Why this makes catalogs and pricing honest

A free-text spec cannot be priced automatically because software cannot trust it. "Oak-ish" is not a catalog entry. Once the material axis of an item code points at a real catalog row, pricing stops being a designer guessing and starts being a lookup — production tier, wholesale tier, or retail tier, with markup and tax applied consistently. The same discipline makes reporting real: you can total a project by function, by material, or by lighting spec because every item carries those attributes as data.

Ambiguity is the most expensive material in modular manufacturing. An item code is how you stop paying for it.

The hand-off that just works

The real test of an item-code system is the factory hand-off. When a work order arrives, every line is a code the factory already understands — no interpretation, no assumptions, no "did they mean the deep one?" The keyplan and the build order speak the same language, which means the thing that gets made is the thing that was designed. That is the quiet superpower behind modular manufacturing at scale: not a better drawing, but a shared code underneath it.