CClaudeMentor
All articles
Architect
16 min read

CCA Domain 4 Study Guide: Prompt Engineering and Structured Outputs

Research-verified study guide for Domain 4 — output contracts, prompt architecture, specificity without overconstraint, JSON and schema conformance, validation and retry loops, evaluation, scenario traps, and a seven-day plan.

Purpose and accuracy note

This guide focuses on reliable prompt design and machine-consumable output. It avoids unsupported claims that one markup format is universally superior or that hidden chain-of-thought should be requested. Anthropic’s public certification announcement does not publish domain percentages; use the current candidate guide or partner portal for authoritative weighting.

1. Start with the output contract

Before writing a prompt, define success:

  • What decision or artifact must be produced?
  • Which source material is authoritative?
  • Who is the audience?
  • What fields, length, tone, and exclusions are required?
  • What should happen when information is missing?
  • How will the result be validated?

The best prompt is not the longest. It is the shortest prompt that removes material ambiguity. Replace “analyze this” with an explicit task, evaluation criteria, evidence requirements, and output contract.

Example:

Weak: Review this support ticket.

Stronger: Classify the ticket as billing, technical, account, or other. Assign urgency low, medium, or high using the criteria below. Quote one supporting passage. If the ticket lacks enough evidence, set urgency to null and explain the missing evidence in one sentence.

2. Prompt architecture

A robust prompt commonly contains:

  • Task: the action to perform.
  • Context: only facts needed for the task.
  • Source data: clearly delimited from instructions.
  • Criteria: how to judge or classify.
  • Constraints: boundaries, exclusions, and safety rules.
  • Output contract: schema or precise human-readable format.
  • Examples: representative inputs and correct outputs, including edge cases.

Put stable high-level behavior in the system prompt and request-specific details in the user message. Do not repeat conflicting instructions across layers. When a prompt has grown through many patches, audit it for contradictions, obsolete rules, and duplicate requirements.

XML tags are useful delimiters for sections such as <instructions>, <document>, and <examples>. Their main value is separation and hierarchy, not a promise that XML is always the best output format. Use JSON when downstream software expects JSON, structured outputs when schema conformance is required, and natural language when humans need a readable explanation.

3. Specificity without overconstraint

Good constraints reduce ambiguity; bad constraints conflict or force fabrication. “Comprehensive and no more than 50 words” may be impossible. “Return every field, even if absent” invites invented values unless missing-data behavior is defined.

Prefer observable criteria:

  • Instead of “be concise,” say “use at most five bullets, each under 20 words.”
  • Instead of “identify serious issues,” define severity thresholds.
  • Instead of “use a professional tone,” identify the audience and communication goal.

Ask for evidence or a brief rationale when it improves auditability. Do not require disclosure of private hidden reasoning. A concise explanation, cited evidence, intermediate calculation, or checklist is usually the correct observable artifact.

4. Examples and edge cases

Few-shot examples teach boundaries better than abstract prose. Use diverse, realistic examples that demonstrate:

  • the common case;
  • an ambiguous case;
  • missing information;
  • an out-of-scope request;
  • the exact output shape.

Examples must not conflict with the written rule. A model often follows the demonstrated pattern, so a flawed example can override a carefully worded instruction. Avoid examples that leak private data or accidentally bias all outputs toward one category.

5. Structured outputs

When valid JSON matching a schema is a hard requirement, use Anthropic’s structured outputs rather than relying only on “return JSON” in prose. Current documentation describes two main approaches: JSON outputs for structured responses and strict tool use for validated tool inputs.

Design the schema deliberately:

  • Use enums for closed categories.
  • Mark fields required only when the source must contain them.
  • Use nullable or optional fields when absence is legitimate.
  • Add descriptions that clarify business meaning.
  • Use arrays for repeated items and nested objects for real hierarchy.
  • Avoid unbounded free-form blobs when downstream code needs typed data.

Schema validity is not semantic truth. A perfectly valid JSON object can still contain a wrong classification. Validate business rules, provenance, ranges, and cross-field consistency after parsing.

Citations and structured outputs serve different response shapes. Anthropic’s citations documentation says citations interleave blocks with text and are incompatible with strict structured outputs. If both traceability and structured data are required, redesign the flow—for example, capture source identifiers as ordinary schema fields or use separate passes, then validate the mapping.

6. Choosing between JSON output and tool use

Use structured JSON output when the model’s final answer itself is data: extraction, classification, routing, or generation of a typed record.

Use a tool call when the system must perform an action or query an external capability. Strict tool use validates the tool inputs, but your application must still authenticate, authorize, execute, handle errors, and return the result.

Do not create a fake tool solely to format every response if native structured output solves the contract more directly. Conversely, do not use JSON output as a substitute for an actual side effect such as creating a ticket.

7. Reliability patterns

For extraction, tell Claude to use only the supplied source and define missing-value behavior. Delimit untrusted data so it is not mistaken for instruction. For classification, define mutually exclusive labels and tie-break rules. For summarization, identify audience, emphasis, length, and whether quotations or citations are required.

For long documents, place the documents and metadata clearly, then state the task and evaluation criteria unambiguously. Test prompt behavior across realistic lengths rather than assuming a structure that worked on one small example will scale.

When parsing streamed structured data, remember that partial chunks may not yet be valid JSON. Accumulate and parse safely, or use the supported SDK helpers. Never execute a partial tool argument.

8. High-frequency scenario traps

  • “Act as an expert” without criteria or relevant context. Role labels cannot replace a precise task.
  • Claiming XML is always more reliable than JSON. Select the format required by the consumer.
  • Asking for chain-of-thought. Request concise evidence or a verifiable rationale instead.
  • Saying “return JSON” when schema conformance is mandatory. Use structured outputs.
  • Making every field required. Legitimately missing facts should be nullable or optional.
  • Retrying extraction until a missing fact appears. That encourages fabrication; return missing status.
  • Conflicting examples and instructions. Align them and test edge cases.
  • Treating schema compliance as factual accuracy. Apply semantic validation.
  • Combining strict structured output with native citation blocks. These response modes are incompatible.
  • Mixing instructions into untrusted source text. Delimit source material clearly.
  • Overloaded prompts containing years of amendments. Refactor and remove conflicts.
  • Parsing incomplete streamed JSON as if it were final.

9. Rapid decision framework

  • Is the output for a human or a machine?
  • Is exact schema conformance mandatory?
  • Does the request need external data or a side effect?
  • Can information legitimately be absent?
  • Is provenance required, and in what representation?
  • What programmatic and semantic checks will run?

Human explanation → clear prose format.

Machine record → structured output plus validation.

External action → tool use plus authorization.

Quoted traceability → citations or explicit source fields, depending on the output contract.

10. Seven-day revision plan

  • Day 1: Rewrite ten vague prompts using explicit tasks and success criteria.
  • Day 2: Practice separating instructions, context, documents, and examples with delimiters.
  • Day 3: Create examples for common, ambiguous, missing, and out-of-scope cases.
  • Day 4: Design JSON schemas using enums, arrays, nesting, and nullable fields.
  • Day 5: Compare structured output, tool use, citations, and plain prose across scenarios.
  • Day 6: Add syntactic and semantic validators; test malformed, missing, and contradictory inputs.
  • Day 7: Solve 20 scenarios and explain why the chosen output contract is appropriate.

Final checklist

  • I can turn a vague request into observable success criteria.
  • I can separate instructions from untrusted source data.
  • I use examples to clarify boundaries and edge cases.
  • I can design a schema that represents missing information honestly.
  • I know the difference between structured output and a tool action.
  • I validate meaning as well as JSON shape.
  • I understand the structured-output/citations compatibility constraint.

Official sources

Take the diagnosticBuild a study plan

Keep reading