Vague vs Precise Instructions (CCAO-F)

An instruction only helps if Claude can act on it

Setting a standing instruction once is only valuable if the instruction is precise enough to change behavior. The CCAO-F exam treats telling vague from precise as an understand-level skill, because a vague instruction feels like it is doing something while actually giving Claude almost nothing to act on.

The classic example is "be professional." It sounds like a real directive, but it does not specify any concrete behavior, so different conversations interpret it differently and the output quality wanders. A precise instruction, by contrast, names measurable criteria that Claude can apply the same way every time. The difference between the two is the difference between an instruction that changes output and one that only feels reassuring.

Why vague instructions wander

A vague instruction leaves the important decisions unspecified, so Claude fills them in, and it fills them in differently across conversations. "Make the reports good and accurate" expresses a perfectly reasonable intention, but "good" and "accurate" are not behaviors; nothing concrete changed about how a report is written. One conversation might produce a terse report, another a verbose one, and both can claim to be following the instruction.

The result is variability. Because the instruction pins down nothing checkable, the quality of the output rides on factors the instruction never constrained. This is why intention is not enough: an instruction can carry exactly the right goal and still fail to move the output, because a goal is not an operational rule.

What precision looks like

A precise instruction replaces intentions with criteria you could check by inspection. Instead of "be professional," write "use a formal register, define any acronym on first use, and keep paragraphs under four sentences." Each clause is measurable: you can look at the output and confirm whether the register is formal, whether acronyms are defined, whether paragraphs stay under the limit. That checkability is what lets Claude apply the rule consistently.

The building blocks of precision are concrete: length limits ("under four sentences"), structural rules ("list each decision as its own bullet"), and explicit do or do-not behaviors ("define any acronym on first use," "never promise a refund we cannot honor"). And precision is not only about tone words. Making the tone word "formal" instead of "professional" is a small improvement; the real gain comes from adding checkable structural and behavioral criteria around it. Precision is about concrete rules, not swapping one adjective for another.

What the CCAO-F exam trips candidates on

The exam sets two traps. The first is assuming an instruction like "write good reports" will reliably improve output because it expresses the right intent. It expresses intent but specifies no behavior, so it does not reliably change anything; the credited answer rewrites it with concrete, checkable criteria. Right intention, wrong mechanism, is the tell.

The second is treating precision as only about tone words rather than concrete, checkable rules. Swapping "professional" for "formal" reads as making the instruction precise, but real precision comes from adding measurable criteria: structure, length, explicit behaviors. A question that offers a slightly nicer adjective as the "precise" option is testing this; the credited answer is the one with checkable rules. Both traps reward recognising precision as measurability, not phrasing.

Common misreadings to avoid

How this shows up on the exam

Domain 5 questions ask which of several instructions is most likely to actually change output. Choose the one with measurable, checkable criteria, not the one with the most reassuring adjectives. An instruction that only states intent, however well, is vague.

This understanding sets up the two-reader test for confirming precision before finalising an instruction, and it explains silent instruction failure, where vague wording fails without warning. It also grounds writing testable verification instructions and builds on the purpose of standing instructions.