Skip to main content

Anomaly Detection

Anomaly detection surfaces cross-document data quality issues at the case level. Five structural detectors compare values across the documents in a case to find contradictions, divergences, and missing patterns that no single-document check can catch, for example an invoice total that disagrees with its purchase order. Anomalies are computed directly from the case's field occurrences with deterministic rules: no LLM is involved.

The five detectors

Anomaly detectors

ParameterTypeDescription
Validation ClusterD1Multiple validation failures concentrated in the same document or field group.
Field ConflictD2The same field has contradictory values across documents in a case.
Duplicate Key DivergenceD3Documents share a link key value but differ on fields that should match.
Missing Document TypeD4A case template expects a document type that is absent from this case.
Value ReuseD5Identical values appear across unrelated fields, suggesting copy-paste or extraction errors.
  • D1 — Validation Cluster: multiple validation failures concentrated in the same document or field group
  • D2 — Field Conflict: contradictory values for the same field across documents in a case
  • D3 — Duplicate Key Divergence: shared link key but differing values on fields that should match
  • D4 — Missing Document Type: case template expects a document type that is absent
  • D5 — Value Reuse: identical values across unrelated fields, suggesting copy-paste or extraction errors

Triage workflow

Anomalies appear in the Anomalies tab of the case detail page (Advanced mode). Each anomaly card shows severity, affected fields, and a dismiss button. Dismissed anomalies are hidden by default but visible via the show dismissed toggle. A typical workflow starts on the cases list page, where anomaly count badges give you an at-a-glance view of which cases need attention: click into a case, switch to the Anomalies tab, and use the severity filter pills to focus on critical issues first.

Anomalies are computed on-read from the case's current field occurrences, so they are always up to date: when case membership changes (documents added or removed, cases merged or split), the next view of the case reflects the new detection results. Each detector operates independently, so a single case can trigger multiple anomaly types simultaneously. Most teams find that D2 (Field Conflict) and D3 (Duplicate Key Divergence) catch the highest-value issues in procurement and financial workflows. Configure case templates so the D4 detector can flag incomplete cases.

List anomalies for a specific case
curl -s https://api.talonic.com/v1/cases/CASE_UUID/anomalies \
  -H "Authorization: Bearer $TALONIC_API_KEY"

# Response:
# {
#   "data": [
#     {
#       "type": "field_conflict",
#       "severity": "critical",
#       "title": "Conflicting total_amount across documents",
#       "description": "total_amount is 12,450 in Invoice_4521.pdf but 12,500 in PO_8890.pdf",
#       "document_ids": ["…", "…"],
#       "targets": [
#         { "document_id": "…", "field": "total_amount", "value": "12,450" },
#         { "document_id": "…", "field": "total_amount", "value": "12,500" }
#       ]
#     }
#   ],
#   "findings": [ ... ],   # open dangling-reference findings
#   "template": { ... }    # matched workflow template, or null
# }
# severity is one of: critical, warning, info

Anomaly detection is designed for high-throughput triage. In a workspace processing hundreds of cases per week, the anomaly count badges on the cases list page give you an instant heat map of where problems are concentrated. A case with zero anomalies typically needs only a quick spot-check, while a case with multiple field conflicts or duplicate key divergences warrants detailed investigation. This severity-based prioritization lets your team focus review effort where it has the highest impact, rather than reviewing every case with equal depth.

Anomaly detection requires Advanced mode to be enabled. In Simple mode, anomalies are still computed but not displayed in the case detail page. Toggle Advanced mode from the sidebar to access the full anomaly workflow.

Frequently asked questions

What anomalies does Talonic detect?+
Five structural patterns: validation clusters (D1), field conflicts (D2), duplicate key divergence (D3), missing document types (D4), and value reuse (D5). Each is surfaced as a dismissable card on the case detail page. D2 and D3 are the highest-value detectors for procurement and financial workflows — they catch contradictory values across related documents, such as mismatched amounts between an invoice and its corresponding purchase order.
Do anomalies update automatically when cases change?+
Yes. Anomalies are computed on-read from the case's current field occurrences, so whenever case membership changes (documents added or removed, cases merged or split) the next view reflects the new results. Each detector operates independently, so a single case can trigger multiple anomaly types simultaneously.
Can I dismiss anomalies?+
Yes. Each anomaly card includes a dismiss button. Dismissed anomalies are hidden by default but can be revealed using the show dismissed toggle on the Anomalies tab.
What is the difference between anomaly detection and validation checks?+
Validation checks operate on individual documents — they flag issues within a single record like date inconsistencies or format mismatches. Anomaly detection operates at the case level — it compares values across multiple documents within a case to find conflicts, divergences, and missing patterns. Both are complementary: validation catches per-document issues while anomaly detection catches cross-document issues.
Does anomaly detection use an LLM?+
No. The five detectors are deterministic structural rules computed directly from the case's field occurrences. Nothing is sent to a language model and nothing is persisted; results are recomputed each time the case is read, so they always reflect the current document set.

Related

Cases
Evidence Validation
Validation Checks
Document Graph