Skip to content
Home › Prompt Engineering & Structured Output

Resilient schema design

Prompt Engineering & Structured Output

Definition

Designing extraction schemas that absorb edge cases and document amendments instead of failing validation or overwriting data — via catch-all enum values, redundancy, and multi-value fields.

Key points

  • Anti-pattern: Fragile Expansion — continuously expanding enums as edge cases arise. A restricted enum ["house","apartment","condo","townhouse"] throws a VALIDATION ERROR on unexpected types (e.g. "studio", "converted warehouse").
  • Pattern: Resilient Catch-Alls — add an "other" value to the enum, paired with a detail string field (property_type_detail, "Specifics for 'other' types") → VALIDATION SUCCESS, data captured (e.g. property_type:"other", property_type_detail:"studio").
  • Data Evolution Rule: for amended documents, redesign schemas so amended fields capture multiple values, each with a source location and effective date, rather than overwriting original terms. Validate against extracting both original and amended contract clauses.
    • Example payment_terms array: {value:"30 days", source:"Original Contract, Clause 4.1", effective_date:"2023-01-01"}, {value:"45 days", source:"Amendment 1, Clause 2", effective_date:"2023-06-15"}.
  • Redundancy variant for math: see Mathematical consistency enforcement (calculated_total vs stated_total).
  • On the Architect's Reference Matrix this is the Accuracy × Data Extraction cell ("Schema Redundancy").

Why it matters for the exam

  • Structured-output scenarios test choosing the resilient catch-all + detail field over ever-growing enums, and multi-value+provenance fields over overwriting.

Common gotchas

  • Endlessly adding enum values is the trap; add other + a detail field instead.
  • Amendments should preserve both original and amended values with source + effective date, not overwrite.

See also

Sources

Referenced by