← Domain 6: Prompt and Context Engineering

6.3 · 2.6% of the exam · Topic 3 of 3

Output Handling

A confident answer is still model output. Structured output makes the shape parseable. Your code validates the values, parses defensively, and refuses a field the source does not support.

Learning objectives

Use a schema when a program will read the answer.
Validate business rules after the schema succeeds.
Parse only a finished, typed block, and reject what does not match.
Treat confident prose, invented citations, and filled-in blanks as claims to check.

Detailed theory

What this skill covers

Output handling is 2.6% of the exam: structured outputs, response validation, defensive parsing, and skepticism toward confident model output.

The prompt asked for a shape. This topic is what your program does with the text that came back. The model is not the system of record.

Structured output

Structured outputs constrain the response to a schema. JSON outputs use output_config.format with a JSON schema. Strict tool use validates tool names and inputs against the tool schema. The older output_format field is a transition path. New calls use output_config.

A schema stops a class of failures: missing braces, a string where the program expected an array, a tool input that does not match the parameters. It does not stop a refund amount that parses and is still wrong. Grammar and truth are different checks.

Ask for a field only when the program can use it. A required date on a document that may lack a date pressures the model to fill one in. Optional or nullable fields are how you let the model say the value is absent.

output_config: {
  format: {
    type: "json_schema",
    schema: {
      type: "object",
      additionalProperties: false,
      properties: {
        decision: { type: "string", enum: ["approve", "refuse"] },
        amount: { type: ["number", "null"] },
        date: { type: ["string", "null"] }
      },
      required: ["decision", "amount", "date"]
    }
  }
}

Response validation

Parse first, then validate. Schema success means the types match. Your rules decide whether the value is allowed: the amount is under the cap, the id exists, the enum is one you handle, the line items sum to the total.

On failure, do not ship the object. A retry that helps includes the validation error in the next user turn so the model sees what failed. A second call with the same messages is another sample and often repeats the same mistake.

If the source you sent does not contain the fact, fail the check or return null. Retrying cannot create a department that was never in the document. That case goes to a person, or stays null.

Defensive parsing

Read content by block type. A thinking block is not the answer. A text block is not JSON until you parse it. If stop_reason is max_tokens, the text is a prefix. Do not repair a truncated object by guessing the missing braces.

Without structured outputs, a model may wrap JSON in prose or add a trailing comma. Extract only when the slice parses. If it does not, reject the turn. Do not eval the string, do not exec it, and do not pass it to a template engine.

Tool arguments that are not strict need the same defense. A tool name you did not define is not a call you run. A string that looks like a path is not a path you open until your allow-list says so.

Skepticism toward confident output

Claude will state a number, a citation, and a policy quote in a confident tone when the window does not contain them. Confidence is the style of the completion. It is not a probability you can read off the sentence.

Check claims against the source you provided, or retrieve them again with a tool whose result you trust. A citation the model wrote is a string. If that string is not in the document, the citation failed. Do not ask the model whether it is sure. Ask the data.

The dangerous path is a confident answer that a parser accepts. A schema-valid amount, a fluent letter, and a tool call with a real-looking id can all be wrong. The human or the rule sits after the model, on the action.

Core concepts

Structured output

What: A response constrained by output_config.format, or a tool input constrained by strict tool use.
Why: The program receives a shape it can parse.
When: A later step reads fields rather than prose.
When not: You need the fields to be true. That is validation against the source.

Response validation

What: Checks you run after parsing: ranges, sums, known ids, and allowed enums.
Why: A valid document can still violate the policy.
When: The schema succeeded and you are about to store or act.
When not: The turn is truncated. Fix the stop before you validate a prefix.

Defensive parsing

What: Accept only a finished block that parses. Reject prose, prefixes, and unexpected types.
Why: Model text is not code and not a guarantee.
When: You turn a Messages response into an object in your process.
When not: You are showing the assistant's prose to a person with no further action.

Confident output

What: A fluent claim, including a citation or a filled blank, with no extra evidence attached.
Why: Tone does not measure support in the source.
When: You decide whether to trust a field.
When not: The field matched a check you already ran. Then the check is the reason, not the tone.

Validation retry

What: A new call that includes the specific validation failure.
Why: The model otherwise repeats the sample that already failed.
When: The source contains the fact and the shape or the rule missed it.
When not: The source never had the fact. Retrying asks the model to invent it.

Practical examples

The well-formed wrong total

Structured output returns decision approve, amount 500, date null. The schema matches. The line items in the user message sum to 450. A client stores 500 because JSON.parse succeeded.

The parser did its job. The sum check did not run. Fail the object, and if you retry, include "line items sum to 450, stated total is 500." Do not ask for a higher temperature.

The citation that is not in the page

The answer quotes a statute and a section number in a confident paragraph. The page you sent does not contain that section. The product shows the quote to a customer.

The quote is a claim. Compare it to the page, or leave it out. A second call that says "be more careful" can produce a different confident quote. The check is a string match against the source, or a human.

Claude-specific considerations

JSON structured output is output_config.format with a JSON schema. Strict tool use constrains tool inputs.
output_format is the older field. New requests use output_config.
A required field the source may lack pushes the model to fill it. Make that field nullable.
Schema-valid JSON can still fail a sum, an id lookup, or a policy cap.
Read blocks by type. Do not parse a thinking block or a max_tokens prefix as the object.
A validation retry includes the error. An identical second call is only another sample.
A citation is text. It counts if it occurs in the source you trust.

Architecture decisions

SituationChooseBecause

A service will store fields from the answer.Structured output, then your own rules.The schema gets you an object. The rules get you an allowed object.

The document has no department and the schema required one.Null, or a person. Do not retry for a value the source lacks.The model would be inventing the field.

The total does not match the lines, and the lines are in the prompt.Reject, and retry with that discrepancy.The source contains the information to correct.

stop_reason is max_tokens and the JSON is cut off.Continue or raise the cap, then parse.A prefix is not a document.

The prose sounds certain and names a source you did not provide.Drop the claim or verify it with a tool.Confidence is not a citation.

Tradeoffs

A stricter schema rejects more bad shapes and also rejects legitimate answers that do not fit. A looser parse ships more turns and more inventions. Skepticism costs a check on every action and saves the action you cannot undo.

AxisTrust the textCheck, then act

ShapeA sentence that says "return JSON."output_config.format.

ValuesSchema success.A business rule after the schema.

FailureThe same request again.A retry that includes the validation error.

CitationsFluent quotes.A match against the source you sent.

Quick reference

Structured output is a schema on the response or strict checking on tool inputs.
Use output_config.format for JSON. A prompt sentence is a weaker constraint.
Nullable fields are how you allow absence. Required fields pressure the model to fill them.
Parse, then apply business rules: sums, caps, known ids.
A schema-valid object can still be wrong.
On failure, retry with the specific error only when the source contains the fact.
Do not parse a thinking block or a max_tokens prefix as the answer.
Do not eval or exec model text.
A confident citation counts when you find it in the source, not when it sounds specific.
The model is not the system of record. The action sits behind your check.

Decision rules for the exam

If the question says…The answer is likely…

"JSON.parse succeeded"Still run the business check

"the date was required and the receipt has none"Make the field nullable. Do not retry for a date

"lines sum to 450 and the total is 500"Reject and retry with that discrepancy

"the JSON ends mid-string and stop_reason is max_tokens"Finish the turn, then parse

"the model says it is very confident"Ignore the tone. Check the source

"a citation the prompt never contained"Drop it or verify it outside the prose

"tool input is not strict"Validate before you run the tool

"the same prompt, second try"A new sample, unless you included the error

Common exam traps

TrapCorrect answer

Structured output means the facts are correct.It means the shape matches the schema.

A required field is safer than a nullable one.Required fields invent values when the source is silent.

Asking the model if it is sure is a validation.Validation is your rule or a comparison to the source.

Repair truncated JSON by adding braces.A max_tokens prefix is unfinished. Continue the turn.

Fluent text with a section number is a citation.The section has to appear in the source you trust.

Open the Domain 6 sheet

Exam tips

Separate shape from truth. The stem usually offers a schema as if it replaced the business rule.
If the fact is absent from the source, the answer is null or a person, not another sample.
Confidence language in the stem is a distractor. Look for a check.

Common mistakes

Storing the object because it matched the schema.
Run the sum, the cap, and the id lookup before the write.
Requiring a date the receipt may not have.
Make the date nullable and treat null as unknown.
Retrying an identical prompt after a bad total.
Include the validation error so the next sample has the miss.
Showing a model-written citation because the paragraph was confident.
Display the quote only when it is in the source.

Practice questions

Original questions for this topic. They are study items, not questions from the live exam.

Scenario questions

Two documents, two failures

Document A lists line items that sum to 450 and a total of 500. Document B has no department. Both calls use a schema that requires department and total. A lead wants one retry policy for every validation failure.

Which handling matches the two documents?

Option ARetry both with the same prompt so the model gets another chanceOption BRetry A with the sum discrepancy. Leave B null or with a person, because the department is not in the sourceOption CAccept both, because the schema returned valuesOption DRetry B only, and trust A's total because 500 is a round number

Build exercise

Put a check behind a schema

Intermediate · 35 minutes

What you will learn

What a schema guarantees.
Which failures are retryable.
How a confident string gets verified.

Step 1
Write the schema
Fields: decision, amount, date, citation. Date and citation are nullable. Decision is approve or refuse.
Why: Absence has to be representable.
You should see: A field list with nulls where the source may be silent.
Step 2
Add two rules
Amount must equal the sum of line items when the decision is approve. Citation, if present, must occur in the source text.
Why: These rules are outside the schema.
You should see: Two checks that run after parse.
Step 3
Sort three failures
Label each: truncated JSON, sum mismatch, department absent from a second document. Say continue, retry with the error, or send to a person.
Why: Not every failure is a retry.
You should see: Three different next actions.
Step 4
Write the retry turn
For the sum mismatch only, write the user message you would append. Include both numbers.
Why: The model needs the miss, not a request to try again.
You should see: One sentence that names the two totals.

Review checklist

Checks are saved in this browser.

I use a schema for shape and a rule for values.
I allow null when the source may be silent.
I refuse to parse a truncated turn.
I retry with the validation error only when the source can support a correction.
I check citations against the source, not against the tone.

Key takeaways

Structured output makes JSON and strict tool inputs parseable. It does not make them true.
Validate sums, caps, and ids after the schema. Fail closed.
A prefix, a thinking block, and a string you would have to eval are not the object.
Confidence is style. A claim stands when your check finds it in the source.

Sources

Structured outputs — output_config.format for JSON, and strict tool use.
Build with Claude — The message content blocks a parser has to read by type.
CCDV-F blueprint notes — Domain 6 output skill and weight. Study notes, not exam items.

Domain 6 overview · Quick reference

View progress