You will build a small script that reads sample emails and returns validated JSON for each.
Every week, Priya's team receives emails from customers asking to change a delivery. Someone reads each one and types the details into the job system by hand: the order number, the new date, the new address and anything special. It is slow and dull, and it is exactly the kind of job a schema-based extractor does well. In this exercise you build one, for these emails or for a kind of email you receive yourself.
Allow about 35 minutes. You need your working script from lesson 1.4, Send your first request and read the response, and your AI coding assistant.
Gather ten sample emails and save each as a plain text file in a folder called samples. Use real emails if you can, with names, phone numbers and addresses replaced by made-up ones. Personal data has no place in a practice folder.
Variety matters more than volume. Priya's ten included four ordinary change requests, one with two orders in it, one that gave the new date as "next Thursday", one that said "same address as last time", one written in Chinese, one forwarded thread where the request was buried under three replies, and one that was only "Thanks, received". The last two are the important ones. Most extractors fail on the email in another language and the email with nothing to extract, and you want to find out how yours behaves before a customer does.
Decide what fields you need before asking for any code. Priya's schema had five:
order_number: a string, or null if none is given. new_date: a string in the format YYYY-MM-DD, or null if the email does not give one clearly. new_address: a string, or null. request_type: an enum with the values change_date, change_address, change_both, cancel and no_request. notes: a short string for anything else the person handling it should know.
Two choices are worth copying. Every field allows null, so the model has an honest answer when information is missing instead of inventing an order number. And request_type includes no_request, which gives the "Thanks, received" email somewhere to go, as lesson 2.2, Ask for JSON and enforce it with a schema, recommended.
Relative dates are a trap. The model does not know today's date unless you tell it. Priya's system prompt includes the date the email was received, and tells the model to return null when the date is unclear rather than guess.
Give your coding assistant the schema and the structure you want. Ask it to write a script that reads every file in the samples folder, sends each one with your system prompt and the schema using the provider's structured output mode, validates the reply against the schema, checks the stop reason, retries once with the validation error on failure, and writes the result for each email to an output file. Ask it to write a log line for every call that records the file name, whether validation passed, whether a retry happened and the token usage.
Read what it produces before running it. Check that the key comes from the environment variable, that there is exactly one retry and not a loop, and that a failure on one email does not stop the rest.
Run the script on all ten samples. Then read the log before you read the outputs. How many calls failed validation the first time? How many recovered on the retry? Did any hit the output limit? Priya's first run, as a worked example, had one validation failure out of ten, on the forwarded thread, which recovered on retry.
Now open each email beside its JSON and mark the result as correct, wrong or failed. Correct means every field matches what a careful person would have typed. Wrong means valid JSON with a wrong value. Failed means the extractor gave up and sent the email to the fallback.
This step is where you learn the most. Priya's extractor returned valid JSON for all ten emails, but two were wrong: the "next Thursday" email got a date one week too late, and the Chinese email had the new address but missed the unit number. Valid JSON with a wrong value is the failure lesson 2.2 warned about, and only checking by hand reveals it at this stage.
You have a folder with ten sample emails, the script, a JSON output for each email, a log of every call and retry, and a results table with one row per email marked correct, wrong or failed, plus a note on what went wrong in each wrong row.
Do not fix the problems yet. A short list of how your extractor fails is more useful now than a patched prompt, because module 7 will turn these exact cases into tests.
Run your extractor on ten sample emails, save the JSON outputs, and mark each as correct, wrong or failed.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).