← VAF·SA Framework
When the Architecture Decision Record has been written, the concern formally documented, the deadline passed without resolution, and a direction to proceed has been issued, the appropriate response is not to accept the documentation layer as the final position. Treating a documented but unresolved concern as a closed matter protects the paper record while leaving the engagement exposed.
Escalation has three layers. Each one increases visibility. Each one makes ignoring the risk progressively harder. Use them in sequence. Do not skip to layer three — it signals panic. Move through them deliberately.
Encode the risk into the design
Mark the affected component as provisional in the architecture diagram. Label it explicitly: "Pending resolution of ADR-[NNN] — data sovereignty confirmation required." The risk is now visible in the design itself. It cannot be silently forgotten because it is in the artefact. Every review of the Architecture on a Page sees it. Every delivery team member working on that component sees it. The risk is not in a document nobody reads. It is in the thing everyone uses.
I have marked this component as provisional in the AoaP pending the data sovereignty decision. It will stay provisional until ADR-003 is closed. That status is visible to the delivery team and will appear in every design review.
Pull it to the governance body with consequences named
The Design Authority, Architecture Review Board, or equivalent — whatever governance layer exists. Frame it specifically: "We cannot close this design without a decision on X. The consequences of proceeding without it are Y. The decision belongs to Z. We need it by this date." This is not a complaint. It is a structured input to a governance function. The governance body now has a named decision in front of it. Ignoring it is a governance failure, not an architecture failure. That distinction matters when accountability is assigned later.
I am raising this to the Design Authority. The design cannot be closed without a decision on data sovereignty. The consequence of proceeding is potential breach of the data classification policy. The decision belongs to the CISO. I need it by Friday.
Make the decision visible in front of the right mix of people
Raise the open item in a session where the project manager, the security lead, the platform lead, and the vendor representative are all present simultaneously. Not to create conflict. To make the decision visible to all parties at once. Saying "ignore it" in that room is no longer a quiet management choice. It is a named position taken in front of every stakeholder who will be affected by the consequences. Most people will not take that position publicly. The social layer works because visibility changes behaviour.
Before we move to the next agenda item — Domain 02 on the heat map is still red. Everyone in this room is affected by the consequence if we proceed without closing it. I want to confirm in front of all of you: who is making the call to proceed, and are they aware of the policy implications?
When escalation has run its course and the decision is to proceed anyway, the appropriate response is a formal boundary statement. Not a resignation. Not a confrontation. A precise statement of what the design satisfies and what remains unconfirmed.
The Boundary Statement
State exactly what you can confirm the design satisfies. State exactly what you cannot confirm without the outstanding decision. Assign ownership of the unresolved risk explicitly. Put it in writing. Send it to all relevant parties before delivery begins.
I can confirm the solution architecture satisfies all technical requirements in scope, with one exception. Domain 02 — data sovereignty — remains open. Without written confirmation from the vendor that data remains within the jurisdiction, I cannot confirm the architecture satisfies the data classification policy. That risk is now owned by [name / role] as of today's date. This is documented in ADR-003.
The boundary statement does three things. It protects your professional position. It forces explicit ownership of the risk onto the party who made the decision to proceed. It creates the written record that resolves any future ambiguity about who knew what and when.
The boundary statement is not defeat. It is precision. You are not walking away from the engagement. You are being exact about what you can and cannot verify — and placing the unverified risk exactly where it belongs.
The framework defines the discipline required within each module. Without explicit time guidance, a predictable failure mode emerges: extended intelligence-gathering phases that accumulate information without converging on design. The time boundaries below are not aspirational targets. They are operational limits. These time ranges define operational limits, not aspirational targets. Work within these boundaries is progressing. Work that exceeds them has encountered a condition requiring formal identification and governance response.
Module 01
Orientation
5–10
Working days
E-stop: Day 14
Module 02
Intelligence
5–15
Working days
E-stop: Day 20
Module 03
Design
10–20
Working days
E-stop: Day 30
Module 04
Artefacts
3–7
Working days
E-stop: Day 10
Module 05
Communication
Continuous
All modules
E-stop: per concern
Total
Full Engagement
30–60
Working days
E-stop: Day 90
Complex Archetype 3 engagements — Institutional Paralysis — may require up to sixty working days for Modules 1–3 combined, due to the immersion requirement. That is not slow. That is the nature of the archetype. The E-stop is day ninety from engagement start to first artefact delivery. If artefacts are not in the client's hands by day ninety, the loop has broken somewhere.
The most expensive time in any engagement is not the hard problem. It is the re-litigated decision — decisions already made, documented, and agreed that are brought back to the table. The integration pattern that was agreed in week two and revisited in week six because a new stakeholder has questions. The data flow direction that was confirmed and then challenged by a vendor with a commercial interest in the challenge.
Pattern locking is the discipline of declaring a decision closed and defending that closure. Not rigidly — new information that materially changes the decision reopens it through an ADR. But social pressure, repeat questioning, and stakeholder second-guessing do not reopen a locked pattern. The ADR holds it.
Lock Condition
When to lock a pattern
The pattern has been discussed in at least one workshop. The heat map cell is green. The ADR is written and accepted. The decision makers were in the room when the decision was made. Those four conditions met — the pattern is locked.
Challenge Response
When someone re-litigates a locked pattern
Point to the ADR. Name the date. Name who was in the room. State: "This was decided. If you have new information that materially changes the technical case, bring it and we will review. If you have a preference for a different approach, that is a different conversation." Then stop.
What Unlocks a Pattern
The only valid reasons to reopen
New technical information that could not have been known at the time of the decision. A change in regulatory or compliance obligation. A vendor change that materially affects the solution. A business requirement change confirmed at executive level. Not: a new person joining the project who was not briefed. Not: a vendor who prefers a different outcome.
The Time Cost
What re-litigation actually costs
One re-litigated decision in a complex engagement costs between two and five working days on average — workshop time, documentation time, stakeholder re-alignment time. Three re-litigated decisions is a full working fortnight. Pattern locking is not rigidity. It is time management.