An architecture description contains several views produced from different viewpoints. ISO/IEC 42010 asks you to record "correspondences", "correspondence rules", and architecture rationale. What are these, and what problem do they solve?

## The problem: many views, one system As soon as you have more than one view, you have a consistency problem. Each view is written by different people, at different times, for different stakeholders. They describe **one** system, so they must agree — but nothing in a pile of diagrams enforces that. Typical silent contradictions: - A functional element exists in the functional view but is allocated to no node in the deployment view (where does it run?). - The information view says a data store holds personal data; the deployment view puts that store in a region the compliance concern forbids. - The operational view describes a rolling upgrade that the concurrency view's shared-state design cannot survive. - An interface marked external in one model has no authentication mechanism recorded anywhere. Each of these is a real defect discovered late and expensively. Multi-view descriptions do not fail because a view is wrong; they fail because two views are individually plausible and jointly impossible. ## Correspondences A **correspondence** in ISO/IEC 42010 is an explicitly recorded relation between architecture description elements. It is deliberately general: it can link elements *within* one model, *between* models in one view, *between* views, or even between separate architecture descriptions (useful for a system-of-systems, or between an enterprise architecture and a system architecture). Common relation types include: - **allocation / realization** — functional element → node, logical entity → physical store, - **refinement** — a coarse element in an overview → its decomposition in a detailed model, - **composition / aggregation** — element is part of another, - **traceability** — decision → concern → stakeholder; requirement → element, - **consistency / equivalence** — the same real thing appearing under two names in two views. The practical payoff of naming them is that reviewers gain a checklist, and tooling gains something to verify. ## Correspondence rules A **correspondence rule** is a constraint that governs correspondences — a statement that must hold across views for the description to be well-formed. Examples worth actually adopting: - Every functional element appears on at least one deployment node. - Every node in the deployment view hosts at least one functional element (otherwise, why does it exist?). - Every data store in the information view has an owner, a classification, a retention rule, and a location. - Every externally reachable interface in the context view has a recorded authentication and authorization mechanism. - Every process/thread in the concurrency view is realized by some functional element. - Every element that a quality scenario names exists in some view. Rules can be checked by humans at review, or automatically when models are machine-readable (architecture description languages, structured YAML/JSON models, or code-level tools such as dependency and modularity checkers that enforce a documented module structure). The strongest form is generating a view from the same source of truth as the system itself, so the correspondence is true by construction rather than by inspection. ## Known inconsistencies — the honesty clause The standard explicitly asks that an architecture description **record known inconsistencies** among its views. This is unusual and important. Real projects have periods where views disagree — mid-migration, mid-refactor, or where two teams have not converged. The choice is not between consistent and inconsistent; it is between *known* and *unknown* inconsistency. Writing "the deployment view still shows the pre-migration single-region topology; multi-region is described in ADR-052 and will be reflected after cutover" converts a trap into a managed item with an owner. ## Architecture decisions and rationale Alongside consistency, the standard provides for capturing **architecture decisions** and **architecture rationale**: the reasoning for a choice, the **alternatives considered and rejected**, the assumptions, and traceability from decisions back to the **concerns** and **stakeholders** that motivated them. In practice this is what an architecture decision record (ADR) captures: context, decision, alternatives, consequences, status, and ideally a revisit trigger. Why it matters more than the diagrams: - **Structure is recoverable; reasoning is not.** In five years a competent engineer can read the code and reconstruct the module structure. Nobody can reconstruct why the team rejected the obvious-looking alternative, or which regulatory clause forced an awkward boundary. - **It prevents re-litigation.** Without recorded rationale, the same debate recurs every time the team composition changes. - **It prevents dangerous "cleanups".** An odd-looking indirection with no recorded reason gets removed by a well-meaning engineer; one with a recorded reason and a revisit trigger does not. - **It supports change.** A decision recorded with its *assumptions* can be re-evaluated when an assumption expires ("we chose single-region because no EU customers; we now have EU customers"). ## Trade-offs and edge cases - **Cost.** Exhaustive correspondence recording is expensive and rots like anything else. Adopt a handful of high-value rules — the ones whose violation causes real incidents — rather than a formal complete mapping. - **Formality spectrum.** Ranges from prose statements, to tables, to machine-checked model constraints in an architecture description language, to generation from a single source of truth. Pick the level the risk justifies; regulated or safety-critical contexts justify far more. - **Rationale bloat.** An ADR per trivial decision buries the important ones. Reserve them for decisions that are costly to reverse, cross team boundaries, or resolve a stakeholder conflict. - **Stale rationale.** ADRs should be **immutable with status transitions** (proposed → accepted → superseded by ADR-N) rather than edited in place; editing destroys the history that gives them value. - **Traceability overreach.** Full bidirectional traceability from every requirement to every element is a classic heavyweight-process failure; trace the *significant* decisions to the *prioritized* concerns and stop there. - **Beyond one system.** Correspondences across architecture descriptions are how a system architecture is kept aligned with an enterprise or product-line architecture — the same mechanism, one level up.