Reading the Room ended with a starting position.
Not a plan. Not a roadmap. A precise account of what was inherited — which failure mode is most active, which structural condition is most constraining, which domain has the highest decision pressure in the actual delivery environment this week. That starting position is the only basis on which the first intervention can be designed.
The first intervention is always the same in structure. One domain. One owner. One constraint built and held under pressure. Not because the organisation only has one problem. Because the decision system has to prove it can function before anyone will trust it with two.
This is the moment the implementation either establishes credibility or loses it. Not in a governance forum. In the delivery environment, on a Tuesday afternoon, when a question arrives and the domain owner produces a binding answer in forty-eight hours and the answer is recorded and the constraint holds. That moment — small, unremarkable to anyone not watching for it — is when the decision system becomes real.
Everything before it is preparation. Everything after it is expansion.
Why the First Domain Is an Architectural Choice and an Organisational One Simultaneously
Most practitioners treat domain selection as a technical question. Which domain is most bounded? Which has the clearest interfaces? Which has the least legacy complexity?
Those are relevant considerations. They are not the primary ones.
The first domain is also an organisational design choice. It names a single owner. It sets Decision Altitude for the first time in a functioning way. It builds the first Compliant Path — the delivery route that is coherent with architectural intent by construction, not by instruction. And it does all of this inside an organisation that has a specific Configuration Inheritance, specific political conditions, and a specific theory of what architecture is supposed to do.
The Theatre Inheritance and the Vacuum Inheritance do not start in the same domain. The Decay Inheritance starts somewhere different again.
In a Theatre Inheritance, the architecture function has been producing artefacts that describe what the organisation does. The first domain intervention has to produce something the artefact cannot — a binding answer to a delivery question, recorded, attributed, and enforced. The domain chosen is the one where a delivery question is live and unanswered. Not the most strategic domain. The one with an active question the current governance model cannot close.
In a Vacuum Inheritance, authority has never been designed. The first domain intervention is simpler in one sense — there is no competing structure to navigate. It is harder in another — every assumption about how decisions get made has to be built from zero. The domain chosen is the one with the most willing owner. Not the most qualified. The most willing to be named and to answer. Qualification can be developed. Willingness to hold the role under pressure cannot be installed after the fact.
In a Decay Inheritance, there is an existing structure that looks correct but has drifted from delivery reality. The first domain intervention is the most politically delicate. The existing domain owners believe they are functioning. The existing constraints believe they are current. The first domain chosen is the one where the gap between the documented structure and the delivery reality is most visible and most costly — where the evidence of Architectural Decay is strong enough that the intervention is welcomed rather than resisted.
The non-profit has a Theatre Inheritance with Decay underneath. The first domain is chosen at the intersection of both — where the Theatre has produced the most documentation and the Decay has produced the most drift. That intersection, in this organisation, is the data ownership layer inside the SAP upgrade programme.
The Single-Threaded Owner
The most important decision in the first domain is not which constraint to build first. It is who holds the domain.
One person. Named. Accountable for producing binding answers to domain-level decisions within forty-eight hours. Accountable for maintaining the Baseline Integrity of the domain record. Accountable for escalating cross-domain conflicts to the right Decision Altitude rather than absorbing them or deferring them.
Not a committee. Not a working group. Not a rotation. One person, at one point in time, who can be asked a question and who is structurally obligated to answer it.
This is where the Theatre Inheritance produces its first resistance. The Theatre Inheritance has committees. It has working groups. It has review boards. It has collective accountability, which is the structural condition that produces no accountability at all. Naming a single domain owner inside a Theatre Inheritance is a challenge to the existing governance model. It implies that the governance model, as currently designed, cannot produce a binding answer. It implies that collective decision-making has been producing collective deniability.
That implication is correct. The resistance it produces is real. The political architecture required to hold the single-threaded owner model against that resistance is the subject of The Political Architecture. What matters here is that the model is not compromised before that political work begins. A domain owner who reports to a committee has not been named. A domain owner whose decisions can be overridden by a forum without record is not an owner. The structure is either single-threaded or it is not.
The practitioner's first political act is naming the owner and holding the naming against the institutional instinct to dilute it.
Setting Decision Altitude for the First Time
Decision Altitude is the governance level at which a decision is made and owned, matched to the consequence it carries. Setting it correctly for the first time in a functioning way is the most technically precise act in the first domain.
The failure mode is Altitude Collapse — decisions resolved at the wrong governance level. Downward Altitude Collapse produces an Ownership Vacuum: decisions that carry cross-domain or enterprise consequences are being resolved at team level by people who do not have visibility of the full consequence. Upward Altitude Collapse produces Governance Drag: decisions that should be resolved at team or domain level are being escalated to enterprise or executive level, where they accumulate and slow everything beneath them.
Most Theatre Inheritances have upward Altitude Collapse as the dominant pattern. Every decision that touches more than one team goes to a steering group. The steering group meets fortnightly. The delivery team waits. The pragmatic call gets made without the steering group because the steering group is too slow to be relevant. The steering group approves the decision retroactively. The record shows approval. It does not show that the approval came three weeks after the decision was implemented.
Setting Decision Altitude correctly in the first domain means defining three things explicitly.
Which decisions stay at team level. These are decisions that are reversible within a sprint, affect a single team or service, and do not cross a domain boundary. The team owns them. The only obligation is that they are recorded in the decision log — not approved, recorded.
Which decisions belong at domain level. These are decisions that cross services within the domain, introduce a new pattern within existing constraints, or affect the domain boundary. The named domain owner answers within forty-eight hours. Deferral is not an option — deferral equals escalation. If the domain owner cannot answer within forty-eight hours, the decision escalates automatically to enterprise level and the reason for escalation is recorded.
Which decisions escalate beyond the domain. These cross domain boundaries, introduce new estate-wide patterns, conflict with existing constraints, or carry regulatory or security implications. These belong at enterprise level and are addressed in The Political Architecture.
The forty-eight hour threshold at domain level is not arbitrary. It is the boundary between a decision system and an advisory service. An advisory service produces recommendations when convenient. A decision system produces binding answers within a defined time. The difference is not the quality of the answer. It is the structural obligation to produce one.
Building the First Compliant Path
The Compliant Path is the delivery route that is already coherent with architectural intent by construction. Not chosen because it is the right thing to do. Defaulted to because it is the easiest thing to do.
This is the most misunderstood concept in constraint infrastructure. Practitioners hear "compliant path" and think enforcement — a rule that delivery teams must follow, a gate that stops the non-compliant option. Enforcement is the last resort of a constraint that has already lost. A constraint that has to be enforced at every decision point has failed as a structural condition. It is producing compliance theatre rather than compliant behaviour.
The Compliant Path works differently. It makes the architecturally coherent option structurally easier than the alternatives. Not mandated. Not enforced. Easier. The integration pattern that has been pre-approved, documented, and tested is faster to use than the pattern that requires a fresh architectural assessment. The cloud service that has been through the security review is faster to provision than the one that has not. The data model that has been through the domain review is faster to implement than the one that requires a new ownership conversation.
When the Compliant Path is correctly built, delivery teams do not choose compliance. They default to it. Because the compliant option is faster, cheaper, and lower risk than the alternative. The Internal Market Problem has been solved in the architecture's favour.
Building the first Compliant Path in the non-profit means identifying one delivery question the SAP upgrade programme needs answered regularly. Not all of them — one. The data ownership question is the right choice. Every integration the SAP programme builds touches data. Every data decision either has a named owner who can answer within forty-eight hours or it generates a delay while the programme figures out who to ask.
The first Compliant Path is the answer to that question, pre-built. The data domain owner is named. The data ownership model is documented at the level of precision the SAP programme needs — not a capability map, a decision surface. Which data domains exist. Who owns each one. What decisions can be made at domain level and what escalates. How to get an answer within forty-eight hours.
When the SAP programme has that, the data ownership question stops generating delay. The programme defaults to the domain owner. The domain owner answers. The answer is recorded. The Compliant Path holds.
The Tuesday Test — Run for the First Time
The Tuesday Test is the simplest possible diagnostic of whether the first element of the decision system is functioning. A Solution Architect, on a Tuesday afternoon, needs answers to four questions. Can they get structured answers within minutes?
Which domains does this touch? Who owns each one? Has this been done before and was it approved or an exception? What is the escalation path if there is a constraint conflict?
In Reading the Room, the Tuesday Test was run against the existing organisation and failed completely. The non-profit could not answer any of the four questions within minutes. The domain ownership was undocumented. The exception history did not exist as a visible record. The escalation path was a steering group that met fortnightly.
Run the Tuesday Test again after the first domain is established. Not against the full estate — against the first domain only. One domain. One owner. One constraint built and recorded.
The answer to question one — which domains does this touch — may still be incomplete for the full estate. Within the first domain, it is not. The boundary is documented. The ownership is named. The exception history, even if it only goes back ninety days, exists as a visible record. The escalation path from domain level is defined.
The Tuesday Test does not pass for the full estate after one domain is established. It passes for one domain. That is the point. The decision system is not built for the full estate on day one. It is built domain by domain, Compliant Path by Compliant Path, until the Tuesday Test passes everywhere.
The first domain is where the Tuesday Test passes for the first time. That moment is the proof of concept. Not in a presentation. Not in a governance report. In a delivery team getting a structured answer to a delivery question within forty-eight hours.
What the Non-Profit Builds First
The data ownership domain inside the SAP upgrade programme.
Not because data is the most strategic domain. Because it is the domain where the decision pressure is highest, the existing gap is most costly, and the first Compliant Path can be built and demonstrated within ninety days.
The domain owner is named. One person. The data architecture lead who has been in the organisation long enough to know the estate and is willing to hold the role. Not a committee. Not a shared responsibility. One person who will answer within forty-eight hours and whose answers are recorded in the decision log from day one.
Decision Altitude is set. Team-level data decisions — field mappings, local transformations, single-system extracts — stay at team level and are recorded. Domain-level data decisions — new integration patterns, cross-system data flows, ownership conflicts between two programme workstreams — go to the domain owner within forty-eight hours. Cross-domain decisions escalate.
The first Compliant Path is built. The data ownership model is documented at decision-surface precision. The SAP programme has a named owner to ask, a documented model to reference, and a forty-eight hour response guarantee. The non-compliant path — raising an undocumented data question to a steering group that meets fortnightly — is now slower and harder than the Compliant Path.
The Internal Market Problem is solved for one domain. The constraint holds not because someone enforces it. Because defaulting to it is faster than going around it.
The Tuesday Test passes for the data domain. For the first time in this organisation, a Solution Architect on a Tuesday afternoon can get a structured answer to a data ownership question within forty-eight hours.
That is not the full decision system. It is the proof that the decision system is possible. And in an organisation that spent a year producing a capability map that could not answer a single delivery question, proof is everything.