Use lessons 01–02 or equivalent skills before this exercise. You can revisit them from the lesson list.
A computer and Python 3.10+. The supplied standard-library lab needs no API key, network or purchase.
Download the runnable offline builder lab →Start with the idea
Check both the shape and the truth of a structured result.
Validate status, fields and types. Then compare the values with their source. Refused or incomplete output must not become an ordinary success.
Schema validation: Checking that an output follows the required field and value rules.
See the example and check your understanding
A made-up teaching example
The response has valid fields but says record P starts at 11:00. The source says 10:00. Format validation passes; the evidence check fails.
Ask yourself
Does valid structure make the time correct?
Show the explanation
No. Return an unsupported-result state. Do not invent replacement content for refusal or incomplete output.
Start with these checks
- Validate the envelope and fields.
- Check values against evidence.
- Preserve refusal and incomplete states.
Use the different practice case below and check every requirement in its full instructions.
Full learning objectives
- Separate JSON parsing from validation.
- Handle refusal and incomplete output explicitly.
- Normalize provider responses without inventing missing content.
Captions appear here during playback.
Handle structured output and provider failure states
Check both the shape and the truth of a structured result.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · What you will learn
Check both the shape and the truth of a structured result.
What appears on screen
Check both the shape and the truth of a structured result.
0:06 · The idea
Validate status, fields and types. Then compare the values with their source. Refused or incomplete output must not become an ordinary success.
What appears on screen
Validate status, fields and types. Then compare the values with their source. Refused or incomplete output must not become an ordinary success.
0:19 · One useful term
Schema validation. Checking that an output follows the required field and value rules.
What appears on screen
Checking that an output follows the required field and value rules.
0:28 · A worked example
The response has valid fields but says record P starts at 11:00. The source says 10:00. Format validation passes; the evidence check fails.
What appears on screen
The response has valid fields but says record P starts at 11:00. The source says 10:00. Format validation passes; the evidence check fails.
0:42 · Your turn to think
Does valid structure make the time correct? Pause and decide before continuing.
What appears on screen
Does valid structure make the time correct? Pause the video if you need more time.
0:58 · Why this answer works
No. Return an unsupported-result state. Do not invent replacement content for refusal or incomplete output.
What appears on screen
No. Return an unsupported-result state. Do not invent replacement content for refusal or incomplete output.
1:09 · Check 1
Validate the envelope and fields.
What appears on screen
Validate the envelope and fields.
1:14 · Check 2
Check values against evidence.
What appears on screen
Check values against evidence.
1:19 · Check 3
Preserve refusal and incomplete states.
What appears on screen
Preserve refusal and incomplete states.
1:25 · Now try a different case
Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.
What appears on screen
Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →
The method
A provider adapter should distinguish success, refusal, incomplete response and transport or application error using the provider’s actual supported metadata. Inspect current official documentation before implementing a live adapter. Do not normalize every response into a successful string or assume tool/schema support from a model’s name.
Parse structured output, validate required fields and types, then check factual values against evidence. These are separate gates. A correct schema can contain a false time. Preserve failure states and do not substitute an apparently helpful answer when generation was refused or truncated. The offline adapter in this lesson is a fictional envelope, not an API specification.
Choose your model, harness and offline route
Text-only assistant
Use supplied text. Ask for a plan or draft; do not claim browsing, code execution or file access that was unavailable.
Tool-enabled application or harness
Record which tools actually run, allowed files and actions, approval boundaries and observable results. Tools are optional unless the task needs them.
Local or cloud deployment
Inspect inference, retrieval, connectors, logs and storage separately. Use only authorized environments for real data; training fixtures are fictional.
Higher-capability or frontier model
Evaluate the exact task and configuration. Capability does not supply missing evidence or grant permission. No provider ranking or guarantee is implied.
Offline alternative
Use the supplied inputs and inspect the worked example manually. Builder exercises use local deterministic Python. No paid account or live model call is required.
Record the exact product/model label when available, tools actually used, inputs, permitted actions, observed output and checks. Live accounts or APIs may have external costs; they are optional and are not used by this page.
Read the general workflow guide →Worked example
Supplied input
Fictional envelope: status=ok, payload={id:"P", time:"11:00"}. Source record P says 10:00. The field names and string types are valid.
A checked result
Shape passes; evidence check fails. Return an unsupported-result state rather than treating valid JSON as a correct answer. A refused or incomplete envelope cannot become an ok result.
Why this works
Structure constrains representation, not truth. Status handling prevents silent success on partial or unavailable output.
Try a different case
Independent lab stage: implement validate_answer in starter.py. Exact fields id and time must be non-empty strings and agree with the supplied source. Run it against wrong time, extra fields, refusal and incomplete envelopes.
Download this task and checklist →Interactive practice / Fictional fixture
Run shape and evidence checks separately
Source fixture: public record P has time 10:00. Modify the response, run checks and inspect each gate. Do not treat these results as live provider behavior.
Everything runs in this browser. No AI model is called and no work is uploaded. Bounded checks cover specific facts and rules. Your writing is not graded: you review it yourself. Practice never marks a lesson complete automatically.
Try refusal, incomplete status or extra fields. These are fictional envelope rules, not a provider API.
Try the task, run the checks, then revise. Checks are teaching feedback, not an instructor grade.
Observed browser simulation
This trace comes from the bounded local checker. It is not a Python run, model result or production tool execution.
Self-review
Locked. Write every written part, then run the checks. A few words is not an attempt.
This is self-review, not grading. Read our answers, then tick what your own work does. Ticks are optional. They stay on this page and are not saved or sent anywhere. A different answer can be just as good if it meets the lesson criteria.
Explain the failed gate and one further negative case
A strong answer
The shape gate passed: status ok, and the payload had exactly id and time as strings. The evidence gate failed: the payload said 11:00 and source P says 10:00. Right structure, wrong fact. I changed time to 10:00 and all gates passed. Another negative case: status refused with a correct-looking payload. It must stay refused; a refusal cannot be turned into ok because the payload looks fine. These are rules for this made-up envelope, not any provider’s API.
A flawed answer
The JSON was valid so the check should have passed. I fixed it by adding a note field explaining the time. It works now.
What is wrong with it: Valid JSON says nothing about whether the time is right. Adding a field breaks the exact-shape rule. “It works now” names no gate and no result.
Keep or restore your work
Drafts are not saved automatically. Save only fictional practice data. A browser draft may be lost if storage is cleared; download a copy to keep it.
Your steps
- Separate envelope status from payload validation.
- Check exact fields and source agreement.
- Keep a failure reason and run the checker.
Check your work
- Only status ok with correct evidence passes.
- Wrong time and extra fields fail.
- Refusal and incomplete output remain failures without inferred replacements.
After your attempt: review notes and a common mistake
Checking only json.loads is insufficient. In the supplied lab, a dictionary can already be parsed and still have invalid fields or unsupported values.
Different wording or a different justified decision can pass. Check your work against every requirement; these notes are not an automated grade.
The lab’s reference.py is a worked solution. Run python check.py --reference only to inspect feedback after your attempt; passing the reference does not complete your work.
Explain your approach
What changes would a real provider adapter need beyond this fictional envelope?
Keep your artifact, one correction or decision, its evidence and one remaining limitation. Nothing on this page sends or uploads your work.
Check your understanding
Choose an answer to see feedback. This is a knowledge check, not instructor assessment.
Review your independent practice
Complete the supplied task before recording progress. Use the acceptance criteria and reveal the review notes after your attempt. Keep your artifact yourself; nothing is uploaded.
Not yet self-reviewed. Completion stays in this browser and does not issue a badge.
Optional deeper study
Explore the related general-course lesson → This opens the existing canonical lesson; it is optional depth, not another copy of this focused task.
Primary references
Revision 2026-10-03. Fictional examples, not observed provider results. Knowledge checks and completion records are self-study aids.