Field Resolution
Field resolution is the process that matches each extracted field against Talonic's Field Registry using a three-band matching model. The bands determine whether a match is accepted automatically, flagged for confirmation, or treated as a new field. Resolution is the core mechanism that turns raw, document-specific field names into canonical registry entries, building a unified knowledge graph across all your documents.
| Parameter | Type | Description |
|---|---|---|
| Auto band | ≥ 0.80 similarity | High-confidence match. The field is linked to the existing registry entry and its occurrence count is incremented. |
| Confirm band | 0.50 – 0.79 | Candidate match. The field is linked but flagged for manual review in the Review Queue. |
| New band | < 0.50 | No match found. A new Provisional field and cluster are created in the registry. |
How Resolution Works
Resolution follows a strict three-band order that is never skipped. First, the system checks for an exact name match against existing registry entries. If no exact match is found, it checks for a cluster member match — whether the field name matches any synonym in an existing semantic cluster. Finally, it computes semantic embedding similarity using AI embeddings to find conceptually similar fields. This graduated approach prioritizes fast, deterministic matches before falling back to more expensive similarity comparisons.
Resolution runs concurrently across documents. Each document's fields are resolved in an isolated transaction to prevent lock contention, and occurrence counts are updated atomically in the same SQL transaction using upserts with a 3-attempt deadlock retry mechanism. This keeps the registry eventually consistent without blocking concurrent ingestion, even when hundreds of documents are being processed simultaneously.
After resolution completes, the platform evaluates maturity promotions, regenerates affected schemas, and updates the cross-schema harmonization view in a fixed chain: resolve, then promote, then regenerate. The chain is never interrupted, so newly promoted fields immediately appear in auto-generated schemas. The resolution process also feeds into the job pipeline: during Phase 1 of a job run, the system uses a 3-tier lookup cascade (string normalization, token fuzzy matching, then AI fallback) to fill 60-80% of cells without a full LLM call, dramatically reducing cost.
/review). Accept to merge into an existing cluster, or reject to create a new field.Monitoring Resolution via API
Batch resolution runs automatically as documents are processed, so there is nothing to schedule or trigger. To monitor it, use the read-only registry health endpoint, which includes occurrence and recent-resolution statistics alongside tier counts and the deterministic transfer hit rate. It is the same view the in-app registry dashboard reads, so a script polling it sees exactly what you see in the app.
curl https://api.talonic.com/v1/registry/health \
-H "Authorization: Bearer $TALONIC_API_KEY"For best results, process pending confirmations promptly in the Review queue. Unconfirmed fields in the confirm band (0.50-0.79 similarity) remain in a pending state that can affect downstream extraction accuracy. Confirming correct matches strengthens the cluster and improves future resolution, while rejecting incorrect matches prevents bad data from propagating through the knowledge graph. Teams that review confirmations weekly typically see their auto-band match rate increase steadily over the first few months of platform usage.