The Architect's Job: Decisions You Put Your Name To

A common story in banks goes like this. A team builds an impressive assistant in six weeks. The architecture board approves it, because the diagrams look like any other web service. Three weeks before launch, the model risk team is asked to sign off. They ask for accuracy evidence, a monitoring plan and a list of known failure modes. Nobody has them. Launch slips five months while the team builds, in a hurry, what should have been designed from the start.

Nobody in that story was lazy. The problem was ownership. The engineers owned the code, the product owner owned the backlog, and nobody owned the question "how will we prove this is good enough, to people whose job is to say no?" In an AI project, that question belongs to the architect.

This lesson defines the role by what it owns. It also names the value gap: the distance between what a demo promises and what production delivers.

The value gap, measured

At Meridian, the first pilot's demo scored 38 out of 40 on policy questions the team had chosen. When the operations team later replayed 500 real staff questions from the pilot logs, it scored 71%. The model had not changed. The questions had. Real staff ask about edge cases, use internal abbreviations, and ask about products the demo never covered.

That drop is typical, and it comes from three separate gaps. An architect's job is to close each one on purpose.

Most teams work hard on the quality gap and are surprised by the other two. The integration gap stopped Meridian's second pilot. The assurance gap stopped the first. Neither can be closed by prompt tuning.

The gaps also have very different costs of closing late. The quality gap can often be narrowed in weeks by better retrieval or clearer prompts. The integration gap can mean rebuilding how the system authenticates to every data source. The assurance gap is the most expensive of all, because evidence cannot be backdated: if you did not log what the pilot did, you cannot later prove how it behaved. An architect who plans for all three in week one saves months in the final quarter.

What the architect owns

An AI solutions architect owns the decisions that shape the system and the evidence that those decisions work. In practice that means seven things.

• Problem framing. Turning "help my people" into measurable requirements with baselines and thresholds.
• System boundaries. What the AI does, what deterministic systems do, and what humans do, written as decision records.
• The quality contract. How quality is defined, measured before launch and watched after launch.
• Non-functional design. Latency budgets, availability, capacity and cost per unit of work.
• Integration and failure behaviour. How the system connects to enterprise systems and what happens when each one fails.
• Control design. Which technical controls answer which risks, so security and risk teams can test them.
• Traceability. The links that let anyone follow a requirement to its design, test and owner.

Notice what is not on the list. The architect does not own the truth of the policy content; the policy team does. The architect does not accept risk on the bank's behalf; the business owner and the risk committee do. The architect usually does not train models. Confusing "I designed the control" with "I accept the residual risk" is the fastest way to lose a risk committee's trust.

A decision-rights table for Meridian

Unclear ownership costs weeks. The fix is cheap: write down who decides what, before the first design review. Here is the table Meridian adopted. R means responsible for doing the work, A means accountable (the single person who decides), C means consulted and I means informed.

Two rows deserve attention. Model risk is accountable for independent validation, and the architect is only informed. That separation is deliberate: the people who validate must not be the people who built. And the Head of Servicing, not the architect, accepts residual risk, because she owns the business outcome and the customer impact.

Architecture decision records

Every significant choice gets an architecture decision record (ADR). An ADR is a short document with a fixed shape: context, decision, alternatives, consequences, and what evidence would make you revisit it. The last field matters most in AI work, because the technology changes every few months.

# ADR-004: The assistant never sends customer lettersStatus: Accepted (2026-03-12)Deciders: Architect (A), Head of Servicing (C), Model risk (C)## ContextHardship letters carry figures and mandatory wording. A wrong lettercreates a customer detriment and a regulatory breach.## DecisionThe assistant creates drafts only. Sending stays in the existingdocument service, triggered by a named staff member's approval.## Alternatives considered1. Auto-send drafts that pass all checks: rejected, no human   accountability for customer communication.2. Auto-send after a second model reviews: rejected, two models can   share the same blind spot.## ConsequencesStaff time per letter falls less than full automation would allow.Review quality must be measured (see MER-06, review design).## Revisit whenTwelve months of data show a draft error rate below 0.5% and modelrisk agrees a sampled-review regime is adequate.

The "revisit when" field turns a "no" into a conversation with a clear exit. Stakeholders accept a firm boundary much more easily when they can see what would move it.

Keep ADRs small and numerous rather than large and few. Meridian's design ends with about twenty of them. Each one is short enough to read in two minutes, and each has a single decision. When a reviewer challenges one choice, you reopen one record, not a fifty-page design document, and the history of why the choice was made stays intact for the next architect who inherits the system.

1id: MER-012title: Loan servicing assistant charter3sponsor: Dana Whitfield, Head of Loan Servicing4architect: Solutions architecture, retail lending5users: 450 loan-servicing staff, two centres, 07:00-21:006capabilities:7  - policy_answers        # cited answers from 260 policy documents8  - account_summary       # one-screen history, hardship and arrears cases9  - hardship_letter_draft # wording around rules-engine figures10non_goals:11  - customer-facing chat12  - eligibility or credit decisions13  - sending any communication14  - writing to core banking15baselines:16  policy_lookup_minutes_median: 6.517  history_review_minutes: 1418  letter_draft_minutes: 2219  letter_qa_failure_rate: 0.0720  staff_policy_error_rate: 0.1821decision_rights: MER-01-annex-A   # the RACI table