What You Will Build: the Meridian Design Record

It is a Thursday afternoon at Meridian Bank. The Chief Risk Officer, the Chief Information Security Officer, a finance partner and the head of model risk sit around a table. They have forty minutes and one question: should the bank put a generative AI assistant in front of 450 loan-servicing staff who handle people in financial difficulty? You are the architect. Everything you say in those forty minutes has to point to a document, a number or a test.

This course builds that design, one document at a time, and ends in that room. You will not write a thousand lines of application code. You will write the decisions that tell a team of engineers what to build, and the evidence that tells a risk committee why it is safe enough to run. That is the job of an AI solutions architect in a large organisation.

We start with the finished product, so you always know where each lesson is heading. Then we look at the thirteen documents behind it, which this course calls the design record.

Meridian Bank and the ask

Meridian is a regulated retail bank with 2.4 million customers and 380,000 active loans: mortgages, personal loans and car finance. Its loan-servicing operation has 450 staff in two centres, working 07:00 to 21:00, and handles about 7,000 servicing cases a working day. Hardship requests, where a customer cannot keep up with repayments, arrive at about 1,500 a month and grew 30% last year.

Before any design work, the operations team ran a two-week time study with 40 staff. These baseline numbers appear again and again in the course, because every later claim is measured against them.

The sponsor is Dana Whitfield, Head of Loan Servicing. Her ask, in her own words: "Help my people find the right answer, see the customer's story quickly, and write the letter correctly the first time."

What the finished assistant does

The assistant lives as a side panel inside Atlas, the case management system staff already use. It does three jobs, and only three.

1. Policy answers. A staff member asks, "Can we offer a payment holiday on a car finance loan that is already two months in arrears?" The assistant answers in plain language and cites the exact policy sections it used, with their effective dates.
2. Account history summary. When a hardship case opens, the assistant prepares a one-screen summary: loan details, arrears, missed payments, earlier hardship plans, contact history and any vulnerability flags, each line linked to its source record. Staff can also ask for one on any case with arrears.
3. Hardship letter draft. The staff member picks the plan the customer agreed to. The Hardship Calculator, an existing rules engine owned by Credit Risk, produces every figure. The assistant writes the explanation around those figures in the bank's approved template. A human reviews, edits and approves; the existing document service sends it.

Just as important is what the finished assistant never does. It never decides whether a customer is eligible for a plan. It never sends a letter. It never writes to the core banking system. It never talks to customers. Each of these boundaries is a decision you will record, defend and enforce in the design, not a promise in a slide.

The design record

The design is thirteen short documents. Each section of this course produces one. Each document takes its inputs from the ones before it, so a decision made in section 3 is still visible, by ID, in section 13.

Each document is short: usually two to five pages of tables and short YAML or Markdown, not prose essays. A reviewer should be able to find any decision in under a minute.

Why a design record and not a slide deck

A slide deck tells a story once. A design record lets a reviewer pull any thread and follow it to the end. Suppose the Chief Risk Officer asks, "What stops a wrong arrears figure reaching a customer?" With a design record, the answer is a chain of IDs:

1. Requirement — MER-03 says every figure in a letter must equal the Hardship Calculator output, with zero tolerance.
2. Decision — the decision record says the model never computes figures; the rules engine does, and the model only writes the words around them.
3. Permission — the tool matrix in MER-06 gives the assistant read-only access to the calculator and no way to send a letter.
4. Test — the evaluation plan in MER-08 checks every draft's figures with code before a human sees it.
5. Operation — the runbook in MER-09 treats a wrong figure in a sent letter as a top-severity incident with a named owner.

That chain is what convinces a risk committee. Not the claim "the model is very accurate", but five linked pieces of evidence, each owned by someone, each testable. When a reviewer finds a broken link, you fix one document, not the whole deck.

The design record also protects the team from drift. When someone proposes, six weeks in, to "let the model calculate the reduced payment because it is faster", the decision record shows why that was ruled out and what evidence would change the decision.

The next lesson starts the first design-record document, MER-01, by settling who owns which decision before any design work begins.

Check your understanding

0 of 3 answered

1.Meridian's earlier pilots were stopped by model risk and by security. What do the two failures have in common?

AThe model was not accurate enough on policy questionsBBoth lacked design decisions and evidence that reviewers needed, not model capabilityCBoth used the wrong cloud providerDBoth tried to talk to customers directly

2.Why does the finished assistant take every letter figure from the Hardship Calculator instead of asking the model to compute it?

AModels cannot do arithmetic at allBThe calculator is faster than a model callCIt makes a zero-tolerance requirement enforceable by code, using a rules engine the bank already trusts and validatesDRegulators forbid language models in banking

3.A reviewer asks where the decision "the assistant never sends letters" is enforced. With an design record, what is the best answer?

A"It is in the system prompt"B"The team agreed it in a meeting"CPoint to the decision record, the tool matrix that exposes no send tool, and the test that proves itD"The model has been told it is only a draft"