Claude Certification Guide CCAR-P

Curriculum › Solution Design & Architecture · 17% of the exam

From business problem to Claude solution

What you’ll be able to do

  • Frame a business problem as a task, a user, a current baseline and an error-cost profile before choosing any technology
  • Decide which parts of a problem need a language model and which belong in deterministic code, search or process change
  • Map a framed problem to a solution shape: assistant, automation, or agent, with the right degree of human involvement
  • Align a solution to a primary business value pillar (efficiency, transformation, productivity, cost, performance SLAs) and name the metric that proves it
  • Recognize tensions between pillars and make the trade-off explicit to stakeholders

What you need to know

Frame the problem before you touch the model

Business requests usually arrive as solutions ("we want a chatbot", "can we put an agent on this?"). The architect's first job is to turn them back into a problem statement precise enough to design against. Four questions do most of the work:

  • What task, for whom? Name the person or system that does the work today and the unit of work: one claim, one ticket, one contract, one pull request.
  • What is the baseline? Time per unit, volume, backlog, error rate, cost per unit, customer wait. Without a baseline, no one can later say whether the solution worked.
  • What does "good" mean? An acceptance bar that a domain expert would sign: which fields must be right, what tone is acceptable, what must never happen.
  • What does an error cost, and to whom? A wrong product suggestion costs little; a wrong denial of an insurance claim or a wrong dosage instruction costs a lot. The asymmetry of error cost decides how much autonomy is acceptable and where humans stay in the loop.

Not every part of the problem is an LLM problem

Claude earns its place where the work involves unstructured language and judgment: reading messy documents, interpreting intent, drafting, summarizing, classifying under fuzzy criteria, reasoning across sources. It is the wrong tool for logic that is already deterministic. Tax calculations, eligibility rules that are written down as thresholds, joins across database tables and access decisions belong in code, where they are cheap, exact and auditable.

Most good designs are hybrids. A claims-intake solution might use Claude to extract and normalize fields from free-text submissions, deterministic rules to check policy coverage, and a human adjuster for denials. Drawing that boundary early prevents two common failures: asking the model to do arithmetic or policy lookups it can get subtly wrong, and building elaborate code to parse language that a model handles well.

Sometimes the honest answer is that the bottleneck is a process or data problem. If tickets are slow because three teams must approve every refund, a faster draft reply changes nothing. Say so.

Choose the solution shape

  • Assistant or copilot: a human does the task and Claude helps (drafts, summaries, suggested next steps). Lowest risk, value shows up as efficiency or productivity, adoption depends on fitting the existing tool.
  • Automation: Claude performs a bounded step end to end inside a defined workflow, with validation and exception routing. Value shows up as cost and throughput; requires clear acceptance criteria and a path for cases the system should not handle.
  • Agent: Claude chooses steps and tools to reach a goal. Justified when the path genuinely cannot be fixed in advance; it carries more cost, latency variance and governance work (lesson 1.2).

Error cost decides the human role. High-volume, low-stakes, reversible actions can run autonomously with sampling-based review. High-stakes or irreversible actions keep a human decision point, and the design should make that review fast rather than pretend it is unnecessary.

Align to a value pillar and measure it

Executives fund outcomes. Tie each solution to one primary pillar and a metric that moves when the solution works:

  • Efficiency: less time or effort per unit of work (minutes per ticket, handling time).
  • Productivity: more output per person or team (cases closed per analyst, features shipped per sprint).
  • Cost: lower fully loaded cost per outcome, which includes model usage, infrastructure, human review and rework, not just the API bill.
  • Transformation: a capability that was not practical before, such as reviewing every contract instead of a sample, or offering support in languages the team never staffed.
  • Performance SLAs: commitments on latency, availability, accuracy or turnaround that the business has made, or wants to make, to customers or internal teams.

Pillars pull against each other. Tight latency SLAs may rule out multi-step agentic designs or the largest model; a cost target may force batching that breaks a turnaround SLA; a transformation goal (review everything) may increase total spend while cutting cost per item. A professional design names the primary pillar, states the guardrail metrics the others impose ("cost per resolved case down, while first-response latency stays within the agreed SLA and escalation accuracy does not drop"), and gets stakeholders to agree to that trade-off before building.

Count the whole cost of an outcome

ROI claims fail most often because they count model output, not resolved outcomes. A drafting assistant that saves four minutes per ticket but adds three minutes of checking saves one minute. An automation with a low error rate can still lose money if each error triggers an expensive manual correction or a customer escalation. Measure the business unit end to end, compare against the baseline, and include review and error handling in the number.

Key concept

A Claude solution is defined by a business task, its baseline and its error cost, and is justified by one primary value pillar measured end to end; the model choice comes after that, not before.

Questions in this area describe an eager stakeholder or an impressive demo. The right answer usually reframes toward the measurable outcome, keeps deterministic logic in code, sets autonomy by error cost, or picks the metric that reflects the business result rather than model activity.

Practice scenario

ScenarioA logistics company's VP asks for "an AI agent that handles all carrier invoice disputes." Today, eight analysts process about 2,000 disputes a month; median resolution takes six days, mostly waiting for analysts to compare invoice lines to contracted rates in a rate table. Roughly a tenth of disputes involve a judgment call about damaged goods. The VP's slide lists efficiency, cost reduction, transformation and a new 48-hour resolution SLA as goals.
Work it through, then open this

Reframe first. The unit is one dispute; the baseline is six days and the analyst time per dispute. The slow step is a rate comparison, which is deterministic once the invoice lines are extracted, so Claude’s job is extracting and normalizing line items from varied invoice formats, while code compares them to the rate table. The damaged-goods judgment calls are higher stakes and lower volume: Claude can assemble evidence and draft a recommendation, but an analyst decides. That is an automation with exception routing, not a free-roaming agent.

For value, pick the 48-hour SLA as the primary pillar, because it is what the business is committing to. Cost per resolved dispute (including analyst review time) and error rate on approved credits are the guardrails. Make clear to the VP that “transformation” is not what this delivers, and that claiming every pillar would hide the trade-off between speed and review depth.

Build exercise — Write a one-page solution frame

Advanced · 40 min

What you’ll learn

  • Turning a solution-shaped request into a problem statement with a baseline
  • Drawing the boundary between model work, deterministic code and human decisions
  • Choosing a primary value pillar with guardrail metrics

  1. Pick a real request from your organization and write the task, the user, the unit of work, the current baseline numbers and the cost of one error, in five lines.

    • Why: Every later design and evaluation decision depends on knowing what is measured today and what a mistake costs.
    • You should see: At least one baseline number you had to go and find, and an error-cost statement that differs between case types.

  2. Split the workflow into steps and label each one as model (language/judgment), code (deterministic), or human (accountable decision).

    • Why: Hybrid boundaries keep exact logic exact and put the model where it adds value.
    • You should see: Fewer model steps than the original request implied, and at least one step that is pure code.

  3. Name one primary value pillar, its success metric and two guardrail metrics from the other pillars, including fully loaded cost per outcome.

    • Why: Stakeholders need to agree what is being optimized and what must not get worse.
    • You should see: A sentence of the form “X improves from A to B while Y and Z stay within limits”, which a sponsor could sign.

Exam traps

Starting from “where can we use Claude?” instead of from a business outcome and its baseline

Technology-first framing produces demos without a measurable result. Start from the task, the baseline and what improvement would be worth.

Using an LLM for logic that is deterministic and auditable in code

Thresholds, calculations and lookups are cheaper and exact in code. Use Claude for the language and judgment around them.

Measuring success with model-centric proxies (tokens, accuracy on a demo set) instead of the business metric

Proxies can improve while the business outcome does not. Measure the unit of work end to end against the baseline.

Claiming every value pillar at once, so no trade-off is ever decided

Pillars conflict, for example latency SLAs against cost. Name a primary pillar and set the others as guardrails.

Ignoring the cost of human review and error correction when computing ROI

Review time and rework can cancel the savings. Fully loaded cost per resolved outcome is the honest number.

Defaulting to full autonomy when the error cost calls for a human decision point

Autonomy should follow error cost and reversibility. Keep humans on high-stakes decisions and make their review efficient.

Sources

Quick check

An insurer's eligibility rules are written as explicit thresholds in an underwriting manual, but applications arrive as free-form text with attachments. The team proposes putting the whole manual in the prompt and letting Claude decide eligibility. Compliance requires every decision to be explainable and reproducible. Which design is most appropriate?