2.2 · 2.8% of the exam · Topic 2 of 6
Systems Life Cycle
A Claude application moves through requirements, design, implementation, verification, release, operation, and change. A model swap or a prompt edit is a new pass through that cycle, not a silent replacement.
Learning objectives
- Name the life-cycle stages that sit around a Claude application.
- Place requirements from task 2.1 before design and implementation.
- Treat verification as tests and evaluations of the behavior you promised, not only a successful HTTP call.
- Operate the system on cost, latency, errors, and quality after release.
- Run a model upgrade or a prompt change through review and verification again.
Detailed theory
The cycle, not a launch
Systems life cycle management is the 2.8% skill inside Applications and Integration. It is how a team carries a requirement from the first statement to a system that stays correct after it ships.
The stages are the ordinary ones: understand the need, design, build, verify, release, operate, change, and eventually retire. Claude does not remove them. The model call sits inside implementation. The promise you made to users sits in requirements, and the evidence that the promise holds sits in verification and operation.
What each stage owns
Requirements, covered in 2.1, say what the system must do and which constraints are measurable. Design chooses the surface, the request shape, and where control lives in code. Implementation is the client, the prompts, the tools, and the persistence of conversation state.
Verification checks the acceptance criteria: functional tests, schema checks, and evaluations of quality where the output is language. Release is a version you can name. Operation watches latency, errors, spend, and the cases the evaluation set did not include. Change is a new model version, a prompt edit, or a tool change. Retirement removes a path users should no longer hit.
- Requirements before model choice.
- Design before you scatter prompts through the codebase.
- Verification against the criteria you wrote, not against a single demo transcript.
- Operation after the first users, because production inputs differ from the eval set.
- Change is reviewed. Retire a prompt or model id when it is no longer supported.
A change re-enters the cycle
Public study notes for this exam say model releases can change behavior, so a production system pins a model version and treats an upgrade as a change that needs evaluation. That is life-cycle management applied to the API.
The same rule covers a prompt rewrite and a tool schema change. Both can move the system's behavior without a compile error. They go back through review and verification before they replace the version that is running.
Core concepts
Requirements
- What
- The statement of outcomes and measurable constraints, before a model or a framework is chosen.
- Why
- Later stages have nothing to verify if this stage stays vague.
- When
- A new system, or a change that alters what users were promised.
- When not
- You already have an accepted requirement and you are fixing a defect inside it.
Verification
- What
- Tests and evaluations that show the acceptance criteria hold.
- Why
- A 200 from the API does not show that the summary, the tool call, or the cost target is right.
- When
- Before release, and again when the prompt, tool, or model version changes.
- When not
- You treat a single happy-path transcript as the whole test.
Operation
- What
- The running system, watched for latency, errors, spend, and quality.
- Why
- Production traffic is the input distribution you did not write by hand.
- When
- After release, for as long as the system is in use.
- When not
- You stop looking once the deploy pipeline is green.
Change control
- What
- A named version of the model, prompt, and tool contract, reviewed before it replaces the last one.
- Why
- Those three can change behavior with no type error.
- When
- An upgrade, a prompt edit, or a schema change.
- When not
- You edit the live prompt in place because the diff looks small.
Practical examples
Overnight documents
The requirement is 100,000 documents overnight, no one waiting, with a cost cap. Design can choose asynchronous work. Implementation calls the API. Verification samples outputs against the acceptance criteria and checks the job finishes inside the window and the budget. Operation keeps the failure and spend charts. A later model upgrade is not deployed because the previous job succeeded. It is verified against the same criteria first.
A prompt edited in production
Support changes one sentence in the system prompt on the live service. There is no release name and no rerun of the cases that used to fail. The life-cycle defect is the missing verification and the missing version, not the wording of the sentence.
Claude-specific considerations
- Pin the model id you verified. Public notes for this exam treat an unpinned upgrade as a behavior change, not a drop-in.
- Prompt caching and batch versus real time are API choices made in design. They are covered as mechanics in 2.3. The life cycle is what forces you to re-check them when the workload changes.
- Session history is application state. A design that cannot say which transcript a user is on will be hard to operate and hard to retire.
- Retiring a model id means the client must stop sending it. Leaving the old id only in a comment does not retire the path.
Architecture decisions
Tradeoffs
A short path to production skips stages and learns from outages. A full pass is slower and leaves a version you can explain. The left column skips. The right column keeps the stage.
Quick reference
- Life cycle: requirements, design, implement, verify, release, operate, change, retire.
- A successful HTTP call only shows that implementation can reach the API.
- Verification uses the acceptance criteria from 2.1.
- Operation watches latency, errors, spend, and quality.
- A model upgrade or a prompt edit re-enters review and verification.
- Retire a model id or prompt by removing the live path, not by commenting it.
Decision rules for the exam
Common exam traps
Exam tips
- This repository does not yet include practice questions for systems life cycle management. Use the sheet, not an invented item.
- If a stem is only about message history or stop_reason, that mechanic is task 2.3. This task is the stage the mechanic sits in.
- A vague brief that jumps to a model is still a requirements failure, even when the question sounds like architecture.
Common mistakes
Shipping on a single transcript.
Compare outputs with the acceptance criteria, and keep a set you can rerun.
Watching uptime and not spend or quality.
Operation for a Claude application includes tokens, latency, and the behavior users get.
Editing the prompt on the server without a diff.
Keep the prompt in version control with the code that sends it.
Practice questions
Original questions for this topic. They are study items, not questions from the live exam.
Scenario questions
Build exercise
Write the life cycle for one Claude job
Beginner · 30 minutes
What you will learn
- Where requirements end and design starts.
- What verification has to show.
- Which signals operation watches.
- How a model change re-enters the cycle.
Step 1
Pick one job from the requirements in 2.1
Use a workload you can describe in a few sentences, such as overnight document processing or an interactive support reply.
Why: The stages are easier to check against a concrete job than against a blank template.
You should see: One paragraph that states the outcome and two measurable constraints.
Step 2
Name the design and the implementation
Write the surface, whether anyone waits on the result, and what the client stores between calls.
Why: Design is the decision. Implementation is the code that carries it.
You should see: A short note that says real time or asynchronous, and where the message history lives.
Step 3
Define verification and operation
List the checks that must pass before release, and the charts you would watch after release.
Why: Those are the stages teams skip when the first call succeeds.
You should see: At least one behavioral check and one cost or latency check.
Step 4
Plan one change
Describe a model upgrade as a new version: what you pin, what you rerun, and how you retire the old id.
Why: Public notes treat an upgrade as a behavior change.
You should see: A version name, a verification step, and a way the old id stops being sent.
Review checklist
Checks are saved in this browser.
Key takeaways
- The life cycle wraps the API call. The call is not the whole system.
- Requirements and acceptance criteria come before design.
- Verification checks the criteria. Operation watches the live system.
- Model, prompt, and tool changes are new versions.
Sources
- CCDV-F exam guide, Domain 2 skill weights — Public blueprint summary