What you'll learn: how to defend a design to an architecture review board (ARB): three ways to answer a challenge, model answers to five challenges on the Order and Policy Assistant, and how to leave with a recorded outcome.
At a glance
Figure 1. A review session from challenge to recorded outcome
How to read this: three answers per challenge, then a log entry.
- Send a short pre-read two days ahead.
- A named gap builds trust.
- Leave with a written outcome and conditions.
Scenario
Composite scenario, not a real company. Lumen Industrial Supply, a fictional distributor of industrial equipment, holds an architecture review to decide whether the Order and Policy Assistant may move from proof of concept (POC) to a pilot with some of its 24 agents. The board has a chair, a security reviewer, a platform engineer and a finance partner. You have 20 minutes (illustrative): five to present, fifteen to answer.
What you will be able to do
- Prepare a two-page pre-read from your design-pack artifacts.
- Answer a challenge by defending, conceding or deferring, and say which.
- State a review outcome and its conditions in writing.
Prerequisites
- Executive briefing, estimation and TCO (total cost of ownership), POC design.
- Governance and responsible AI.
Core ideas
Three answers to a challenge
| Answer | Use it when | Sentence shape |
|---|---|---|
| Defend | You hold evidence | "The log review found no customer personal data." |
| Concede | It is right and fixable | "That is a gap. I will write and test the switch-off steps." |
| Defer | You lack the information | "Not yet known. Owner: platform team; date: Friday." |
Five challenges and model answers
| Challenge | Model answer |
|---|---|
| Security: what can it read, and what is logged? | Defend: each agent's own sign-in reaches the OMS (order management system) read-only; logs hold no customer personal data. Defer: where the hosted model processes data is open; owner IT security lead (threat modelling) |
| Cost: how wrong could you be? | Defend: build 30,600, three-year TCO 93,357.50 (illustrative). Model use is 399.17 of 20,919.17 yearly run cost, so tripling the model price adds about 3.8 percent (cost economics) |
| Evaluation: how do you know it works? | Defend: the POC report against its criteria. Concede: the 9-minute baseline is 24 timings from six agents; the pilot re-measures it |
| Rollout: what stops it? | Defend: the pilot group and stop rule in the rollout plan, with a named owner who can pause it |
| Failure: what if it is wrong or down? | Defend: answers show policy id and version; if the service is down agents work as today. Concede: switch-off steps unwritten (owner platform team) |
In the interview: "How would you defend this design?" A strong answer states the decision, shows evidence, concedes one weakness and says what would change it. Outcomes: approved, approved with conditions (owner and date each), or not approved with the missing evidence named (mindset lesson).
Worked example
Spot the flaw. Find at least four defects before opening the answer.
Board: What can the assistant read, and what do you log?
Presenter: It uses one admin account for the OMS so lookups never fail.
We log full conversations for debugging. The vendor says the
platform is secure, and the demo worked.Answer
- One admin account breaks least privilege: the OMS cannot tell which agent asked.
- Full conversations hold customer personal data; log category, policy ids and result.
- A vendor claim is not evidence about Lumen's setup.
- A demo is one chosen path, not a test.
Stronger: "Agents' own sign-ins reach the OMS read-only; the POC log review found no customer personal data. Access test before the pilot; owner: me."
Practice task
Add the review defence to your design pack. With a colleague, write a two-page pre-read (context view, TCO table, POC results, security checklist), take the five challenges in 20 minutes, and answer each with defend, concede or defer. Have them write the outcome.