The unglamorous distance: design freeze to first article.

There's a moment in every hardware program when the interesting work appears to be done. The design is frozen, the prototype works, the renders are gorgeous. Teams celebrate, budgets relax, attention drifts to the launch. What follows is the least glamorous and most fatal stretch of the entire journey: turning a frozen design into units coming off a line, at rate, at cost, that match the thing everyone approved.

The gap nobody budgets

Between freeze and first article live a hundred small negotiations: supplier queries that each quietly modify your design, tooling reviews where draft angles and gate locations get "adjusted", material substitutions proposed on cost, assembly steps that turn out to need three hands. Handled passively, each one nudges the product away from what was designed. The sum of those nudges is the difference between the render and the disappointment in the carton.

What transition actually involves

Active production transition is a discipline with named artifacts: tooling reviews attended with the authority to say no; first-article inspection against real drawings with real tolerances, not "looks right"; golden samples signed so batch nine has a referee; assembly documentation the line can actually follow; and a controlled change process, because changes will come, and the question is whether they're decided or discovered. More of this record is going digital (inspection results captured against the CAD model rather than retyped into a spreadsheet, change requests tracked in a system the factory sees as well as you), which helps, provided someone with the authority to act still reads it.

Late drift is a choice

The most dangerous phrase in this phase is "while we're at it". Late improvements feel free because the design work seems finished; they are the most expensive changes in the program, invalidating tests, drawings and sometimes certifications. Discipline here isn't conservatism. It's the understanding that the product now exists in tool steel, and tool steel doesn't do iterations for free. Tools that can regenerate a part quickly make late changes feel cheaper still. The tool steel hasn't noticed.

The agent-native lens: the as-built record

When the buyer sends an assistant. The specification you publish at launch is often drafted around freeze, while the product that ships is whatever survived first article. A shopper skimming the page rarely checks. An assistant comparing your listing with the manual, the label and a reviewer's measurements can, and a mismatch in a dimension, a weight or a material is the kind of detail it may report back to the person it works for. So treat published product data as an output of the change process, not of the launch plan: generate it from the released revision, and make "update the public data" a step in every approved change, so the page and its schema.org markup describe the unit in the carton.

When the business runs on agents. This phase is mostly correspondence and comparison, which is work agents can carry. They can log every supplier query against the drawing revision it touches, flag the ones that alter a critical-to-function feature, compare first-article inspection data with the drawing's tolerances and list every feature out of band, and chase the factory for answers still open. The decisions stay with people. An agent can say what the drawing requires; it never answers "yes, that's fine" to a deviation. Every accepted change carries the name of the engineer who approved it and the reason, the golden sample is still signed by hand, and the tooling go-ahead is a person's call.

Who walks it onto the line

This is why our engineering practice scopes production transition as first-class work, not aftercare, and why the same team that made the design decisions walks them onto the line. The reasoning behind every tolerance travels with the person who set it. As agents take on more of the checking and chasing in this phase, that continuity counts for more: an agent can tell you a dimension moved, but only the person who set it knows whether the move is harmless. If your program is stalled in this exact gap, that's a common way engagements start; the Release loop exists for it.