Lesson 03. Six Clients, Six Constraints

A small agency wins its first bank. It has shipped the same assistant three times for startups: a hosted model behind a thin gateway, a shared vector index, tools that run under one service account, a one-page diagram, six weeks from kickoff to demo. The bank's product team loves the demo. Then the bank's third-party risk function opens its review and asks for a sub-processor list with regions, a data-flow diagram that shows where every prompt goes, evidence that the model provider retains nothing, a validation pack for the model's behaviour, penetration-test results for the gateway, and the name of the person who approves each tool the assistant can call. The agency has none of it, because none of its previous clients had asked. The review runs longer than the build did, the product team's budget window closes, and the deal dies with the demo still working. Decide now: what did the agency get wrong before it wrote a line of code?

Illustrative composite. The agency, the six-week build and the review that outran it are a composite; the pattern of a startup architecture meeting an enterprise procurement process is the common part.

This lesson's deliverable is the third file of your Architecture Dossier. A client-segment profile and a constraint register for your case, listing every constraint with its source and its owner. It goes into dossier/02-constraints.md and it serves the Frame stage of the Frame → Decide → Prove → Run loop, closing the framing before any design decision is taken.

What is actually going on

The agency read the use case and skipped the client. A support assistant for a bank and a support assistant for a startup are the same use case and different systems, because the constraints that shape the system come from who the buyer is, not from what the assistant does. A bank owes evidence to a regulator, to an internal model-risk function and to an audit committee before it owes anything to a user. A startup owes its runway. The constraints existed before the engagement started; the agency's error was to discover them from the reviewer instead of from the segment.

Six segments cover almost every buyer you will meet. An early-stage startup is building one AI-native feature that is the product, with a tiny team and a runway that makes speed the only constraint that matters until a customer asks about data. A scale-up adding AI to an existing product carries multi-tenancy, security questionnaires from its own enterprise customers, and margin pressure, since every model call comes out of a per-seat price. A regulated enterprise, a bank, an insurer or a health system, carries validation, residency, audit and a procurement process measured in quarters, and starts with internal-facing assistants because customer-facing ones need a second layer of review. A public-sector body carries procurement authorisation for every component, transparency and fairness obligations toward citizens, fixed budgets and political exposure. An agency or consultancy building for others inherits the client's segment and adds its own: repeatability, margin on fixed-price work, hand-over and liability for what the system says. An internal platform team serves many product teams at once, so its constraints are cost attribution, guardrails by default and the tension between standardisation and each team's autonomy.

The tree below is the first question you ask on an engagement, before the use case. Follow it from the top and stop at the first leaf.

The tree shows why the agency failed: its first branch says the client's segment applies, and the bank's segment answers the fourth question with "yes." Everything the reviewer asked for follows from that one leaf.

The rule and its condition

Read the client's segment first, because the segment fixes four things before the use case is known: the deployment topology the client can accept, the procurement path and its length, the compliance blockers that stop a launch, and the deliverable the buyer will actually sign. Use the segment's defaults when the client matches its segment on all four; when the client is a hybrid, an innovation lab inside a bank or a startup selling to hospitals, register the constraints of the stricter segment and let the client argue individual rows down, never up. Every constraint in the register carries its source and its owner, so that when a constraint is challenged the challenge goes to a person, not to a rumour.

Read the table by row and the agency's error is one cell: it delivered the startup row's deliverable to a client whose signature required the regulated-enterprise row.

The constraint register

A constraint is anything that removes an option from the design before the design starts. The register lists every one, with an identifier, the constraint in one sentence, where it comes from, whether it is hard or soft, the person who owns it, and the design decision it fixes. The source matters more than it looks: a constraint sourced to "the CISO said so" is negotiable in a way that a constraint sourced to a contract clause or a regulation is not, and the register should let a reader tell the difference at a glance. Follow the diagram from the five kinds of source to the three things the register fixes.

Notice the fifth source. People constraints, such as a sponsor who needs a number by a board date or a workforce that will not adopt a tool sold as a headcount cut, are as real as a residency clause and far more often left off the register because they feel like politics. Register them; they decide adoption, and adoption is where pilots stall.

Worked case

Harbor Mutual is a regulated enterprise: an insurer under EU and UK supervision, with a third-party risk process, a compliance function and a legal team that reviews anything a customer might read. The charter has fixed the use case (complex-letter drafting for handlers) and the budget sheet has fixed the numbers. The constraint register now has to capture everything that removes an option, and most of it comes from the segment, not from the letters. In the workshop, the CISO ruled out inference outside the EU and UK and any vendor that retains prompts beyond its abuse-monitoring window; procurement said any new sub-processor needs a vendor risk assessment before a contract; the head of claims confirmed that no draft leaves without a handler's signature and that the wording archive holds several versions of some wordings with no rule for which is authoritative; IT mentioned that the company's only cloud tenancy sits in a US region because the analytics team set it up; and the senior handler said, quietly, that the first pilot died because handlers stopped using it, not because IT killed it.

Illustrative composite. Figures in this case are modeled: a vendor risk assessment that takes about ten weeks, a platform team of three engineers with no machine-learning operations experience, and a CFO's board date eleven weeks after the workshop.

Before reading the register, decide now: which constraints come from the segment rather than from the use case, and which one would have been missed by an architect who read only the charter?

Here is the register as it sits in dossier/02-constraints.md.

# 02 · Segment profile and constraint register · Harbor Mutual

## Segment profile
Regulated enterprise (insurance; EU and UK supervision). Procurement in
quarters; third-party risk assessment before any new sub-processor; legal
review of customer-facing text; internal-facing first. The buyer signs a
full architecture with a compliance overlay, a validation plan, runbooks and
a system card, not a demo.

## Constraint register

| Id | Constraint | Source | Hard/soft | Owner | Fixes |
|---|---|---|---|---|---|
| C-01 | Inference and storage in EU or UK regions only | Regulatory obligation; CISO policy | Hard | CISO | Topology |
| C-02 | No vendor training on company data; retention within the contract's abuse-monitoring window | Procurement's standard AI clause | Hard | Procurement lead | Vendor choice, topology |
| C-03 | Vendor risk assessment before any new sub-processor is contracted | Third-party risk policy | Hard | Procurement lead | Timeline; prefer providers already assessed |
| C-04 | Every draft signed by a handler; the assistant takes no external actions | Head of claims; charter non-goal | Hard | Head of claims | Human gate; tool catalogue has no write tools |
| C-05 | Customer-facing generated text requires legal review before use | General counsel | Hard | General counsel | Scope: internal-facing only in this engagement |
| C-06 | Wording archive is on-premises; some wordings have several versions with no authoritative flag | Archive owner (claims operations) | Hard, data | Archive owner | Grounding data: versioning rule before indexing |
| C-07 | Existing cloud tenancy is in a US region | IT | Soft: cannot be used for this system under C-01 | IT lead | Topology: new in-region tenancy or private endpoint |
| C-08 | Handlers authenticate through corporate SSO; the assistant must act under the handler's identity, not a service account | IT security policy | Hard | IT security lead | Integration: on-behalf-of identity |
| C-09 | Every draft traceable (wording version, prompt version, model version, handler) for the claim file's retention period | Compliance | Hard | Compliance lead | Observability and retention |
| C-10 | Budget approved quarterly; the CFO needs a cost figure by the board date | Finance | Soft | CFO delegate | Milestones: cost model before the board date |
| C-11 | Handlers will not adopt a tool framed as headcount reduction | Senior handler; first-pilot history | Soft | Head of claims | Adoption plan and sponsor messaging |
| C-12 | Platform team of three runs everything; no ML operations capacity | IT | Hard, ops | IT lead | Topology: managed services, no self-hosting |

## Waivers
None. C-07 is not a waiver of C-01; it records that the existing tenancy is
unavailable for this system.

Twelve rows, and only C-04, C-06 and C-11 come from the letters. The other nine come from being an insurer under supervision with a small platform team. An architect who read only the charter would have found C-01 and C-04, because the charter's users and non-goals imply them, and would have missed C-07: the existing US tenancy looks like an asset until C-01 makes it unusable, and a team that started building there would have discovered the residency clause after the build, which is the failure the topology lesson later in this course opens on. C-12 is the other silent row: three engineers with no model-operations experience rule out self-hosting whatever the cost model later says, and the model-selection record will need to know that. C-08 fixes the integration design before it exists; the build detail for tool wrappers that carry a user's identity and keep secrets out of the model's reach lives in /learn/lesson-04-tools-and-integrations.

The rejected option was to treat Harbor Mutual as a scale-up because it already had a cloud tenancy and a modern analytics team. Under that reading the build starts in the US tenancy on a hosted API, the vendor risk assessment starts when procurement notices, and the first quarter goes to a rewrite onto in-region private endpoints plus a ten-week assessment that could have run in parallel from week one. The cost of the misread is not the rewrite; it is the board date, which arrives before the rewrite finishes.

Faded case

Skip to the open case if this is familiar.

Lumen is an early-stage startup by every branch of the tree: one team, one product, no questionnaires yet, hosted API behind a gateway, US region, one engineer. Its register today has perhaps five rows: runway, the engineer's capacity, the model provider's standard data terms, per-seat pricing that makes margin a constraint, and multi-tenancy in a shared index. Now the enterprise prospect from the charter sends its vendor package: a security questionnaire, a data-processing agreement with a sub-processor schedule, and a request for EU processing for its European staff.

Illustrative composite. Assume the prospect is worth more than the rest of the customer base combined and expects answers within a month.

The decision is yours: which rows does the prospect add to Lumen's register, what is the source and owner of each, and which single row changes Lumen's segment?

Open case

The benefits helpdesk from the earlier lessons: a national agency, citizen callers in distress, a transparency obligation, caseworkers with no spare hours, a procurement rule that every component needs authorisation before it touches citizen data, a fixed annual budget, and a director who promised the minister a spring launch. The agency's IT runs on a government cloud with a short list of authorised services. Write the segment profile and the constraint register with a source and an owner on every row, and mark which rows are hard. The quiz's first item grades the row you put first.

Where this breaks

Segments are a first reading, not a verdict. A regulated enterprise's innovation lab behaves like a startup until its pilot touches production data; a startup selling to hospitals carries its customers' constraints from the first contract; a public body's back-office document pipeline may face fewer constraints than its citizen chatbot. Register the stricter segment and let named owners waive rows, and write each waiver into the register with a date, so that the next architect can see what was relaxed and by whom.

Segments also move. Lumen's register grows a row per enterprise customer, and at some point the rows outweigh the startup defaults and the topology has to change, which is why the register carries a version and a review date like the charter. A register written once and never reread is the agency's error in slow motion.

Finally, the agency's own constraints are not the client's. An agency that registers only the client's rows forgets its hand-over obligation, its liability for what the system says, and the clause about who owns the prompts and evals. Those go in the register too, with the agency's principal as owner, because a client who discovers them at contract signature has found a constraint the architect should have registered.

Key Takeaways

• Place the client in a segment before discussing the use case.
• Let the segment fix topology, procurement path, compliance blockers and the deliverable.
• Register every constraint with its source, its owner and what it fixes.
• Register the stricter segment for hybrids; waive rows down with a named owner.
• Record people constraints, such as adoption and board dates, alongside clauses.
• Version the register; a customer, a contract or a launch can change the segment.

What You Have Now

A client-segment profile and a constraint register for your case, listing every constraint with its source and its owner. It lives at dossier/02-constraints.md and completes the Frame stage of the Frame → Decide → Prove → Run loop: the charter says what the engagement is, the budget sheet says what numbers it must hit, and the register says which options are already gone. The Decide-stage files read it directly. The model-selection record filters providers by the residency and retention rows before looking at capability; the topology record starts from the rows marked "fixes topology"; the integration specification takes its identity rule from the row that names who the assistant acts as. The project that closes this module rebuilds all three Frame files from a discovery transcript.

Example Files

The blank profile and register. Copy to dossier/02-constraints.md; a row without a source or an owner is a rumour, and rumours are not constraints.

# 02 · Segment profile and constraint register · <client>

## Segment profile
<Segment from the tree, in one line. Then four lines: the topology the client
can accept; the procurement path and its length; the compliance blockers that
stop a launch; the deliverable the buyer signs. If the client is a hybrid,
name both segments and say which one the register follows.>

## Constraint register

| Id | Constraint (one sentence) | Source (clause, regulation, policy, person) | Hard/soft | Owner | Fixes (topology, model, data, human gate, integration, timeline, adoption) |
|---|---|---|---|---|---|
| C-01 | | | | | |

Hard: an obligation; the design cannot violate it and only the owner can
waive it in writing. Soft: a circumstance or preference; the design may work
around it and should say how.

## Waivers
| Constraint | Waived by | Date | Condition | Review date |
|---|---|---|---|---|

## Constraints the agency carries (if you are building for a client)
| Id | Constraint | Source | Owner |
|---|---|---|---|
| A-01 | Client owns prompts, evals and data; the agency keeps its gateway layer | Statement of work | Agency principal |
| A-02 | Hand-over runbooks and a model-swap procedure are deliverables | Statement of work | Agency principal |
| A-03 | Liability for generated content is bounded by the eval-based acceptance criteria | Contract | Agency principal |

Further Reading

• AWS Well-Architected Framework, Generative AI Lens: a vendor's own list of the questions a regulated buyer's review will ask, organised by pillar.
• UK Government AI Playbook, February 2025: the public-sector segment's constraints in the buyer's own words, including transparency and procurement principles.
• Revised OMB policies on AI use and procurement by US federal agencies: a summary of the contract clauses public-sector buyers now carry on training, IP and portability.
• OpenAI enterprise privacy page and Anthropic regional compliance page: the two kinds of vendor page a residency or retention row must cite as its evidence.

Exercises

1. Rewrite the opening story's register as the agency should have written it in week one, with at least eight rows, each sourced to a bank policy, a regulation or a named role.
2. Place three organisations you know on the tree. For each, write the one constraint that most surprised you when you first worked with them, and which of the five sources it came from.
3. Build the register for your own case from your charter and budget sheet. Mark every row that came from the segment rather than the use case, and every row you had to guess the owner for; the guesses are the next workshop's invitation list.

Check your understanding