Design in VAF·SA is not about producing the most detailed diagram. It is not about demonstrating the full depth of your technical knowledge. It is not about filling every box in a framework template.

Design is about producing the clearest possible picture of the solution — for the audience that needs to act on it — using the minimum tool necessary to achieve that clarity.

A component-level diagram in an executive room does not demonstrate depth. It demonstrates that the audience has not been considered. A context diagram that an executive sponsor and a senior technical practitioner can both read without explanation is the standard. That is design at the right level.

Every tool in the architect's stack has a purpose and a limit. The wrong instrument wastes time, introduces complexity, and signals to the room that the problem has not been properly characterised. The right instrument produces clarity.

The context-to-component structural approach is the primary design instrument in VAF·SA. It provides a shared vocabulary — Context, Container, Component, Code — that any audience can navigate once they understand which level they are looking at. The power is in the discipline: start at Context. Go deeper only when the audience and purpose require it.

Most architectural presentations fail because they start at the wrong level. Too detailed for the executive. Too abstract for the developer. context diagram solves this by making the level explicit and the zoom deliberate.

The heat map is the instrument that Module 2 populates and Module 3 uses to confirm that the design is complete. Every domain that the solution touches must be mapped. Every cell must have a status. A blank cell is not "to be confirmed" — it is an open risk sitting in the design unaddressed.

In the vendor obfuscation case study: the heat map was placed in front of the vendor. Every blank cell was named. Every unanswered question was documented. The vendor could not deflect a blank cell the way they could deflect an open question. The map made lying structurally difficult.

Every design decision in VAF·SA belongs to an altitude. Making the wrong decision at the wrong altitude — or letting the wrong audience make a decision that belongs at a different level — produces the failure modes the four archetypes describe. The three-altitude stack is the structural discipline that prevents that.

Every design begins with an honest picture of what exists. Not what the documentation says exists. Not what the vendor claims exists. What actually exists — confirmed through Module 1 immersion and Module 2 intelligence. From there, target state is designed. The gap between them is what gets delivered.

Security architecture in VAF·SA is not a review that happens after design is complete. It is a constraint that shapes every design decision from the first context diagram context box. security architecture practice provides the threat and risk lens. information security management and security control baseline provide the control framework. The heat map ensures no security domain is left unaddressed.

Integration architecture is where most solution designs introduce unnecessary complexity. The practitioner who defaults to event-driven architecture because it is modern, or point-to-point because it is fast, without asking which pattern the problem actually requires — produces a solution that delivers the wrong thing well.

Observability is not a monitoring tool configured after deployment. It is a design decision made before the first component is built. The solution architect is responsible for specifying what must be observable — not for implementing the observability stack. That distinction matters. Defining the requirement is architecture. Building the tooling is delivery.

Three pillars. All three required. None optional.

Every design is built on some information that has not been fully confirmed. That is unavoidable. What is not acceptable is leaving those assumptions unnamed. An unnamed assumption is an invisible risk — it does not appear on the heat map because it has not been tested, and it does not appear in an ADR because no decision has been formally made against it. It quietly shapes the design until the moment it proves false.

The assumption register names each assumption explicitly before the design is presented. It does not eliminate the assumption — in many engagements the information simply is not available yet. It makes the assumption visible, assigns it an owner, and defines what changes to the design if it turns out to be wrong.

The heat map identifies domain-level risks — gaps in security, data, compliance, vendor, and operations coverage. The architecture risk register tracks something different: the risks created by specific architectural decisions. Every significant design choice introduces uncertainty. Some of that uncertainty has consequences serious enough to document, track, and assign.

The distinction matters. A domain risk is a gap to be closed. A decision risk is a trade-off accepted. Both require governance. Neither replaces the other.

Four response strategies. Every risk in the register requires one of these four responses assigned before the register is presented:

The assumption register tracks what is being treated as true. The architecture risk register tracks what each design decision could cost. The technical debt register tracks something different: what the current state already owes. Every system that has been running in production carries deferred decisions, undocumented integrations, and compromised foundations that were accepted at some earlier point in exchange for speed or short-term convenience.

Technical debt is not a failure of the current engagement. It is the environment the solution must be designed within. Naming it explicitly before design begins prevents the most common failure mode in solution architecture — designing a target state that cannot be reached from the actual current state because nobody documented what stands between them.