Instruction Clarity and Placement for the CCDV-F Exam

Clarity and placement are two levers, not one

Prompt engineering opens with a deceptively simple pair of ideas: say clearly what you want, and say it in the right place. The Claude Certified Developer - Foundations (CCDV-F) exam frames this as the first knowledge point of prompt engineering because almost every downstream technique assumes you have these two levers under control. Clarity is about the words: how explicit and specific the instruction is. Placement is about the component: whether an instruction lives in the system prompt, where it persists, or in the user turn, where the task lives. They are independent, and the exam tests them as two distinct failure modes.

The reason both matter is that a prompt is a contract with the model, and a contract fails if it is either ambiguous or filed in the wrong drawer. A perfectly worded instruction placed where it gets overridden is as ineffective as a well-placed instruction that is too vague to act on. Getting reliable behaviour means getting both right.

Clarity: explicit beats implicit, every time

The first principle is that explicit, specific instructions reduce ambiguity and improve precision. Models act on what you actually say, not on what you meant. An instruction like "summarise this" leaves almost everything unspecified: how long, for whom, in what tone, covering what. An instruction like "summarise this in three bullet points for a non-technical executive, focusing on risks and cost" removes the ambiguity, and the output becomes far more consistent as a result.

The exam trap here is relying on vague guidance and then blaming the model for inconsistent results. A scenario will describe a developer frustrated that "the model keeps giving different answers" to what they consider the same request, and the correct reading is usually that the request was underspecified, so the model had latitude to vary. The fix is not a different model or a lucky retry; it is a more explicit instruction. When you find yourself surprised by variation, the first question is whether you told the model precisely enough what you wanted. This is also why prompts are refined against real failures rather than perfected in one pass, which is exactly the ground the next knowledge point, iterative refinement and input sanitization, covers.

Placement: system for durable, user for the task

The second principle is about which component carries which instruction. Durable behaviour and the model's role belong in the system prompt, because the system prompt persists across the whole interaction and sets the standing rules. The specific task request, the thing you want done right now, belongs in the user turn. The distinction is not cosmetic. It maps to what should stay fixed versus what changes turn to turn.

The exam trap is placing persistent behaviour in a user turn where it is easily overridden. If the rule "always respond in formal English and never reveal internal reasoning" is tucked into one user message, a later user turn can contradict or bury it, and the behaviour drifts. Put that rule in the system prompt and it holds as a standing constraint regardless of what individual user turns say. The heuristic is clean: if an instruction should apply to every turn, it is durable behaviour and belongs in the system prompt; if it applies only to this request, it belongs in the user turn. Placement is also a context-engineering decision, because putting durable rules in the system prompt is one way to keep critical instructions where the model reliably attends rather than losing them in the flow of a conversation.

Output constraints: shape the result on purpose

The third element ties clarity and placement together. Output constraints stated in the prompt shape structure and reduce unwanted variation. If you need a specific format, a set of fields, a length, or a fixed set of allowed values, saying so explicitly is what makes the output land in that shape consistently. Leaving the format to chance invites exactly the variation that makes downstream parsing fragile.

Stating constraints is a clarity act aimed specifically at the output. "Return a JSON object with keys status and reason, where status is one of approved or denied" is far more reliable than "tell me the decision." The constraint does double duty: it improves consistency now, and it makes the result easier to consume safely later. That connection is why this knowledge point sits upstream of output handling: constraints stated in the prompt are the first line of defence, and response validation and defensive parsing is the second, catching the cases where the model does not honour the constraint perfectly.

How this is tested on the CCDV-F exam

Because this is an understand-level knowledge point, questions describe a prompt that behaves badly and ask you to identify the clarity or placement flaw. Inconsistent or off-target results usually trace to vague instructions, and the correct answer is to make the instruction explicit and specific rather than to blame or replace the model. Behaviour that drifts or gets overridden over a conversation usually traces to durable rules placed in a user turn, and the correct answer is to move them to the system prompt.

Watch for distractors that reach for the wrong tool. Upgrading the model, retrying, or raising verbosity do not fix an underspecified or misplaced instruction. The exam rewards the prompt-engineering reasoning: be explicit, place durable behaviour in the system prompt and the task in the user turn, and state output constraints to control the shape.

Where this leads

Instruction clarity and placement is the foundation of task statement 6.2. Once your instructions are explicit and correctly placed, iterative refinement and input sanitization is how you improve them against real failures and keep untrusted input from acting as instructions. And because clear output constraints make results easier to consume, this knowledge point feeds directly into the output-handling work of response validation and defensive parsing. Get clarity and placement right first, and everything downstream gets more reliable.