F4 (Tradeoffs) is the primary framework. Every architectural decision is a choice between two named values — AT1 through AT10 — and any decision can be described by which of those values it prioritises. The value of this vocabulary is not that it adds precision to decisions already made. It is that it forces precision on decisions being made. Teams that use AT vocabulary name their choices before they build them, which means they can reason about whether the choice is right for the context.
F7 (Communication) explains why the same tradeoff needs different vocabulary for different audiences. An engineer reviewing a design decision needs the technical tradeoff: AT5 (Centralization vs Distribution) — we are centralising the auth service because distributed auth creates consistency surface area we cannot instrument. A product manager needs a constraint statement: this means all features that require authentication go through a single service; if that service has an outage, authentication is unavailable across all products. An executive needs a risk statement: the centralised architecture reduces complexity cost but creates a single availability dependency; mitigation is redundancy in the auth tier.
The decision is the same in all three cases. The vocabulary changes to match the audience’s decision-making surface. F7 is not translation — it is selecting the abstraction that makes the decision actionable for the person receiving it.
F8 (Vocabulary) enables F4 to be used at organisational scale. When AT5 means the same thing to every engineer in the organisation, a design document that names AT5 carries immediate shared meaning. The coordination cost of rebuilding shared understanding in every review drops to near zero. The value of F8 is not individual precision — it is organisational efficiency.