Invoices, Nesting, and Cost

nested schemas and totals

Part of: Structured JSON Extractor

Contacts are flat, three string fields. Invoices are the harder, more valuable case: an id, a total, and a list of line items , each with its own fields. Nesting brings a kind of validation you can't do on contacts, since the numbers have to add up. Bigger documents bring another concern: cost. Nested schema An invoice's schema has an array of objects inside it: You spell the item shape out in the prompt too, so the model knows each line needs a name, quantity, and price. Validate the arithmetic The check that earns its keep for invoices: the line items must sum to the stated total. If they don't, the extraction is wrong even when every field is present and typed correctly: This catches the model dropping a line item or misreading a price, errors that presence-and-type checks alone sail right past. Cross-field validation like this is where extraction earns its trust. Note the abs(computed - inv["total"]) 0.01 instead of !=: money is a float here, and floats don't compare exactly (0.1 + 0.2 is 0.30000000000000004, not 0.3). Comparing within a one-cent tolerance avoids false mismatches. In production the sturdier fix is to store money as integer cents and compare exactly. Watch the c

Challenge: Reconcile the Invoice