Chapter 8. Architecture Decision: S3
Settling sourcing, model, hosting, grounding, and authority boundary — and recording the decision so that everything downstream has something to compare against.
8.1 What S3 decides
S3 produces the Architecture Decision Record that G2 assesses and that the Control Plane later compares deployed reality against. Its scope is the architecture boundary, not the engineering interior (Chapter 1, §1.3).
Six decisions belong here.
Table 27. What S3 decides
| Decision | Recorded as | Downstream dependency |
|---|---|---|
| Sourcing | Build, fine-tune, retrieve, API, SaaS, or no AI | Determines governance weight (Chapter 4, §4.5) |
| Model or service | Named model family from the approved list, or an exception | Policy-as-code checks deployed model against this |
| Hosting pattern | Vendor API, private hosting, on-premises | Sovereignty and continuity implications |
| Grounding | Which governed data sources, if any, ground the system | Lineage record at S4; lineage drift detection later |
| Authority boundary | For agentic systems: tools, actions, limits | Agent Card; machine-readable boundary at G3 |
| Pattern conformance | Which reference pattern, unmodified, modified, or none | Determines whether the fast path at G2 is available |
8.2 The sourcing decision framework
S0 raised the sourcing question provisionally. S3 settles it. Twelve considerations bear on the choice; not all matter for every case, but each should be consciously dismissed, not overlooked.
Table 28. The sourcing decision framework
| Consideration | Pushes toward build or fine-tune | Pushes toward API or SaaS |
|---|---|---|
| Differentiation | The capability is a durable competitive advantage | The capability is table stakes |
| Domain specificity | Domain language or format is genuinely distinctive | General language suffices |
| Data sensitivity | Data cannot leave the enterprise boundary | Data is low-sensitivity or can be redacted |
| Data sovereignty | Jurisdictional restrictions on processing location | No location constraint |
| Intellectual property | Outputs or training data create IP that must be retained | No IP consequence |
| Explainability need | High-consequence decisions requiring defensible reasoning | Explainability not material |
| Model control | Behavior must be stable and version-pinned | Vendor-managed updates acceptable |
| Latency | Strict latency requirements favor local inference | Network latency tolerable |
| Cost profile | High sustained volume amortizes fixed cost | Variable, low, or unpredictable volume |
| Vendor dependency | Concentration risk is unacceptable | Dependency acceptable and diversifiable |
| Compliance evidence | You must be able to produce evidence a vendor will not supply | Vendor attestations suffice |
| Skills | You have and can retain the capability | You cannot staff it durably |
Two observations from the framework’s design worth carrying into the conversation. First, the sourcing decision is the architecture decision for externally consumed models; the vendor and data-flow choice is where nearly all the governable content sits. Second, fine-tuning commits you to treating every subsequent training-data change as a major change with full revalidation. That recurring cost is frequently omitted from the business case.
Sourcing and the “no AI” option
The no-AI option remains live at S3, not just S0. Architecture work sometimes reveals that the actual requirement is a deterministic rule with good data behind it. Recording that outcome as a valid S3 decision, not as a failed initiative, makes it available as a real choice.
8.3 Reference patterns and the fast path
Ten pre-approved patterns exist (Chapter 35). Their governance function is specific: a Tier 1–2 system built from an unmodified pattern may use the largely automated G2 path. That is the framework’s main genuine burden reduction, and it only works if pattern conformance is assessed honestly.
Three conformance outcomes are possible, and the distinction matters.
Conformant. The system uses the pattern as published, with only the configuration the pattern anticipates. Fast path available at Tier 1–2.
Modified. The system follows the pattern’s structure but changes something material — an additional data path, a different trust boundary, an extra integration. Fast path not available. The modification is documented in the ADR and reviewed on its merits.
Novel. No pattern applies. Full review regardless of tier, and a candidate for promotion into the pattern library if it proves reusable (Chapter 35, §35.3).
[Practice recommendation] Watch for pattern-conformance inflation, where teams describe a materially modified architecture as conformant to obtain the fast path. The counter is not suspicion but specificity: patterns should be published with an explicit list of what may vary and what may not. A pattern that says only “use a gateway” cannot be assessed for conformance and will be claimed for everything.
8.4 Writing an ADR that survives contact with the Control Plane
An architecture decision record in IRGF carries a load that a conventional ADR does not: it is the approved-state reference the Control Plane compares deployed reality against. Fields that cannot be compared produce no signal.
Table 29. Writing an ADR that survives contact with the Control Plane
| Field | Requirement | Why the Control Plane needs it |
|---|---|---|
| Decision statement | What was decided, in one sentence | Human readability |
| Alternatives considered | What else was assessed, and why rejected | Review quality; not machine-compared |
| Rationale | Why this choice | Review quality |
| Model or service | Named family and version policy | Compared against deployed model registry |
| Hosting pattern | Named deployment topology | Compared against cloud inventory |
| Grounding sources | Named governed data products | Compared against data catalog |
| Authority boundary | For agents: tool list, action limits | Compared against IAM grants |
| Risk tier at decision | Tier and Risk Classification Record reference | Sets alert severity |
| Pattern conformance | Conformant, modified with detail, or novel | Policy-as-code check |
| Accountable owner | Named individual | Alert routing |
The distinction between a field written for a human reviewer and a field written for machine comparison is worth making explicit to authors. “We will use a modern managed model with appropriate controls” is acceptable prose and useless as approved state. “Model family: [approved list entry]; version policy: pinned minor, vendor patch auto-accepted; grounding: Data Product PD-114 only” can be compared tomorrow morning.
Superseding, not editing
An ADR is never edited to reflect a later change. A new ADR supersedes it and references the one it replaces. This preserves the decision history that makes a drift investigation tractable and prevents the common failure where the record silently tracks reality and therefore never shows drift at all.