Recognising Over-Delegation and Halo Delegation for the CCAO-F Exam

Two ways a good map goes wrong

Even a team that knows the three delegation criteria can still misapply them, and this knowledge point names the two ways it most often happens. The Claude Certified Associate - Foundations (CCAO-F) exam sets recognising over-delegation and halo delegation at analyse level, because both failures wear the disguise of reasonable judgement: they are what happens when Claude's success bleeds across the boundary between steps that should have been judged separately.

Both failures share a root cause: letting one step's outcome contaminate another step's classification. Over-delegation lets draft quality justify handing over a riskier step; halo delegation lets a neighbouring success justify delegating the next step. In each, the criteria, reversibility, stakes, and accountability, stop being applied to the step in front of you and get replaced by an inference from elsewhere. Naming the two patterns is what lets you catch them.

Over-delegation: draft quality is not a license

Over-delegation is giving Claude more than its risk profile justifies, on the strength of how well it drafted. Claude produces an excellent redline, so the team lets it approve the changes; it drafts a clean contract, so the team lets it send. The move feels earned, the drafting really was good, but it confuses two different things. Draft quality shows Claude can produce a draft. It says nothing about whether a decision-making or execution step, approving, sending, committing, should be delegated, because those steps are governed by their own reversibility and accountability, not by how good an earlier draft was.

This is the failure the two-teams contrast in workflow integration turns on: the team that pointed Claude at the whole process and let it approve low-risk clauses because it drafted them well. A high-accountability or irreversible step handed to Claude because of upstream draft quality is over-delegation, full stop. The corrective is to notice that "it drafted this well" is simply not an argument about whether the decision or the send should be Claude's. Those are decided by reversibility and accountability, and draft quality does not enter into it.

Halo delegation: neighbours are not evidence

Halo delegation is the sibling failure: judging a step by the success of the step before it. The previous step was delegated and went well, so the next step gets handed over too, riding the halo of that success. But adjacency is not evidence. Step N succeeding says nothing about whether step N+1 is reversible, low-stakes, or human-accountable; those are properties of step N+1 itself, and they have to be checked directly. A successful neighbour creates a feeling of momentum that quietly substitutes for the analysis.

The distinction between the two failures is worth holding precisely. Over-delegation is driven by draft quality, "it wrote this well, so let it decide". Halo delegation is driven by sequence, "the last step worked, so delegate this one". They can occur together, but they are different substitutions, and both are cured by the same rule: every step must be re-evaluated against the three criteria independently of its neighbours. No step inherits a classification from what came before it, whether that inheritance is draft quality or a successful adjacent delegation.

What the CCAO-F exam trips candidates on

The exam tests two traps, one per failure. The first is letting Claude approve or send an output because the drafted version was high quality, which is over-delegation. A scenario may show Claude drafting excellently and then being handed the approval or the send; the credited reading is that draft quality does not justify delegating the decision or the irreversible action. The second trap is assuming a step is safe to delegate because the adjacent step in the workflow was successfully delegated, which is halo delegation. The exam wants each step judged on its own reversibility, stakes, and accountability, with neither draft quality nor a neighbour's success allowed to stand in for that judgement.

Both traps reward the same corrective instinct: when you feel the pull to delegate a step because of something good that happened elsewhere in the workflow, stop and apply the three criteria to the step itself. Independence of judgement, step by step, is the whole defence.

Common misreadings to avoid

How this shows up on the exam

Domain 4 questions on this knowledge point show a step being delegated on the strength of good drafting or a successful neighbouring step and ask what is wrong. The reliable reading is to name over-delegation (draft quality justifying a riskier step) or halo delegation (a neighbour's success justifying the next step), and to correct both by re-evaluating each step against reversibility, stakes, and accountability independently.

This knowledge point builds on stakes and accountability as delegation criteria and reversibility, the criteria both failures abandon. It leads into diagnosing a collapsed collaborative step, where a related drift, a review gate quietly going unstaffed, turns a mapped collaborative step into an unintended automation.