Dependency Ordering in Decomposition (CCAR-P)

A list of tasks is not a decomposition

Splitting a problem into sub-tasks is only half of decomposition; the other half is capturing how those sub-tasks depend on one another. The Claude Certified Architect - Professional (CCAR-P) exam treats dependency ordering as an apply-level skill because a decomposition that lists sub-tasks without their dependencies loses the information that decides the architecture's shape, namely what must happen before what, and what can happen at once. Some sub-tasks are strictly ordered, verification before the action it gates, retrieval before the synthesis that uses it, and some are independent and can run in parallel. Getting this wrong is not a small error; it forces a redesign once the omission surfaces.

The dependency structure is what turns a flat list into an executable plan. It tells you which pieces must be sequenced and which can be parallelised, and it exposes the ordering constraints that a pattern has to respect. Capturing it explicitly at decomposition time is far cheaper than discovering a missed dependency after the architecture has been built around a wrong assumption.

Sequence what depends, parallelise what does not

The rule is straightforward once the dependencies are visible. Sub-tasks that consume another's output must be sequenced: if synthesis needs the retrieved documents, retrieval runs first; if an action depends on a verification passing, verification runs first. Sub-tasks that do not depend on each other are candidates for parallel execution, which reduces latency by doing independent work at once. The decomposition's job is to record which is which, so the pattern, a chain for the sequenced pieces, a parallelization or fan-out for the independent ones, can be chosen to match the real structure of the work.

The order that matters, not the order mentioned

A common failure is listing sub-tasks in the order a stakeholder happened to mention them, rather than the order their dependencies require. Stakeholders describe their process in narrative order, which need not match the execution order the dependencies demand. A decomposition that simply follows the order of mention can put an action before the verification that should gate it, or a synthesis before the retrieval it needs. The discipline is to derive the ordering from the actual data dependencies, what each sub-task needs as input, not from the sequence in which the problem was described.

Hidden dependencies defeat naive parallelism

The subtler trap is the hidden dependency: two sub-tasks that look independent but actually share a requirement, most often both needing the output of a verification or a setup step. Parallelising them appears safe, they seem unrelated, but because both depend on something that has not run yet, or on each other indirectly, the parallel execution produces wrong or inconsistent results. Spotting a hidden dependency means asking, for each pair you plan to parallelise, whether they truly share nothing, or whether both quietly rely on a common upstream output that must be sequenced first. Apparent independence is not enough; genuine independence is the requirement for parallelism.

What the CCAR-P exam trips candidates on

The exam tests two traps. The first is listing sub-tasks in the order they were mentioned by the stakeholder rather than the order their actual dependencies require. The credited answer re-derives the execution order from data dependencies, placing verification before action and retrieval before synthesis regardless of narrative order.

The second is parallelising two sub-tasks that appear independent but actually share a hidden dependency, such as both needing a verification step's output. The reliable reading checks apparent independence for a shared upstream requirement and sequences the pieces that turn out to depend on a common step, rather than running them concurrently on a false assumption of independence.

Common misreadings to avoid

How this shows up on the exam

Domain 1 questions on this knowledge point present a set of sub-tasks and ask for their execution order or whether some can run in parallel. The reliable reading derives the order from data dependencies rather than mention order, sequences dependent sub-tasks like verification-before-action, and checks apparently independent pairs for a hidden shared dependency before parallelising them.

Dependency ordering builds on the three-bucket decomposition and determines which workflow sub-pattern, chaining for sequenced work, parallelization for independent work, fits. It is also the precondition for valid orchestrator-subagent fan-out and fan-in, and a discovered ordering error triggers iterating the decomposition.