A client calls with a project that’s six months late and the board still doesn’t work right. They want it fixed. The first useful thing an outside engineer can tell them isn’t a fix, it’s a diagnosis: is this an architecture failure or an implementation defect, because they require opposite responses and most stalled projects get the wrong one applied first.
Implementation defect: the approach is sound. Something was built wrong within that approach. A wrong resistor value, a missed setup-time constraint, a firmware race condition, a footprint that doesn’t match the actual part. Fixable by correcting the specific thing that’s wrong, without changing the underlying design decisions.
Architecture failure: the approach itself cannot meet the requirements, regardless of how carefully it’s implemented. The topology is wrong for the problem. The sensor doesn’t have enough signal-to-noise ratio at the required range no matter how clean the layout is. The MCU’s interrupt latency can’t hit the control loop’s timing budget no matter how tight the firmware is. Fixable only by changing the approach.
Why the Distinction Gets Missed
Teams default to treating everything as an implementation defect, because that’s the less threatening diagnosis. “We got the layout wrong” is a smaller admission than “we chose the wrong sensing method,” and it’s the diagnosis that doesn’t require telling stakeholders the last six months bought less than they thought.
So the pattern repeats: respin the board, the problem is still there in a slightly different form, respin again. Three respins in, the team has spent more than a redesign would have cost, and they’re no closer, because every respin was an implementation-defect fix applied to an architecture-failure problem.
The reverse mistake is rarer but real: throwing out a sound architecture because one implementation defect made it look broken. A single ground-loop issue can make a fundamentally correct analog front-end look like the wrong front-end entirely, if nobody isolates the actual failure mode before reacting to the symptom.
How to Tell Them Apart
Ask what happens at the margins, not at nominal conditions. An implementation defect usually fails consistently and predictably once you understand it: this specific input, this specific timing window, this specific temperature. An architecture failure tends to fail in a way that gets worse as you push toward your actual spec, because the approach was never going to reach that spec, and the failure symptom you’re seeing at your current test conditions is just the first place it showed up.
Compute the theoretical limit of the current approach before debugging the implementation. If a design needs 12-bit effective resolution and the front-end’s own noise floor, calculated from the datasheet under ideal implementation, caps out at 10 bits, no amount of layout debugging fixes that. This calculation takes an afternoon and it’s skipped constantly, because debugging the board in front of you feels more productive than doing math about the board’s ceiling.
Change one variable in isolation and see if the failure moves with it or stays put. If reducing clock speed, tightening a single tolerance, or swapping one component makes the symptom disappear, that’s evidence for implementation defect. If the symptom persists across every variation you can reasonably make within the current architecture, and only goes away when you change the fundamental approach, that’s architecture failure.
Ask whether the original design review considered and rejected the alternative approach, or never considered it at all. A design that evaluated three topologies and picked one for stated reasons is much less likely to be an architecture failure. A design where the first idea that worked on the bench became the design is a bigger risk, because that single decision was never pressure-tested against the actual requirements.
What Changes Once You Know
An implementation defect gets a patch: a value change, a firmware fix, a layout revision within the existing architecture. Budget and timeline impact is usually contained.
An architecture failure needs the harder conversation: the current PCB, and possibly the current firmware structure built around it, gets replaced rather than revised. This costs more up front than another respin, and it’s the only path that actually converges. Continuing to respin an architecture failure doesn’t just fail to fix the problem, it burns the budget that a proper redesign would have needed, which is the actual reason stalled projects run over by multiples rather than percentages.
The diagnosis takes days. Getting it wrong costs months. If a project has stalled and nobody’s separated “what’s broken” from “what’s fundamentally unworkable,” that’s the first thing to sort out, before committing to another round of anything.
If you’re staring at a design that isn’t working and can’t tell which failure you’re looking at, an independent review is built to answer exactly that question before you commit to a fix.