Schema-Driven Governance: Forcing AI to Speak Your ERP's Language

The Danger of Unstructured LLM Outputs in Legacy Databases

Schema Mismatch Failures

{
  "Invoice Date": "March 15, 2026",
  "Total": "$1,234.56",
  "Vendor": "Acme Corp."
}

{
  "invoice_date": "2026-03-15",
  "total_amount": 1234.56,
  "vendor_id": "V-00847"
}

• Field names use different conventions (title case vs. snake_case)
• Date format is human-readable vs. ISO 8601
• Amount includes currency symbol and is a string vs. a number
• Vendor is a name vs. an internal identifier

Type Coercion Errors

• The string "1234" and the integer 1234
• The string "true" and the boolean true
• The string "null" and the absence of a value

• String concatenation instead of numeric addition
• String comparison instead of boolean logic
• Null pointer exceptions from unexpected string values

Structural Variation

{
  "line_items": [
    {"product": "Widget A", "qty": 10, "price": 5.00},
    {"product": "Widget B", "qty": 5, "price": 10.00}
  ]
}

{
  "products": ["Widget A", "Widget B"],
  "quantities": [10, 5],
  "prices": [5.00, 10.00]
}

The Shift from ETL to ELT: Raw Ingestion First

ELT Architecture for Documents

1. Ingest the original document and preserve it completely
2. Parse the document to extract text and layout information
3. Store both the original and parsed representation
4. Apply schemas when extracting structured data
5. Re-extract with new schemas when requirements change

Schema-on-Read Benefits

• Add new fields to schemas without reprocessing
• Change field types as integration requirements evolve
• Support multiple schemas for the same document type

• Apply new schemas to documents processed years ago
• Extract fields that were not in the original schema
• Respond to audit requests for information not previously extracted

• Maintain multiple schema versions simultaneously
• Route documents to appropriate schema versions
• Compare extraction results across schema versions

• Test new schemas against existing documents
• Measure extraction quality before production deployment
• A/B test schema variations

Schema-Driven Extraction in DocuPipe

DocuPipe schema builder interface

JSON Schema Definitions

{
  "type": "object",
  "properties": {
    "invoice_date": {
      "type": "string",
      "description": "Invoice issue date in ISO 8601 format (YYYY-MM-DD)"
    },
    "due_date": {
      "type": "string",
      "description": "Payment due date in ISO 8601 format (YYYY-MM-DD)"
    },
    "total_amount": {
      "type": "number",
      "description": "Total invoice amount as a number without currency symbols"
    },
    "currency": {
      "type": "string",
      "enum": ["USD", "EUR", "GBP", "CAD", "Other"],
      "description": "Three-letter ISO 4217 currency code"
    },
    "line_items": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "description": {"type": "string"},
          "quantity": {"type": "integer"},
          "unit_price": {"type": "number"},
          "total": {"type": "number"}
        }
      }
    }
  }
}

Enum Fields for Categorical Data

{
  "document_type": {
    "type": "string",
    "enum": ["Invoice", "Purchase Order", "Receipt", "Credit Memo", "Other"],
    "description": "Type of financial document"
  }
}

Schema Versioning

• Create new schema versions (invoice_v1, invoice_v2, invoice_v3)
• Compare extraction results across versions
• Maintain multiple active versions for different use cases
• Roll back to previous versions if new schemas produce issues

What Schemas Control vs. What They Do Not

• Field names in the output
• Expected data types (string, number, array, object)
• Enum values for categorical fields
• Output structure and nesting
• Field descriptions that help the model understand intent

• Required vs. optional fields (all fields are treated as optional by the extraction model)
• Value constraints like minimum/maximum
• Format validation (the model attempts to follow format hints in descriptions)
• Cross-field validation rules

Building Validation into Your Pipeline

• Validate required fields are present
• Check data types match expectations
• Apply business rules (amounts within ranges, dates in sequence)
• Transform formats as needed for target systems

• Pydantic for Python validation
• JSON Schema validators for any language
• Database constraints as a final gate
• ETL tools with built-in validation

Implementation Considerations

Schema Design Best Practices

• Describe what the field should contain, not just its name
• Include format hints ("date in YYYY-MM-DD format")
• Specify units when relevant ("amount in dollars, no currency symbol")

• Use number for amounts you need to calculate with
• Use string for identifiers even if they look numeric
• Use array for repeating elements like line items
• Use object for nested structures like addresses

• Include common values plus "Other" for edge cases
• Keep enum lists focused (5-10 values work better than 50)
• Use descriptive values ("Invoice" not "INV")

Versioning Strategies

• Add new fields without removing existing ones
• Old integrations continue working
• Simplest approach for forward compatibility

• When you must change field names or types
• Create a new schema version (v2)
• Migrate integrations before deprecating old version

• Run multiple versions for different use cases
• Different downstream systems may need different structures
• Version identifier in output enables routing

Integration Patterns

• Map JSON fields to database columns
• Apply type conversion in your insertion logic
• Use database constraints as a validation layer

• Transform extracted data to match API contracts
• Handle missing optional fields gracefully
• Log extraction results for debugging

• Publish extractions to queues for async processing
• Use dead letter queues for failed validations
• Enable retry logic for transient downstream failures

• Serialize extractions to CSV, XML, or EDI as needed
• Apply format transformations for partner requirements
• Validate before transmission

Conclusion