Evidence Validation

Evidence validation is a rule-based engine that checks extracted field values for structural errors and checksum validity. Seven structural validators (S1–S7) catch problems like free-text spillover, empty required fields, and failed Luhn or IBAN checksums, and extensible domain packs add industry-specific rules. Results appear as colored validation badges in the Evidence tab of the case detail page.

Structural validators

The checksum validator (S7) uses a parameterized factory pattern: it accepts a checksum algorithm name and applies the corresponding verification logic. Supported algorithms include Luhn (credit card numbers), ABA (bank routing numbers), IBAN (international bank accounts), and ISBN (book identifiers). For best results, ensure your schema fields are typed correctly so the engine knows which checksum to apply.

Domain packs extend validation with industry-specific rules. The freight domain pack includes DOT number state detection and MC (Motor Carrier) number validation. Each pack is a self-contained module that registers its validators during application startup, so additional packs for other industries can be added to domain-packs/ without modifying the core engine. This plug-in architecture means the validation engine grows with your industry needs without accumulating complexity in the core rule set.

Reviewing results in the Evidence tab

Validation runs automatically after extraction and linking complete. Each field value is checked against every applicable validator, so a single field can trigger multiple rules. Open a case and switch to the Evidence tab: colored badges appear next to each field value, green for pass, red for fail, and amber for warnings. Click a badge to see which validator fired and what the expected format or value was. Use the filter bar to narrow results by status, document, category, or free-text search, and the group-by-document collapsible sections to review one document at a time.

• S1 — Free-text spillover: unstructured text leaked from adjacent content
• S2 — Empty value: required field is blank or whitespace-only
• S3 — Email/URL misclassification: value looks like an email or URL in the wrong field type
• S4 — Name in URL field: person or company name extracted into a URL-typed field
• S5 — Alpha in numeric field: alphabetic characters in a numeric-only field
• S6 — Cross-field duplicate: identical value in multiple unrelated fields on the same document
• S7 — Checksum validation: Luhn, ABA, IBAN, ISBN verification via parameterized factory
• Domain packs: industry-specific rules (e.g., freight: DOT numbers, MC numbers)

# The API's evidence resource returns the case's connective evidence:
# which shared references join its documents, and what is still missing.
curl -s https://api.talonic.com/v1/cases/CASE_UUID/evidence \
  -H "Authorization: Bearer $TALONIC_API_KEY"

# Response:
# {
#   "connections": [
#     {
#       "document_a": "…",
#       "document_b": "…",
#       "via_field": "purchase_order_number",
#       "value": "PO-2025-8890",
#       "kind": "transaction",
#       "confidence": 0.98,
#       "verdict": null          # curator verdict, if reviewed
#     }
#   ],
#   "gaps": [ ... ],       # dangling references / missing documents
#   "documents": [ ... ]   # case members
# }

Note the two complementary evidence surfaces: the Evidence tab in the app shows field-level validation badges produced by the S1–S7 validators and domain packs, while the public API endpoint GET /v1/cases/{key}/evidence returns the case's connective evidence, meaning the shared-reference connections that explain why these documents form one case, plus any open gaps. Use the tab to audit field quality and the API to audit case membership.