Architecture review often spends scarce attention on the decisions that are easiest to discuss.

A team may debate a local library, naming rule, or implementation detail for days. In the same week, a shared data contract, platform boundary, identity model, or provider dependency can be approved in one meeting.

The difference is rarely explained by the cost of being wrong. It is usually explained by who attended, how visible the choice felt, or how familiar the argument was.

That is an expensive way to allocate decision effort.

For a CTO or engineering leader, the useful test is how difficult the choice will be to reverse after adoption and how much of the system will inherit the consequence.

Review the commitment, not the topic

Almost any implementation can be replaced in theory. The practical question is what reversal requires after consumers, data, operating procedures, contracts, and incentives form around it.

Ask what would have to move:

  • consumer code, integrations, or deployment paths;
  • historical data or state;
  • security, regulatory, or contractual controls;
  • on-call procedures and operational knowledge;
  • team responsibilities, skills, or funding; and
  • several roadmaps that cannot change independently.

Then inspect the blast radius. Count more than components. Include customer exposure, critical business decisions, security or safety consequences, dependency concentration, affected teams, and the time required to detect failure.

A change can be technically small and still have a broad consequence. A decision can live in one component while every product or customer depends on it.

Match the operating mode to the quadrant

The point of classification is to change how the decision is made and introduced.

Reversible and contained

Experiment quickly. Set a learning question, a direct owner, and a timebox. A working test may produce better evidence than another architecture meeting.

Reversible and broad

Constrain rollout and observe. Use staged exposure, leading signals, stop conditions, and a tested rollback. The technology may be replaceable, but harm can spread before rollback begins.

Durable and contained

Document the commitment. Record the reason, owner, expected life, and plausible replacement path. A local decision does not need organization-wide governance, but it should not be described as temporary when the operating model will make it durable.

Durable and broad

Invest disproportionate decision effort. Compare credible alternatives, test the boundary before the implementation, reduce the first rollout surface, preserve coexistence where possible, and make the exit owner explicit.

This is where weak decisions create synchronized migrations, permanent coordination work, customer exposure, and long periods in which the organization knows a choice is wrong but cannot change it safely.

Do not turn every decision into a constitutional matter

The framework fails if every team labels its choice irreversible and asks for executive attention.

Require concrete evidence. What data cannot move? Which consumers cannot migrate independently? What operating habit will become difficult to change? Who inherits the consequence? How long would detection take? Which part of the commitment cannot be isolated?

If those answers are vague, prefer a bounded experiment and a review date.

The classification can also change. A local experiment may become a shared dependency after adoption. A durable choice may become easier to reverse after a stable boundary, migration tool, or coexistence path is introduced.

Review effort should follow the current commitment, not the original label.

A better architecture-review queue

Before scheduling the next review, write down:

  1. the specific decision;
  2. the assets, consumers, teams, or customers that inherit it;
  3. the concrete work required to reverse it after adoption;
  4. the time and signals needed to detect a bad outcome;
  5. the smallest rollout that can test the important assumption; and
  6. the owner of the exit path.

Use those answers to choose the operating mode and the amount of review.

The goal is not more governance. It is to spend decision energy where a mistake would remove valuable options, spread broadly, and remain expensive long after the meeting ends.

Reversibility and Blast Radius is Gevorg's conceptual decision aid. It does not predict a fixed migration time, loss, or outcome and does not describe a named employer, customer, advisory engagement, or confidential architecture.