Two engineers argue for forty minutes about whether to use a message queue for the notification service. One insists the queue is necessary. The other insists it is over-engineering. Neither is wrong — they are each optimising for a different unnamed value. The engineer arguing for the queue is weighting resilience and decoupling. The engineer arguing against it is weighting simplicity and operational overhead. The argument cannot resolve because no one has named the tradeoff.
This pattern is not rare. It is the dominant form of technical disagreement in engineering organisations. The surface argument is about the solution. The underlying disagreement is about which costs are acceptable. Until someone names the tradeoff — until someone says “this is a choice between AT10 and AT6” — the argument proceeds as a debate about correctness when it is actually a debate about preference.
Architecture decisions have a vocabulary. Learning it does not make decisions easier, but it makes disagreements shorter and decisions more durable.