'Unknown' Beats a Hallucinated Field: Preventing Made-Up Output

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 42)

▶ Watch on YouTube & subscribe to The Stack Underflow

You built an extraction pipeline: pull vendor, invoice_number, and total out of scanned receipts. Most receipts have all three fields. Some don’t — the vendor logo is unreadable, or there’s no invoice number printed at all. Your schema marks every field as a required string. On those messy documents, Claude doesn’t leave the field empty. It writes something plausible-looking instead — a vendor name that fits the format but isn’t on the page. Nobody catches it, because it looks exactly like a real answer. This is the failure mode Domain 4 of the Claude Certified Architect exam is testing when it asks about “unknown” versus a hallucinated field.

The one-sentence version: A schema that has no way to represent “I don’t know” forces the model to invent an answer — allow null or an explicit unknown value, and instruct the model to use it, and the model can tell you the truth instead.

The question

This is question 9 of 10 in the CCA Domain 4 practice set — Prompt Engineering & Structured Output (20% of the exam).

You want the model to say ‘unknown’ instead of inventing a field it can’t find. Best approach?

• A) Hope it doesn’t hallucinate
• B) Allow null/“unknown” in the schema and instruct it to use that when unsure
• C) Forbid null
• D) Raise temperature

Pause here and pick an answer before you keep reading.

The answer

The correct answer is B — allow null (or an explicit “unknown” value) in the schema, and instruct the model to use it when the field genuinely isn’t present.

The mechanism is about what a schema communicates to the model as a legal shape of output. If your input_schema declares vendor as {"type": "string"} with no null option, you have told the model, structurally, that every response must contain a string in that slot. There is no path through the schema that represents “I don’t have this.” When the model can’t find a vendor name and the schema still demands a string, it does the only thing the contract allows: it produces a string that looks right. That’s not a matter of prompt wording — it’s the schema not having a legal shape to hold the true answer, which is “nothing.”

Widen the schema, and you widen the model’s honest options:

SCHEMA WITHOUT AN ESCAPE HATCH
{
  "vendor": { "type": "string" }   ← must always be a string
}
Input has no visible vendor
        │
        ▼
Model MUST emit a string ──────► "Acme Corp" (plausible, unverified, WRONG)


SCHEMA WITH AN ESCAPE HATCH
{
  "vendor": { "type": ["string", "null"] }   ← string OR null is legal
}
+ instruction: "Use null if the vendor is not clearly present in the document."
Input has no visible vendor
        │
        ▼
Model has a legal null slot ───► null  (HONEST)
Input has a clear vendor
        │
        ▼
Model fills the string slot ───► "Acme Corp"  (CORRECT)

Two things have to be true at once, and the exam likes to test whether you know both halves:

1. The schema must structurally permit the absence. "type": ["string", "null"] (or a sibling "vendor_confidence": "unknown" enum value) gives the model a legal slot for “I don’t know” that isn’t also a string. If you skip this, no amount of prompt wording fixes it — the model is still boxed into producing some string.
2. The instruction must tell the model when to use it. A schema that merely allows null doesn’t guarantee the model reaches for it — models default toward filling fields that look fillable. An explicit line like “if the field is not clearly present in the source, return null — do not guess” tells the model that abstaining is the preferred behavior in that case, not a fallback nobody expects it to use.

Put together: the schema makes honesty possible, the instruction makes honesty the default choice. Neither alone is sufficient.

Why the other options fail

• A) Hope it doesn’t hallucinate. Hope is not a mechanism. Nothing in the request changes what the model is structurally allowed to output, so nothing changes about whether it invents data. This is the same failure as “please return only JSON” from earlier in the domain — a wish, not a contract.
• C) Forbid null. This is the opposite of the fix — it’s the setup that causes the bug in the first place. Forbidding null removes the model’s only honest option when a field is genuinely absent, guaranteeing it has to fabricate something to satisfy the schema.
• D) Raise temperature. Temperature controls sampling randomness across token choices — it makes output more varied, not more truthful. A higher temperature doesn’t give the model a “say unknown” option that didn’t exist in the schema; it just makes the hallucinated guess less predictable, which is worse for downstream consumers, not better.

The concept behind it

This question is really about a broader principle that runs through all of Domain 4: a JSON schema is not just a shape validator, it’s the complete menu of what the model is allowed to say. If a legitimate real-world answer isn’t representable in that menu, the model will pick the closest thing that is representable — and “closest representable thing” is often indistinguishable from a hallucination once it’s sitting in a database column next to real data.

The pattern generalizes to almost every extraction and classification task:

Two follow-on details worth knowing for the exam and for production:

• Downstream code must treat null as a valid, expected value, not an error to catch. If your validator or your database column rejects null, you’ve just recreated the same forcing pressure one layer downstream — now the parsing code invents a default instead of the model.
• Instructing “use null when unsure” is a form of explicit criteria, the same idea tested in the “buried rule” question earlier in this domain: don’t just widen the schema and assume the model will notice. State the abstention rule plainly, ideally near the field definition itself, so it isn’t lost in a long system prompt.

This connects directly to calibration and trust: a system that can say “unknown” is one you can build a review queue around — route the nulls to a human, ship the confident answers straight through. A system that never says “unknown” gives you no signal for where it’s guessing, which means every field carries silent, undifferentiated risk.

FAQ

Does this mean I should make every field nullable “just in case”? Not automatically. Make a field nullable when there’s a real-world scenario where it’s legitimately absent from the source — not as a blanket habit. Over-nullable schemas can invite the model to abstain lazily on fields that were actually recoverable with more careful reading. Pair the null option with a clear instruction of when to use it, so it’s a deliberate escape hatch, not a shrug.

Is null the same as an empty string ""? No, and conflating them causes bugs. An empty string is often ambiguous — did the model find an empty value, or fail to find anything? Use null (or an explicit "unknown" string) specifically to mean “not present, not extracted,” and keep "" out of the schema’s vocabulary for that field entirely if you can.

How does this relate to forcing JSON output with tool_choice? They solve different problems. Forcing tool_choice (covered in the companion question on guaranteeing valid JSON) guarantees the shape comes back as structured data instead of prose. Allowing null in that shape guarantees the content can be honest when a field is missing. You typically want both together: a forced schema that itself has room for “I don’t know.”

Can I ask the model to also return a reason for the null? Yes, and it’s a strong pattern for anything going to a human review queue — add a sibling field like vendor_null_reason: "not visible in image" so a reviewer doesn’t have to re-derive why the model abstained.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is question 9 of 10 in the Domain 4 practice set — Prompt Engineering & Structured Output, 20% of the exam. It sits right next to the two questions it depends on: forcing the schema in the first place with How Do You Guarantee Valid JSON? Forcing Structured Output, and catching the cases where the schema’s types don’t match reality in A Number Comes Back as a String: Validating Structured Output Types. If your pipeline needs to route the honest nulls somewhere useful rather than just log them, see The Output Feeds a Program, Not a Person: Machine-Readable LLM Output for how a downstream program should consume structured extraction results, including the null cases.

For the full five-domain breakdown of what’s tested and how much each domain is worth, start with the Claude Certified Architect (CCA) Exam Guide. Browse all tutorials for the rest of the series.