Iterating the Decomposition as Constraints Emerge (CCAR-P)

The decomposition is a first draft

An initial decomposition is made during discovery, when the picture is least complete, which means it is a hypothesis about how the problem breaks apart, not a settled answer. The Claude Certified Architect - Professional (CCAR-P) exam treats iterating the decomposition as an analyse-level skill because the mark of a good architect is revisiting that first draft when downstream work reveals it was wrong, rather than defending it. Choosing a pattern, selecting a reference architecture, and sketching the data flow all surface constraints the discovery step could not see, and some of those constraints contradict the original decomposition. When they do, the decomposition should change.

The most common contradiction is a data-classification error: a piece assumed to be static knowledge turns out to be live state. The correct response is to re-decompose that piece into a tool call to the system that owns the live state, not to patch around the wrong assumption inside the bucket where it was first placed. Re-decomposing propagates the corrected fact cleanly; patching builds further on the error.

New constraints surface after discovery

The reason the first draft is provisional is that discovery cannot see everything. It is only when you start choosing a pattern and a reference architecture that certain constraints become visible: that a data source is live rather than stable, that a dependency exists that was not obvious, that a piece assigned to Claude actually needs a guaranteed answer. These are constraints the decomposition should have accounted for but could not, because they emerge from the design work that follows it. Treating the decomposition as final means ignoring the very information the later steps exist to produce.

Re-decompose, do not patch

When a constraint contradicts the decomposition, there are two responses, and only one is right. Patching keeps the piece in its original bucket and works around the problem locally, adding a special case to handle the fact that the "static" data is actually live, for instance. Re-decomposing moves the piece to where it now belongs, into a tool call for the live-state case, and lets the corrected classification flow through the rest of the design. Patching accumulates hidden complexity built on a false premise; re-decomposing keeps the design honest. The exam rewards re-decomposing because it is the response that actually fixes the model of the problem rather than concealing the flaw.

A static decomposition is a warning sign

There is a diagnostic in all of this: a decomposition that never changes after its first draft is a sign it was not genuinely tested against the architecture constraints. Real design work almost always surfaces at least one thing the discovery-time decomposition got wrong, so a decomposition that survives untouched has probably not been pressure-tested. And the economics favour iterating early: revisiting a decomposition on paper is far cheaper than discovering the same flaw after implementation has started, when the fix means reworking built code rather than editing a plan. Iterating is not a sign of a poor initial decomposition; it is a sign the decomposition is being taken seriously.

What the CCAR-P exam trips candidates on

The exam tests two traps. The first is treating the initial three-bucket split as fixed once written down, even after later design work reveals a sub-task was miscategorised. The credited answer revisits the decomposition and moves the miscategorised piece to its correct owner, rather than defending the first draft.

The second is continuing to build against an outdated decomposition after discovering a piece of "Claude work" is actually deterministic logic that belongs in code. The reliable reading stops, re-decomposes that piece into the existing-systems bucket, and lets the correction propagate, instead of pressing on with an implementation premised on the wrong assignment.

Common misreadings to avoid

How this shows up on the exam

Domain 1 questions on this knowledge point describe a late discovery that contradicts an earlier decomposition and ask how to respond. The reliable reading treats the decomposition as a revisable hypothesis, re-decomposes the affected piece to its correct owner, most often a static-to-live-state correction into a tool call, and rejects both defending the fixed first draft and patching around the flaw.

Iterating builds on recognising work that does not belong with Claude and dependency ordering in decomposition, and it mirrors the revisability of the architecture brief. The live-state correction draws directly on live state vs static knowledge, and it precedes tuning decomposition granularity.