Field Matching
Field matching is how Talonic maps each field you add to a schema template against the Field Registry. Exact name matches are applied instantly, while semantic and composite matches appear as suggestions for your confirmation. If no match is found, the field is marked Unmapped and you should provide a manual extraction instruction so the AI knows how to extract that value from your documents.
Match types
| Parameter | Type | Description |
|---|---|---|
| Exact | auto | Field name directly matches a canonical registry field. |
| Semantic | AI | AI finds an equivalent field with a different name. |
| Composite | AI | Multiple registry fields combine to derive this field. |
| Unmapped | manual | No match found — needs manual extraction instructions. |
The matching engine uses a three-band resolution process under the hood. First, it checks for an exact name match against canonical registry field names and their synonyms. If no exact match is found, it computes embedding similarity between your field name and every registry field, surfacing semantic matches above a 0.5 confidence threshold. Matches above 0.8 are auto-accepted; those between 0.5 and 0.8 require your confirmation.
Matched fields inherit the registry's AI-synthesized master instruction, which tells extraction exactly how to locate and extract that value from documents. This is why matching matters — a well-matched field leverages all the intelligence the system has built up from processing your document corpus. Unmapped fields rely solely on your manual instruction, so they may need a few correction cycles before reaching the same accuracy.
You can trigger a Rematch on all fields at any time from the template editor. This is useful after the registry has grown — fields that were previously unmapped may now find matches as new extractions contribute to the registry. For best results, use descriptive field names that reflect the actual data (e.g., contract_start_date rather than field_1).
# ?maturity=core|proven|candidate (the legacy ?tier=1|2|3 is still accepted)
curl -s "https://api.talonic.com/v1/fields?maturity=core&limit=20" \
-H "Authorization: Bearer $TALONIC_API_KEY"
# Response:
# {
# "data": [
# {
# "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
# "canonical_name": "invoice_number",
# "display_name": "Invoice Number",
# "data_type": "string",
# "tier": 1,
# "maturity": "core",
# "cluster_name": "invoice_number",
# "occurrence_count": 342,
# "master_instruction": "Extract the unique invoice identifier..."
# }
# ],
# "pagination": { "total": 156, "limit": 20, "has_more": true, "next_cursor": "ZDFhMmIzYzR8..." }
# }Rematching is particularly useful after bulk document ingestion. When a large batch of new documents introduces previously unseen fields into the registry, running a Rematch on your templates can upgrade unmapped fields to exact or semantic matches without any manual configuration. The template editor summarizes how many fields changed status, so you can quickly assess whether the rematch had a meaningful impact on your template coverage. Browsing the registry over the API (above) helps you choose field names that will match: naming your template field after an existing canonical name guarantees an exact match.
Field matching is easiest when you know what the registry holds. Open Registry in the sidebar to browse the Field Registry: each row shows a field's Status (Core, Proven, or Candidate), how often and in how many documents it occurs, and which Specs already use it. Selecting a field opens an inspector with its meaning, the source evidence behind it, where it is used, and related fields. Naming your template field after a Core field's canonical name is the most reliable way to get an exact match.