F4 (Tradeoffs) is the primary resolution mechanism. Every technical disagreement that cannot be resolved by factual analysis is a disagreement about AT1 through AT10. The resolution process has four steps: name the tradeoff both parties are implicitly optimising for; determine whether the disagreement is about this specific decision or about a general preference; check whether the context — scale, team capability, operational environment — makes one tradeoff preference more appropriate; make the decision explicit with the tradeoff named.
T12 (Tradeoffs) is the thread that runs through every technical disagreement. The engineer who has internalised T12 sees every disagreement as a negotiation about which costs are acceptable, not as a dispute about correctness. This reframe changes the emotional texture of the disagreement — from “you are wrong” to “you prefer different costs than I prefer, and we need to decide which preference is right for this context.”
F7 (Communication) determines how the resolution is communicated once the decision is made. The decision must be communicated differently to engineers who disagree with it (technical tradeoff and context), to product managers who need to plan around it (constraint and consequence), and to future engineers who will maintain the system (ADR with named tradeoff and reversal conditions).
F8 (Vocabulary) is the tool that makes the tradeoff naming precise. When both engineers in the auth service disagreement can say “this is a choice between AT9 and AT6 — correctness of session state versus operational simplicity,” the disagreement is resolved in a common language that does not require re-explaining the technical details every time the decision is revisited.