Phase 3: Validation

Cross-field sanity checks and re-resolution. Phase 3 performs two critical tasks: it re-runs the reference table lookup cascade on values produced by Phase 2 to normalize free-text AI output to your canonical codes, and it runs informational validation checks across related fields. Flags are informational only — they never block output but help you prioritize review:

After Phase 3 completes, flagged cells appear with warning indicators in the results grid. Use the Flagged filter to see only rows that need attention — for example, an amount_mismatch flag suggests you double-check a total that does not align with its component values. Addressing flagged cells first is the most efficient way to review large extraction runs.

Phase 3 also re-runs the lookup cascade (reference table resolution) on values that Phase 2 produced. This is important because AI-extracted values often use natural language labels (e.g., "Frame Agreement") rather than the canonical codes your reference table expects (e.g., std_master). The Phase 3 lookup normalizes these labels to codes, improving consistency across your output without requiring manual corrections.

Validation flags are designed to surface the most impactful issues first. The low_confidence_outlier flag is particularly useful — it highlights cells where the system is uncertain in an otherwise high-confidence row, pointing you to the exact cells most likely to contain errors. For large runs with hundreds of documents, filtering by flags and reviewing those cells first can reduce your review time by 80% or more.

What gets flagged and why depends on cross-field relationships, not just individual values. A date_sanity flag fires when temporal fields contradict each other — for example, a contract end date that falls before the start date, or a signature date after the effective date. An amount_mismatch flag fires when a computed total deviates more than 20% from the product of its component values (e.g., monthly rent times term length versus total contract value). The unexpected_empty flag fires when a field that appears in over 80% of documents in your registry is missing from this particular document, suggesting the AI may have missed it rather than it being genuinely absent.

curl -s https://api.talonic.com/v1/jobs/c3d4e5f6-a7b8-9012-cdef-123456789012/results \
  -H "Authorization: Bearer $TALONIC_API_KEY"

# Each result row carries the validation flags raised for that document:
# {
#   "job_id": "c3d4e5f6-a7b8-9012-cdef-123456789012",
#   "job_status": "complete",
#   "total_rows": 150,
#   "data": [
#     {
#       "document_id": "f0e1d2c3-b4a5-9687-8765-432109876543",
#       "filename": "Contract_Beta.pdf",
#       "status": "completed",
#       "confidence": 0.82,
#       "validation_flags": [
#         {
#           "type": "date_sanity",
#           "severity": "error",
#           "fields": ["contract_start_date", "contract_end_date"],
#           "message": "End date (2024-01-15) precedes start date (2025-03-01)"
#         },
#         {
#           "type": "low_confidence_outlier",
#           "severity": "warning",
#           "fields": ["payment_terms"],
#           "message": "Confidence 0.28 in row with average 0.82"
#         }
#       ]
#     }
#   ]
# }

Phase 3 is particularly valuable for catching systematic errors before they reach downstream systems. For example, if your schema includes both a "start date" and "end date" field, the date_sanity check catches temporal inversions that would be difficult to spot in a large grid. Similarly, the amount_mismatch check catches arithmetic inconsistencies between related financial fields — a total that does not align with its components within a 20% tolerance is flagged for review. These cross-field checks operate on relationships between fields rather than individual values, catching errors that single-field validation cannot detect.