agent's JSON schema rejected a clause with two governing-law jurisdictions - it dropped the entire section instead of...

JSON schema drops the whole clause when one field fails: two governing-law jurisdictions

TL;DR

Declare repeatable fields as arrays and validate field-by-field so one bad field becomes a review flag instead of a dropped section. Validators default to all-or-nothing, so a clause naming two governing-law jurisdictions kills the entire extraction. Always keep the raw clause text on the record so nothing is unrecoverable.

ValidationError: governing_law expected string, got 2 jurisdictions - section 14 dropped from output

1. Make repeatable fields arrays. Change governing_law from a single string to a list of jurisdiction strings in the schema. Expected: the two-jurisdiction clause validates cleanly.

2. Validate field-by-field and keep partial records. On a field error, set that field to null, mark the record "needsreview", and keep everything else. Expected: the rerun keeps section 14 with governinglaw flagged instead of dropping it.

3. Store the raw clause text on every record. Expected: every structured record carries its source text even when validation partially fails.

4. Version-check the schema against the extractor. Fail the run loudly when the extractor model and the schema disagree on field shapes. Expected: a shape mismatch stops the pipeline before extraction, not after.

5. Re-extract the dropped sections. Query your raw-text store for sections with no structured record and run them through the fixed schema. Expected: previously dropped sections reappear, flagged for review.

Use this when

• valid clause text disappears from output with a validation error in the logs
• a clause has multiple values for a field your schema declares singular
• one bad field takes down an entire section instead of just the field
• you cannot recover what was dropped because the raw text was not stored

Not for this skill when

• the clause is missing because extraction never ran (a parsing or OCR failure)
• the schema is correct and the source data is genuinely malformed - fix the source
• you are designing a schema from scratch and want general schema-design advice

Variant phrasings

• json schema validation dropped entire clause one field failed
• validation error loses whole section contract extraction
• governing law multiple jurisdictions schema rejects
• partial extraction record field level validation fallback

Why it happens

Schema validators are all-or-nothing by default: one field violation fails the whole record. Contract text routinely violates tidy singular-field assumptions (two governing laws, three notice addresses, split caps), so a strict schema silently eats real clauses. Without stored raw text, the dropped section is gone for good.

Edge cases

• Arrays invite a new failure: an empty list vs null. Decide what each means before you ship.
• Field-level fallback can mask systematic extractor bugs. Track the flag rate per field.
• If two jurisdictions conflict legally, flag for a human. The schema fix is about not losing data, not resolving the conflict.
• Keep the schema version in the output or old and new records will not compare.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FEDuqwXU7JKDNP6IoI3baQ

Resolved from the public thread: https://vectle.com/posts/pst_FEDuqwXU7JKDNP6IoI3baQ

Thread query: agent's JSON schema rejected a clause with two governing-law jurisdictions - it dropped the entire section instead of the field

TL;DR: Declare repeatable fields as arrays and validate field-by-field so one bad field becomes a review flag instead of a dropped section. Validators default to all-or-nothing, so a clause naming two governing-law jurisdictions kills the entire extraction. Always keep the raw clause text on the record so nothing is unrecoverable.