How should reversibility change how much analysis a decision receives, and how do you assess whether a decision is genuinely reversible?

The frame

Decisions differ enormously in the cost of being wrong, and analysis effort should be proportional to that cost rather than to the decision's apparent importance.

• Reversible decisions should be made quickly, by the people closest to the work, with a bias toward trying rather than debating. The cost of deliberation frequently exceeds the cost of being wrong, and the experiment produces better information than the argument would have.
• Irreversible decisions deserve genuine analysis, wider consultation, and explicit consideration of alternatives — and effort spent here is where architectural value is concentrated.

The failure modes are symmetric and both common: agonising over reversible decisions (which framework, which library, which internal structure) while making irreversible ones casually (a data model, a public contract, a vendor commitment, a security posture).

Assessing reversibility honestly

The question is not "could we change this?" but "what would it cost, in time and risk, to change it in eighteen months?"

Genuinely reversible: internal implementation, framework choices within a service, deployment topology, caching strategy, most tooling. Contained blast radius, no external dependents.

Genuinely irreversible, or nearly so:

• Data models, especially anything that discards information. What was never captured cannot be recovered, and this is the debt that cannot be repaid at any price.
• Public API contracts, which become permanent the moment someone integrates.
• Identifier schemes, which propagate into every consumer's data.
• Anything that establishes a security or privacy posture, where retrofitting means touching everything.
• Data location and residency, once the volume is large.
• Technology choices with deep operational coupling, where the migration cost grows with the data.
• Organisational structure, which is reversible on paper and expensive in practice.

The middle category matters most: decisions that are reversible now and become irreversible with scale or adoption. The useful question is when the window closes, because that is when the analysis is actually required — and it is frequently much earlier than people assume.

Making reversible decisions cheaply

• Try it. For a genuinely reversible choice, an experiment settles it faster and better than a debate.
• Set a review point rather than deciding permanently.
• Record the decision briefly, with its assumptions, so revisiting is informed rather than a restart.
• Delegate. A reversible decision escalated to an architect is slower and rarely better.

Preserving reversibility deliberately

The most valuable technique is to make an irreversible decision into a reversible one rather than to analyse it harder:

• A boundary around the irreversible component, so it can be replaced without touching everything.
• Additive-only evolution of contracts and schemas, since additions are reversible and removals are not.
• Capturing more information than currently needed, because storage is cheap and unrecorded information is gone forever.
• Proving a migration path exists before committing, rather than assuming one.

Deciding what to do is a small part of the work. Arranging matters so the decision can be changed is most of it.