Chapter 32. End-to-End Walkthrough

One system, from opportunity to retirement, with every record it produces and every decision it triggers. The example is deliberately sector-neutral so that the mechanism, instead of the domain, is what is visible.

32.1 The system

A large organization operates a shared services function that receives high volumes of inbound written requests. Each request must be categorized, routed to a specialist queue, and prioritized. The work is currently manual, slow, and inconsistent between assessors.

The proposal is a system that reads each request, proposes a category and priority, and drafts a short summary for the receiving specialist.

Throughout this chapter, records are shown as they would actually be written, and the reasoning behind each judgment is stated. Several judgments are contestable; where that is so, the alternative is discussed, not hidden.

32.2 S0 — Opportunity

The capability owner proposes the initiative. The architect’s role at S0 is short: establish that a capability need exists and that AI is the right instrument.

Capability: Request Intake and Routing. Baseline maturity 2, target 4.
Current state: mean 3.2 days from receipt to correct queue. 18% of requests are re-routed at least once.
Need: reduce time to correct queue and reduce re-routing.
No-AI alternative considered: a rules engine over sender and keyword was piloted two years ago and reached 54% routing accuracy against a 90% requirement. Free-text variability defeated it. Rejected on evidence.
Provisional sourcing direction: foundation model API or retrieval-augmented approach; not fine-tuning, since the routing taxonomy changes quarterly.

Decision: proceed to qualification.

Note what has not happened. No vendor has been named, no architecture proposed, and no commitment made. The recorded rejection of the rules-engine alternative is what makes the AI choice defensible later.

32.3 S1 — Use-Case Qualification

The Use-Case Canvas is produced.

Table 81. S1 — Use-Case Qualification

Provisional tier: Impact = avg(2, 3, 3) = 2.67 → 3. Control Deficit = avg(2, 2) = 2. Matrix gives Tier 2.

32.4 S2 — Risk Classification and countersignature

The Risk and Compliance Lead runs the scoring session with the sponsor, the architect, and the data owner.

Table 82. S2 — Risk Classification and countersignature

Impact = avg(3, 3, 3) = 3. Control Deficit = avg(2, 2) = 2. Matrix: Tier 2. No safety override.

Countersignature. The Risk Lead is the accountable scorer here, and the countersignature is provided by a second reviewer from the compliance function who was not in the scoring session. Their note:

D1 raised from 2 to 3 during the session and I agree; the entitlement time-limit point is material. Flagging that this system sits one point of D1 from Tier 3, and that D2 = 2 depends on intake specialists genuinely reviewing proposals. Requiring override-rate instrumentation as a condition of G3.

This is countersignature working as intended. It did not change the tier. It identified the boundary condition and attached a condition that will detect if the assumption behind D2 fails.

32.5 Gate G1

Tier 2, so the gate is self-service with notification. The capability owner approves; the AI Governance Lead is notified.

Outcome: Approve with conditions. Condition: override-rate instrumentation to be in place before G3. Owner: system owner. Due: G3.

32.6 S3 — Architecture Decision

Now the architecture is settled. The team assesses sourcing against the twelve considerations and lands on a retrieval-augmented approach using an approved foundation model API, grounded on the routing taxonomy and a curated set of routing precedents.

Fine-tuning was rejected: the taxonomy changes quarterly, and every change would be a Major change requiring full revalidation. That recurring cost exceeded the accuracy benefit in the team’s assessment.

ADR-0311
Decision: Implement request triage using the Enterprise RAG pattern v2, unmodified, with an approved foundation model accessed through the enterprise LLM gateway.
Alternatives: (a) Fine-tuned classifier — rejected; quarterly taxonomy change makes revalidation cost prohibitive. (b) Rules engine — rejected at S0 on evidence. (c) Vendor SaaS triage product — rejected; would require the request corpus to leave the enterprise boundary, and D5a is 3.
Model: [approved list entry]. Version policy: pinned minor; vendor patch auto-accepted; family change requires new ADR.
Hosting: vendor API via enterprise gateway, in-region endpoint.
Grounding: DP-207 Routing Taxonomy (Internal); DP-208 Routing Precedents (Restricted). No other sources.
Pattern conformance: Conformant, Enterprise RAG v2, unmodified.
Authority boundary: none. The system has no tool access and cannot write to any system. Output is a proposal rendered in the intake interface.
Risk tier at decision: Tier 2, per RCR-0188.
Accountable owner: Intake Platform Product Owner.

The authority boundary line matters even though it is empty. Recording that the system has no action capability is what makes a later grant of action capability detectable as a change.

32.7 S4 — Data Readiness

Table 83.

The maximum staleness values are the practice recommendation from Chapter 9, §9.2, not a framework requirement. They matter here: a routing taxonomy that has changed while the grounding source has not is exactly how this system would degrade silently.

Finding raised at S4: DP-208 had no named owner. The steward was assigned before G2 could proceed. This is the most common S4 finding and it was caught because the record has an owner field that cannot be left blank.

32.8 Gate G2

Tier 2 with an unmodified pattern, so architect self-certification applies and the ARB is notified, not convened.

Risk re-score at G2: the architecture confirms D2 = 2 (no action capability, proposal only) and D5a = 3 (Restricted grounding source retained inside the boundary). The vendor-SaaS alternative would have raised D5 and possibly the tier; the chosen architecture does not. Tier confirmed at 2.

Outcome: Approve. Pattern conformance recorded as conformant. ARB notified.

32.9 S5 — Build

Light governance. Two things are checked, both automatically.

The deployed model family is compared against the ADR by policy rule; it matches. The grounding sources connected in the development environment are compared against the lineage record — and here the Control Plane, running in the non-production environment per Chapter 10’s recommendation, raises a finding.

Drift finding DR-0442. Category 5, Data Lineage and Governance. Development environment shows a third grounding source connected: an unclassified export of historical case notes, not present in the lineage record.

The team explains it was connected for evaluation and was intended to be temporary. This is the classic S5 drift origin, caught before production, not after.

Endpoint: Revert. The source is disconnected. No change record required, because the approved state was correct and the divergence was unintended. Had the team wanted to keep it, the endpoint would have been Ratify, requiring a change record and a G4 assessment, since a new Restricted-or-above source is a Material change.

32.10 S6 — Assurance

Five assurance types, at Tier 2 depth.

Table 84. S6 — Assurance

Note that the pass threshold was defined before the evaluation ran. This is a small discipline with a large effect: thresholds set afterward are set to whatever the system achieved.

32.11 S7 and Gate G3

Tier 2, so the System Owner approves and the AI Governance Lead is notified.

Evidence presented: assurance summary, Control Matrix, named owner, human oversight point confirmed (the intake specialist’s confirmation step), and — the G1 condition — override-rate instrumentation in place.

Deployment Authorization DAR-0129. System: Request Triage Assistant. Tier 2. Authorized by Intake Platform Product Owner, [date]. Evidence: AIS-0233, CM-0177, ADR-0311, RCR-0188. Conditions: override rate to be reported at the first quarterly review; a rate below 5% triggers a D2 re-score.

The condition converts a known weakness of the scoring model into a scheduled check with a pre-agreed threshold. This is the practical answer to the effective-autonomy problem in Chapter 6, §6.3.

32.12 S8 — Runtime, and what happens over eleven months

Month 1. Routing accuracy holds. Mean time to correct queue falls to 1.4 days.

Month 3. First quarterly review. Override rate is 11%: specialists change roughly one proposal in nine. D2 = 2 is supported by evidence rather than assumption. No re-score.

Month 5. Cost drift signal. Inference spend is 40% above the approved budget. Investigation shows request volume grew after another department began routing its intake through the same queue. This is D4 movement disguised as a cost signal, which is exactly why cost is in the drift taxonomy. The Risk Lead re-scores D4: still 3, since the population is still internal and the system of record unchanged. Tier unchanged. The budget is revised.

Month 7. Behavioral drift. Summarization quality degrades on a subset of requests. The two candidate causes are separated immediately because the framework keeps them apart: has the model changed, or has the grounding changed? The model registry shows the vendor pushed a minor version, which the ADR’s version policy auto-accepts. The lineage record shows DP-208 was last refreshed 71 days ago against a 60-day maximum.

Both are true. The vendor update is a Material change at Tier 2 under the change table only at Tier 3–4, so it is recorded as Minor here; the staleness breach is a Data Lineage drift finding requiring the steward to refresh. Quality recovers after refresh, which identifies staleness as the dominant cause.

This is the diagnostic value of separating category 5 from category 6. With a single “data drift” signal, the team would have spent the investigation arguing about the model.

Month 9. A change request arrives, and it is the interesting one.

32.13 S9 and Gate G4 — the autonomy change

Operations propose that requests the system categorizes with high confidence should route automatically, without specialist confirmation, to reduce handling time further.

Classification: this removes a human step from a path. Under the change table it is Major, always — an autonomy increase, boundary-widening. It is never eligible for self-service classification regardless of the current tier.

Consequences: S2 re-entry, G2, and G4.

Re-scoring:

Table 85. S9 and Gate G4 — the autonomy change

Impact = 3. Control Deficit = avg(3, 2) = 2.5 → 3. Matrix: Impact 3, Control Deficit 3 → Tier 3.

The system moves from Tier 2 to Tier 3 on a single dimension change. Everything downstream changes with it: G2 now requires ARB decision rather than self-certification; G4 requires AI Governance Body approval; annual re-scoring becomes mandatory; alert response tightens to five working days; and the AI Governance Body must approve the autonomy grant specifically, not merely the change.

ARB at G2. The architecture now includes a confidence threshold and an auto-route path. That is a modification to the Enterprise RAG pattern, so the fast path is unavailable and the modification is reviewed on its merits. ARB approves with a condition: the confidence threshold must be recorded in the ADR as an approved-state value so the Control Plane can detect it being lowered.

That condition is worth pausing on. Without it, someone could reduce the threshold from 0.95 to 0.80 as a configuration change, materially widening the autonomous path, and nothing would detect it. With it, the threshold is comparable and a reduction is Configuration drift on a Tier 3 system.

AI Governance Body at G4. Approves the autonomy grant with two conditions: the auto-route path is limited to three request categories initially, not all, and override-rate reporting moves to monthly for the confirmed path.

ADR-0388 supersedes ADR-0311. Records the confidence threshold (0.95), the three permitted auto-route categories, and the retained human path for everything else. RCR-0244 records the Tier 3 re-score. ACR-0517 records the change classification and its reasoning.

32.14 S10 and Gate G5 — retirement, two years on

The organization replaces its case management platform, and the new platform includes native intake triage. The Request Triage Assistant is retired.

Table 86. S10 and Gate G5 — retirement, two years on

G5 outcome: Approve. Tier 3, so the AI Governance Lead confirms no open obligations remain — one exception was open and had expired; it is closed as part of retirement.

The dependency finding is the one that would have caused an incident. Two consumers existed that nobody had recorded, and telemetry found them where documentation did not.

32.15 What the walkthrough demonstrates

Six things worth extracting.

The tier did the work. Almost every difference in how this system was governed traced to its tier, and the tier changed once, on one dimension, and changed everything downstream with it.

Countersignature earned its place without changing the tier. Its value was identifying the boundary condition and attaching the instrumentation that would detect the assumption failing.

The most consequential single control was a condition, not a gate. Requiring the confidence threshold to be an approved-state value is what made a future widening of autonomy detectable.

Separated drift categories paid off diagnostically. Month 7 resolved quickly because model behavior and grounding lineage are distinct signals.

Non-production comparison converted an incident into a conversation. DR-0442 would have been a production data-governance finding.

Retirement found what documentation had not. The dependency check is routinely the most valuable part of G5 and the most often skipped.