Functional and infrastructure requirements; a prompt or model change is a release

An insurance broker asks for an assistant that summarizes calls: it wants the reason, the policy details and the next steps. The document lists all of that and nothing else. Only in the meeting does it come out that the summary is used with the customer still on the line and that compliance requires recordings to stay in the European region. Those two sentences change the design more than everything before them.

What it does and how it has to run

• Functional requirements say what the system does: which fields the summary has, which button appears, what happens if a piece of data is missing.
• Non-functional requirements, or infrastructure requirements, say how it has to run: latency, volume, availability, data residency, security, traceability, cost.

Choosing a model, using streaming or moving to batches are not requirements: they’re decisions that follow from them.

Requirement	Decision it suggests
“The first part must appear within seconds, with the customer on the line”	Streaming, a fast model, a short prompt
“Ten thousand documents a month, no rush”	Message Batches API
“Data doesn’t leave the EU region”	A regional endpoint or the cloud platform that guarantees it
“Be able to explain a decision a year later”	An audit log from day one

Auditing means recording at the time

If the business must later show what the system received, what it ran with and what it answered, you have to record it when it happens: the input, the output, the request ID, the pinned model ID and the prompt version. Rerunning the request later reconstructs nothing: the prompt may have changed and a model’s output is not deterministic.

The lifecycle

A Claude system goes through the same stages as any system: plan, build, test, deploy, operate and, finally, retire or migrate. What’s particular is that two pieces change behavior without touching the code: the prompt and the model. So a change to either one is just another release:

1. Regression testing: run the set of graded cases (for example, a hundred and fifty conversations with the expected answer) and compare against the current version.
2. Gradual rollout: first to a small percentage of traffic, watching metrics, then to the rest.
3. Rollback: the previous version stays ready to be restored in minutes.
4. Production monitoring: error rate, unexpected stop_reason values, latency, cost and a sample reviewed by people.

A prompt edited live on a Friday that reaches production without any of this is the exam’s typical scenario.

When a model is retired

Models have a model retirement date, and after that date requests to that ID fail. The deprecation notice is the start of a maintenance task:

1. Inventory every place where a model ID is configured (services, jobs, scripts, clouds).
2. Evaluate the successor model in each service with its own set, and build the set if it’s missing.
3. Migrate in good time, with the same gradual rollout as any release.

The typical traps

• Confusing a technical decision (“use Opus”) with a requirement.
• Missing the non-functional requirements hidden in the scenario’s context.
• Thinking you can audit later by rerunning the request.
• Releasing a prompt or model change without regression testing, gradual rollout or rollback.
• Waiting for the retirement date to start migrating.

On the exam

If you’re asked for infrastructure requirements, choose the ones about latency, volume, region, availability or traceability, not features. If the requirement is auditing, look for recording at the time, with model and prompt version. If a prompt change caused harm in production, look for regression testing, gradual rollout and rollback. And when there’s a retirement notice, look for inventory, evaluation of the successor and migration before the date.