A permitting API receives a Claude JSON checklist destined for the case file. Which output handling step fits?
Select an answer to reveal the explanation.
Short Explanation
Don't trust the JSON just because Claude wrote it—validate against the schema before it hits the case file.
Full Explanation
Validating Claude JSON checklists against a schema before writing the permitting case file protects municipal records integrity. That step works because structured model output is still untrusted application input: field names, types, enums, and required keys can be wrong even when the JSON parses. Schema validation catches malformed or incomplete checklists before they corrupt parcel history, inspection queues, or fee calculations that residents and auditors rely on.
Checking Claude JSON checklist syntax in the gateway before writing to the case file fails because a syntax check only confirms the JSON parses; it does not validate field names, types, enums, or required keys against the case-file schema, so structurally invalid checklists can still slip through.
Holding Claude JSON checklist as draft for staff review before writing to the case file fails because it replaces schema enforcement with manual review; it does not reject nonconforming output at write time and can still allow bad data into the permitting workflow.
Normalizing checklist field formatting in the API layer before writing to the case file fails because normalization alters field formatting instead of validating against the schema; it can silently mask missing or invalid keys and change data rather than rejecting nonconforming checklists.
Exam caveat: schema validation proves structure, not that the underlying facts match the uploaded plans; business-rule and human review gates may still be required. Operational check: define a versioned checklist schema, reject nonconforming Claude output with actionable errors, never partial-write on failure, and alert permitting ops when validation failure rates spike for a given prompt version.