Claude Certified Engineers logoCCE

CCAR-P · Study Guide

← Domain 1: Solution Design & Architecture

1.5 · Lesson 5 of 6

Apply decomposition techniques for complex problem solving

What You Need to Know

Decomposition turns a problem that exceeds attention, tool scope, or verification into units that fit. Architects split by dependency (what must precede what), uncertainty (what is unknown and must be discovered), and verification boundaries (what can be checked independently). Adaptive decomposition is preferred when structure is unknown — codebases, open research, unfamiliar systems. Fixed pipelines work when dependencies are already clear.

Re-merging is not concatenation. Synthesis needs explicit criteria and a coverage check. Thin or missing categories after thorough specialist work almost always mean the coordinator never assigned those categories — a bad split, not a temperature or caching bug. Avoid the opposite failure too: dumping the whole problem into one monolithic prompt when units are separable.

Split dimensions

  • Dependency — order forced by prerequisites
  • Uncertainty — discover structure before committing to a fixed pipeline
  • Verification — units that can pass or fail independently
  • Attention/tool fit — each unit must fit the working set and available tools

Decision rules

  • Decompose by dependency, uncertainty, and verification boundaries.
  • Prefer adaptive splits when structure is unknown upfront.
  • Use fixed pipelines only when dependencies are already clear.
  • Re-merge with synthesis criteria and coverage checks.
  • Thin coverage after good specialist work means revise the split — do not blame temperature.

Why bad splits hide in "successful" runs

Specialists can execute assigned briefs perfectly and still produce incomplete outcomes if the coordinator omitted categories. Tracing only tool success misses the coverage hole. Professional designs attach a checklist to aggregation and treat empty categories as decomposition defects.

Checklist before you ship the split

  • Is structure known enough for a fixed order, or do you need a discovery wave?
  • Does every required category appear in some unit brief?
  • Can each unit be verified without reading the entire corpus?
  • Is re-merge defined as criteria + coverage, not paste-together?
  • Would a monolithic dump be tempting — and why is it wrong here?

Exam stems that show thorough specialist work with thin final coverage key on omitted coordinator categories. Distractors include temperature, caching, and "use a bigger model with the same split."

Exam application

Prefer adaptive discovery when structure is unknown; fixed order when deps are clear. Prefer answers that fix the split and coverage check. Reject monolithic whole-repo dumps and sampling excuses for missing assigned work.

Exam traps

  • Blaming temperature for missing categories

    When specialists complete assigned briefs but coverage is thin, the split omitted work. Sampling settings do not invent unassigned topics.

  • Fixed alphabetical pipeline for unknown structure

    Legacy codebases and open research need adaptive decomposition. A rigid A→B→C order pretends dependencies are known.

  • Single monolithic prompt with the whole repo or problem

    Dumping everything into one turn exceeds attention and verification boundaries. Decompose into units that fit tools and checks.

  • Re-merging without synthesis criteria or coverage checks

    Aggregation without a checklist produces confident reports that silently skip required categories.

Practice scenario

A multi-agent research workflow finishes with thorough specialist work, yet the final report covers only 2 of 5 required topic categories. Traces show specialists executed their assigned briefs fully. What is the most likely root cause?

Choose one answer

Build exercise

Adaptively decompose an unknown-codebase "add tests" goal

40 minutes

What you'll learn

  • Define verification and coverage before splitting
  • Use adaptive discovery when structure is unknown
  • Scope units to attention, tools, and checks
  • Re-merge with synthesis criteria and a coverage pass

  1. Step 1

    Frame the goal and verification boundaries

    For an unknown codebase "add tests" goal, list what done means: modules touched, critical paths, coverage floor, and tests that must run green. Separate discovery from implementation.

    Why: Decomposition without verification criteria cannot detect a bad split later.

    You should see: A written done definition and a coverage checklist with empty checkboxes.

  2. Step 2

    Decompose adaptively while structure is unknown

    First wave: map packages, entrypoints, and risk hotspots. Only then assign specialist (or sequential) units by dependency and uncertainty — not by alphabet.

    Why: Unknown structure favors adaptive splits. Fixed pipelines invent false order.

    You should see: A discovery note plus a second-wave task list tied to real modules.

  3. Step 3

    Assign units that fit attention, tools, and verification

    Each unit should be completable with a bounded working set and a clear check (files changed, tests added, command to run). Prefer fewer well-scoped units over a monolithic dump.

    Why: Exam stems punish dumping the whole repo into one prompt when units are separable.

    You should see: Unit cards: scope, inputs, tools, verification command, owner (agent or step).

  4. Step 4

    Re-merge with synthesis criteria and a coverage pass

    Before declaring success, walk the checklist. Thin or missing categories after thorough unit work mean revise the split — do not only rewrite prose.

    Why: Coverage gaps after good specialist work are decomposition failures.

    You should see: Checklist with every category marked covered or explicitly deferred with reason.

Sources