Reversibility
The property of a decision that determines how much analysis it deserves, since a cheaply reversible choice can be tested rather than debated.
The most useful first question about any architectural decision is "how expensive is it to undo?", because the answer determines the process, not the topic.
Reversible decisions — a library choice, an internal API shape, a caching layer, a deployment configuration — should be made quickly by the people closest to the work, and revised when evidence arrives. Extended analysis of a decision you can change next month is a waste of the most expensive resource in the room.
Irreversible or expensive decisions — a data model that will hold years of records, a partitioning key, a public API contract, a vendor commitment, a programming language, a regional topology — warrant real analysis, prototyping and a written record. These are the small number of decisions architecture should spend its attention on.
The consequence for how architects work: spend effort converting decisions from the second category to the first. An adapter around an external dependency, a feature flag, an interface that admits a second implementation, a migration path designed alongside the schema — each reduces the cost of being wrong, which is more valuable than increasing the chance of being right.
And when a decision is genuinely irreversible, say so explicitly. Teams treat those differently once they know.