An architecture review board sees designs on average nine weeks after the team started building. Its approval rate is 94% and by far the most common outcome is approved with comments. Leadership reads the approval rate as evidence that standards are well understood. Which explanation is correct?

What actually distinguishes these explanations

The value of a review is proportional to how much of the design is still reversible when it happens. That is the mechanism, and it is what the nine weeks tells you.

At week nine a team has a schema, a deployment, a dependency on another team's service and probably a demo. Those are not opinions any more; they are work. A board that asks for a different data model is asking for weeks to be discarded, and boards do not do that - not because they lack nerve, but because the cost is real and the board can see it too. So the outcome converges on the only thing available: approve, and attach comments.

A 94% approval rate with late reviews is a measure of sunk cost, not of compliance. The two explanations predict different things, which is what makes this testable. If teams genuinely arrived compliant, you would expect few comments. The stem says comments are the norm. High approval plus heavy comments is the signature of a board reviewing decisions it cannot change.

The consequence people miss

Formal authority does not fix it. Giving this board a hard veto changes the 94% by a point or two and converts the remaining cases into escalations, because the alternative - discarding nine weeks - is worse for the business than shipping a flawed design. Authority at the wrong moment produces exceptions, not compliance. This is the general shape: governance placed after commitment degrades into governance by exception, whatever the policy says.

The second-order effect is on the comments themselves. Advice nobody can act on gets written anyway, so the board produces a growing body of recorded concerns with no owner - which is later cited after an incident as evidence that the problem was known.

Why the other options fail

• "Standards are clear and teams arrive compliant." The explanation leadership has already adopted, and it is falsifiable from the data in the stem: compliant designs do not generate comments as their most common outcome. If this were true you would also see a short review - a compliant design is quick to confirm - rather than a process that waits nine weeks.
• "The board lacks depth and needs more senior members." A real problem in some boards, and it predicts the opposite symptom: shallow comments, missed risks, designs approved that should not have been. Here the comments are plentiful. Adding seniority to a late review produces better advice that arrives just as late.
• "Make the comments binding actions." The most tempting answer because it sounds like accountability. It converts a soft cost into a hard one at the worst moment and will be waived under delivery pressure, which teaches everyone that the board's output is negotiable. Binding outcomes require early review; the sequence matters more than the force.

What to change

Move the trigger, not the authority. Review at the point where the expensive decisions are being made and are still cheap to change - a one-page intent with the two or three choices that bind other teams, typically in the first week or two. Define the trigger by consequence, published in advance, so teams know when to come. Then the board has something it can genuinely influence, and the approval rate becomes meaningful because rejection is survivable.

Measure review lead time from the first commit, not queue length. Nine weeks is the number to fix.

When this is the wrong answer

When the board exists for assurance rather than improvement. A regulated change needing a documented pre-production sign-off is legitimately reviewed late, because its job is to attest that what was built matches what was approved. Judging that board on whether it changed the design is judging it against someone else's purpose - but then its approval rate is a control-effectiveness measure and should not be reported as evidence that architecture standards are understood.