Chapter 10. Build, Configure, Acquire: S5
The stage where architecture governance deliberately does the least, and the two things it must still do.
10.1 The light-touch principle
S5 is where the system gets built, integrated, or purchased. Architecture governance is intentionally thin here. Construction is an engineering and delivery activity, and IRGF’s scope boundary (Chapter 1, §1.3) puts model training, prompt authoring, retrieval tuning, and implementation detail outside its reach.
Two governance obligations remain, and both are about boundary conformance rather than construction quality.
The build must stay inside the approved architecture. The system that emerges from S5 should be the system the ADR describes. Where implementation reveals the approved architecture is unworkable, that is a change to the architecture decision, handled by superseding the ADR, not an implementation detail to absorb quietly.
Approved-list conformance must hold. Models, platforms, and patterns used in the build must be those the ADR named. This is a strong policy-as-code candidate and one of the first preventive rules worth automating (Chapter 18).
10.2 Where drift begins
Most architecture drift originates in S5, not after deployment. The pattern is consistent and worth naming so teams recognize it.
Table 32. Where drift begins
| Origin | What happens | Detection |
|---|---|---|
| Convenience substitution | A different model is used because the approved one had a quota issue during a sprint | Model registry compared against ADR |
| Scope accretion | An additional data source is connected “temporarily” for testing and stays | Data catalog compared against lineage record |
| Permission expansion | A service account is granted broader access to unblock integration | IAM compared against authority boundary |
| Pattern departure | The pattern’s trust boundary is adjusted to fit an existing network topology | Policy evaluation of deployment configuration |
None of these is misconduct. Each is a reasonable local decision under delivery pressure. The framework’s response is not to prevent them but to make them visible, so that a temporary expedient either gets ratified through a change record or gets reverted before production.
[Practice recommendation] Run Control Plane comparison in non-production environments from the point the ADR is approved, not from deployment. Drift found in a development environment is a conversation; the same drift found in production is an incident.
10.3 Procured systems at S5
For purchased AI, S5 is configuration and entitlement review, not construction. The governance content is different in kind.
Three checks carry most of the value. What data the feature actually processes, verified against what procurement was told. What the default configuration enables, since vendor defaults frequently turn on capabilities the risk assessment did not contemplate. What the update policy is in practice, because a vendor-side model change is a change to your system that you did not initiate and may not be notified of.
That last point connects directly to the change model in Chapter 14: vendor-initiated model updates are changes to your system, and your change classification applies to them even though you did not make them.