AnthropicClaude Certified Architect – Professional2026-106.4 Document architectures and provide implementation guidance
Give operators procedures and decision authority
Completed by the knowledge check
Learning objective
Write operational runbooks and responsibility matrices for deployment, monitoring, incident response, and rollback.
Core idea
For an architect transferring a production Claude service, a runbook must turn a recognizable condition into an authorized action and a verified outcome. A responsibility matrix must identify who performs that action, who owns the decision, and who receives the update. “Contact the AI team” supplies neither.
NIST AI RMF GOVERN 2.1 calls for documented responsibilities and communication lines. MANAGE 4.1 covers post-deployment monitoring, incident response, recovery, and change management. Use a runbook and an ownership matrix as concrete implementations of those practices. They complement the release inventory in 6.4.1 and the implementation specification in 6.4.3: knowing what is deployed and how it should behave is necessary, but operators also need permission and procedures to change its state.
How it works
Write a procedure someone can execute
Start each runbook with its purpose, trigger, affected service and release, owner, prerequisites, and last exercise date. Put the first stabilizing action near the beginning. Then give ordered actions, expected observations, stop conditions, and an escalation path. Name the actual deployment or operational control used by your application; “disable the agent” is incomplete until the operator knows which control does it and what it leaves running.
Separate observation from mutation. A diagnostic query can be safe for any on-call engineer while a queue purge requires additional authority. Identify required credentials by role or reference, without embedding secret values. Include a way to obtain the procedure when the affected service is unavailable.
For each action, state how to verify its effect. “Restore release R17” needs a check that traffic actually reaches R17, that its prompt and tool versions resolve correctly, and that pending work is handled. A successful deployment command alone does not establish service recovery.
Cover the four operational paths
A compact runbook index makes the paths discoverable:
| Path | Procedure must identify | Completion condition |
|---|---|---|
| Deployment | Approved release, checks, exposure stages, promotion authority | Intended configuration serves the intended population |
| Monitoring | Signal, denominator, threshold, observation window, alert destination | Alert delivery and the owner’s response are exercised |
| Incident response | Severity, stabilizing action, incident roles, escalation, update cadence | Harm is contained and recovery is verified |
| Rollback | Retained target, compatibility checks, traffic control, pending-work treatment | Baseline behavior returns and affected effects are reconciled |
For deployment, name the candidate and retained baseline before changing exposure. Google’s canary guidance compares a candidate with a control and ties evaluation to traffic management. The runbook should point to the application’s release controller and stopping rule rather than repeat the statistical design taught in 4.3.4.
For monitoring, reference the alert definition and its dashboard, not a screenshot of a healthy graph. Include both service failures and task-quality degradation. See 3.4.4 for selecting monitoring ownership and 4.6.3 for segmented alerts; this runbook says what the alerted owner does next. If the quality review is periodic rather than continuous, state that delay so an operator does not expect an immediate quality signal.
Make incident roles explicit
Google’s incident-management guidance separates incident command, operations, communications, and planning. The incident commander coordinates and assigns responsibilities; the operations team changes the system. The communications role issues updates, and a live incident state document preserves status, actions, and unresolved questions. Adapt those roles to team size, but preserve their responsibilities when one person holds several roles.
Record the declaration and handoff process. At a shift change, transfer incident command explicitly and confirm the receiving person’s acceptance. A list of names does not establish who commands an incident after its first responder leaves.
Include Claude-specific diagnostic references without turning every runbook into an API manual. Anthropic’s error page distinguishes 429 rate_limit_error from 529 overloaded_error, and warns that a tier spend-cap 429 lacks retry-after and persists until access resumes. A capacity playbook must identify which case it is treating before increasing retry traffic. Retain the Claude API request-id for Anthropic support; the same identifier is in an error body’s request_id. See 4.6.1 for the broader call record.
Assign responsibility and authority together
Use a RACI matrix (responsible, accountable, consulted, informed) as the team’s responsibility-assignment convention. The cited sources define the duties, not this format. “Responsible” performs the work; “accountable” owns the outcome and decision. Keep one accountable role per row so a responder does not need to negotiate authority during an incident.
Useful rows include release promotion, authorization-control changes, quality-alert triage, traffic reduction, rollback, reconciliation of uncertain writes, and stakeholder communication. Identify both the role and a maintained rota or escalation reference. A matrix naming an engineer who left the organization is less useful than a live on-call role.
State preauthorized emergency actions. For example, the incident commander may order a stop to automated writes while the operations lead executes the control; restoring writes may require the service and risk owners. Make that policy explicit. Do not require a routine approval meeting before an action already authorized to contain harm.
Specify what rollback cannot repair
Rollback returns execution to a retained configuration. It does not erase an email already sent or a transaction already committed. List external effects, pending jobs, in-flight operations, and compatibility risks. Require reconciliation before replaying uncertain writes, using the mechanisms specified in 6.4.3.
Retain the compatible prompt, model target, tool handler, retrieval configuration, and evaluation record together. If an external dependency or model target cannot be restored, document the tested degraded-service path instead of promising a rollback that cannot run. Assign an owner to revalidate that path as dependencies change.
Exercise these procedures with the receiving operators. Give them an alert, a release identifier, and a failure scenario while the architect observes silently. Record ambiguous instructions and missing permissions as defects, assign corrections, and repeat the affected step. NIST GOVERN 2.2 calls for training personnel to perform their duties; a rehearsal tests whether the documented duties are feasible.
Key distinctions and trade-offs
Runbook versus postmortem: A runbook guides action during a condition. A postmortem explains an incident and tracks improvements; see 4.6.4. An incident can reveal a missing runbook branch.
Accountability versus execution: The person authorized to approve promotion need not operate the release controller. Document both so approval does not become a vague shared responsibility.
Rollback versus compensation: Restoring software configuration and repairing business effects are separate operations, with potentially different owners and permissions.
Highly detailed procedures reduce interpretation but become stale when controls change. Keep exact operational steps close to their implementation, version the procedure with releases, and schedule exercises. Use the index and responsibility matrix to preserve discoverability across several services.
Architecture / decision scenario
An education provider runs an assistant that drafts enrollment messages and sends approved ones through a separate mail service. Its four-person platform team must restore a usable service within 20 minutes of a release incident. A candidate release passes offline checks but produces incorrect course dates after exposure reaches 10%.
The tempting response is to restore yesterday’s application and retry every unfinished job. The architect rejects that as an incomplete procedure: some messages may already have been sent, and the prompt and retrieval configuration can change independently of the application binary.
The runbook assigns the incident commander authority to halt automated sends, the operations lead responsibility for executing the application’s send-disable control and restoring the retained release bundle, and the enrollment lead ownership of affected-message reconciliation. The communications role updates support every ten minutes. These are illustrative operating choices, not provider defaults.
Before promotion, the deployment owner had recorded the candidate, baseline, and rollback target. During recovery, the operator verifies the baseline configuration and routes drafting to the approved degraded path. The mail-service owner resolves uncertain send outcomes before replay. Recovery ends when service checks pass and affected messages have an owned disposition, not when the deployment command exits. A rehearsal reveals that the backup operator lacks send-disable permission; the team repairs that gap before accepting the runbook.
Common exam traps
- Writing “roll back” without a retained target, control, or verification step.
- Assigning monitoring to a team without a responder and escalation path.
- Treating every 429 as a short-lived rate limit that retries resolve.
- Assuming restoration of software reverses external business effects.
- Calling a runbook complete before another operator exercises it.
What to remember
A runbook specifies triggers, actions, stop conditions, and verification. A responsibility matrix gives those actions performers and decision owners. Cover deployment, monitoring, incident response, and rollback, including uncertain effects and explicit command handoff. Test the package with the people who will operate it.
Knowledge check
An alert fires on Claude API HTTP 429 rate_limit_error responses. They carry no retry-after header and have kept failing for an hour regardless of traffic. The capacity runbook’s first step says to raise the SDK retry count. What should the operator do?
retry-after header and keeps failing until access resumes. These symptoms warrant checking for that cause before increasing retries, rather than assuming a transient rate limit. If the cap is confirmed, extra retries only add failing traffic; a 529 overload is a different error.After a release, an enrollment assistant starts drafting messages with wrong course dates, and some of those messages have already been sent through a separate mail service. Unsent jobs are still queued. The on-call engineer proposes restoring yesterday’s release and replaying every unfinished job. Which recovery procedure should the runbook require?
A responsibility matrix lists the platform team, the product team and the risk team as accountable for production rollback. During an incident, responders spend twenty minutes deciding who may approve it. How should the row change?
A severe incident is still open when the incident commander’s shift ends. The rota shows who is on call next. What should the runbook require before the commander leaves?
References
- NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- Google, Managing Incidents
- Google, Canarying Releases
- Anthropic, Errors