Decomposition Granularity: Too Coarse vs Too Fine (CCAR-P)

How finely to cut the problem

Decomposition is not only about which pieces exist and how they depend on each other; it is also about how finely to cut. The Claude Certified Architect - Professional (CCAR-P) exam treats granularity as an evaluate-level skill because both extremes are failures, and the right level is a judgement, not a formula. Cut too coarsely and different kinds of work get merged into one unit that hides its own seams; cut too finely and coherent work is shattered into fragments that cost more to coordinate than they are worth. The target is the level at which each unit has a single owner and a single failure mode.

That target is precise enough to be useful. A unit with a single owner, Claude, an existing system, or a human, and a single failure mode is granular enough that its owner and its way of going wrong are unambiguous, and no more granular than that. Everything coarser hides distinctions that matter; everything finer adds coordination without adding clarity.

Too coarse hides the seams

Decomposing too coarsely lumps distinct kinds of work into one unit, and the danger is that the merged unit hides sub-tasks that belong to different buckets or need different patterns. A single step labelled "Claude handles the order processing" might actually contain a deterministic calculation, a live-state lookup, and a judgment call, three pieces with three different owners, concealed inside one bucket. Because the coarse unit has more than one owner and more than one failure mode, you cannot assign it correctly or reason about how it fails. The seams are still there; the coarse decomposition has just papered over them, which is exactly how deterministic work ends up wrongly routed through the model.

Too fine fragments coherent work

The opposite error splits a single coherent task into many tiny units. A judgment task that is naturally one decision, weigh these factors and produce a recommendation, broken into a dozen micro-calls, adds coordination overhead, latency, and cost with no gain in quality or auditability. The fragments have to be orchestrated, passed between, and reassembled, and each hop adds failure surface. Fine-grained decomposition feels rigorous but often buys nothing: the work was already a single owner with a single failure mode, and splitting it just multiplies the moving parts. Over-splitting is as much a design flaw as over-merging, and it is easy to mistake for thoroughness.

Re-check granularity against the pattern

Granularity is not fixed once and forgotten. Once a candidate pattern is chosen, the granularity should be re-checked against the pattern-selection factors, especially error cost and observability. A pattern with a tight observability requirement may need finer units so each step is separately inspectable; a high error-cost step may need to be its own unit so it can be gated. Conversely, a pattern may reveal that some fine units can be merged without losing anything. The interaction runs both ways: the pattern informs the right granularity, and the granularity has to support the pattern. Re-checking after the pattern is chosen is how you keep the two consistent.

What the CCAR-P exam trips candidates on

The exam tests two traps. The first is merging a deterministic calculation and a judgment call into one "Claude step" because they happen to occur back to back in the user's workflow. The credited answer splits them, since they have different owners, code for the calculation, Claude for the judgment, and different failure modes, and the coarse merge hid that distinction.

The second is splitting a single coherent judgment task into many tiny Claude calls, adding latency and coordination cost without improving quality or auditability. The reliable reading recognises the over-split, notes that the fragments share one owner and one failure mode, and merges them back into the single unit they naturally form.

Common misreadings to avoid

How this shows up on the exam

Domain 1 questions on this knowledge point present a decomposition that is too coarse or too fine and ask you to right-size it. The reliable reading targets the level where each unit has a single owner and a single failure mode, splits coarse units that hide different owners or patterns, merges over-split fragments that share an owner, and re-checks granularity against the chosen pattern's error-cost and observability requirements.

Granularity is the evaluate-level capstone of the decomposition task, building on iterating the decomposition and the ownership logic of the three-bucket decomposition. It connects to coordinator task decomposition quality in multi-agent design and is re-checked against the five deciding factors.