Field Registry

The Field Registry is Talonic's knowledge graph of every canonical field discovered across your documents. As documents are processed, AI discovers fields and resolves them into unified registry entries, so the platform grows smarter with every document: each new document contributes to a shared understanding of field names, data types, and extraction patterns that benefits all future processing.

Open Explore and select the Field Registry tab to explore the registry. Every canonical field is displayed with its maturity level, data type, occurrence count, and document types.

The registry grows automatically as documents are processed. During extraction, AI discovers fields from each document and resolves them against existing registry entries using three-band matching (exact name match, cluster member match, then semantic embedding similarity). New fields that don't match anything create a Provisional entry. Frequently occurring fields are promoted to higher maturity levels, so the registry naturally converges on a stable set of canonical fields over time.

Each registry entry tracks its occurrence count (how many documents contain this field), data type (string, number, date, etc.), synonyms (alternate names discovered across documents), and master instruction (an AI-synthesized extraction directive).

The registry is the foundation for several downstream features. Jobs use registry fields to pre-fill schema values via lookup cascades before resorting to LLM extraction. Semantic clusters group related registry fields together. Generated schemas are auto-built from registry fields that appear in a given document type. Understanding the registry is key to understanding how Talonic reduces extraction cost and improves accuracy over time.

Each registry field maintains two separate embedding vectors: one optimized for resolution matching (based on the canonical name and synonyms) and one for graph visualization (based on name, type, and instruction). This dual-embedding approach ensures that each concern uses the most appropriate representation. The resolution embedding is what powers the three-band matching during document processing, while the visualization embedding drives the Field Graph clustering view.

Browsing the Registry via API

The Field Registry is also readable through the REST API, allowing you to build custom dashboards, export field data for analysis, or integrate registry information into external tools. Use GET /v1/fields to list registry entries with search, tier, and cluster_id filters, and GET /v1/fields/{id} to retrieve a single field along with its 20 most recent occurrences. This programmatic access is particularly valuable for teams that need to audit their field registry or build automated monitoring around field quality.

curl "https://api.talonic.com/v1/fields?search=vendor&tier=1" \
  -H "Authorization: Bearer $TALONIC_API_KEY"

{
  "data": [
    {
      "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "canonical_name": "vendor_name",
      "display_name": "Vendor Name",
      "data_type": "string",
      "tier": 1,
      "cluster_name": "vendor_name",
      "occurrence_count": 312,
      "master_instruction": "Extract the supplier's legal entity name from the document header...",
      "created_at": "2026-04-25T14:30:00.000Z"
    }
  ],
  "pagination": { "total": 3, "limit": 20, "has_more": false, "next_cursor": null }
}

curl https://api.talonic.com/v1/fields/a1b2c3d4-e5f6-7890-abcd-ef1234567890 \
  -H "Authorization: Bearer $TALONIC_API_KEY"

Batch resolution and promotion evaluation run automatically as documents are processed: after each batch resolution run, the platform resolves unresolved field occurrences against the registry and evaluates whether any Provisional fields qualify for promotion to Established. You do not need to schedule anything; the registry stays current on its own as new documents arrive.

Monitoring Registry Health

A registry health snapshot is available over the public API at GET /v1/registry/health. It returns tier and admission counts, the singleton and weak-name rates, occurrence and recent-resolution stats, the deterministic transfer hit rate (the share of cells filled with no AI call), and coherence and atomicity metrics. This is the same view the in-app registry dashboard reads, and it is read-only: it exposes no lifecycle or cleanup actions. Teams poll it to track how the knowledge graph matures. A rising transfer hit rate means more extraction resolves for free, while a rising singleton or weak-name rate is an early signal that naming or clustering needs attention.

curl https://api.talonic.com/v1/registry/health \
  -H "Authorization: Bearer $TALONIC_API_KEY"

The Organization Ontology Overlay

The registry learns field names bottom-up from your documents, but you can also seed it top-down with an organization ontology — a versioned overlay of your own document types and field concepts that augments the built-in Talonic ontology. You author the doctypes and fields specific to your domain, anchor each doctype to a Talonic type, and publish. Publishing projects your authored fields into the registry as pinned canonical rows (protected from cleanup) and adds your custom doctypes to the classifier on an organization axis that runs alongside the always-on Talonic axis. The overlay is additive: an empty or unpublished ontology leaves capture and classification identical to the Talonic-only path, so adopting it never regresses existing extractions. The full lifecycle — create, import, update, publish, unpublish, delete, and embedding-assisted mapping to Talonic types — is available over the API under /v1/customer-ontologies.