The expensive mistakes in hardware development are not the ones you know about when you make them. They are the ones that travel silently from one layer to another and surface three weeks later in a form that is expensive to unwind. A mechanical dimension changes. The firmware written against the old dimension keeps running. The discrepancy shows up at integration when both layers are substantially complete.
This is not a communication failure. It is a decision architecture failure. The process did not have a mechanism to surface the implications of a mechanical change for the firmware team before the firmware was finished.
Three Layers, Three Revision Costs
Every full-stack hardware build involves at least three revision regimes with very different costs. Mechanical revisions are expensive. A PCB respin costs real money and real time. A firmware update costs almost nothing. A decision process that does not account for these differences will consistently underestimate the cost of mechanical and electrical decisions.
The process needs to encode these asymmetries. Decisions that affect mechanical geometry should require more deliberation and more cross-layer review. The process should make this asymmetry explicit, not leave it to individual judgment.
Cross-Layer Dependency Mapping
Before any decision is made, I map its cross-layer dependencies. A motor selection decision lives in the mechanical and electrical layers. It also affects the firmware, because the motor driver protocol, the PWM frequency and the feedback signal format all follow from the motor choice. It affects the power layer, because the current draw profile determines the power rail design.
The dependency map makes the implications visible before the decision is committed. A short document listing which layers are affected and what they need to know. The discipline is doing this for every significant decision, before implementation, not in the retrospective when the system fails to integrate.
Which layers does this decision constrain? Who needs to know before the decision is committed? The answer to the second question is the review list. If those people have not been consulted, the decision is not ready to commit.
Decision Records and Version Control
A decision that is not recorded did not happen in any useful sense. Teams change. Memory fades. The reasoning that made a decision obvious in week three is invisible to the person debugging the consequence in week sixteen.
The format does not need to be elaborate. The decision, the options considered, the reasoning for the choice, and the constraints it creates for other layers. Four sections. Short. Linked to the relevant schematic or CAD revision. Version controlled alongside the code. Mini-PLM was built to make this tractable: connecting the decision to the specific file revisions it was based on, and to the requirements it was responding to.
Stage Gates as Decision Points
The IIL methodology structures development around stage gates that are explicitly decision points, not just review milestones. At each gate the question is: are all four layers still pointing at the same system? If they are not, the gate does not pass.
This requires that the gate review actually examines cross-layer consistency, not just per-layer progress. A team can be making excellent progress in every layer independently while moving toward an integration problem that will cost two months to untangle. The gate asks the uncomfortable questions before they become expensive.