Core Concepts
Talonic is built on ten interconnected core concepts: Sources, Documents, Fields, the Field Registry, Schemas, Jobs, Specs, Pipelines, Cases, and Provenance. Sources bring documents in, extraction turns them into fields, the Field Registry organizes those fields into a knowledge graph, and schemas define the structured output you get back. Understanding these concepts will help you navigate every feature of the platform.
Each concept builds on the previous ones. Sources produce Documents, documents yield Fields, fields aggregate into the Field Registry, and the registry powers Schemas. A schema is run in one of two ways: a Job runs documents against it as a quick one-time task, or a Spec wraps it with a reusable configuration that runs as a Pipeline for production. Both produce structured output with Provenance. Cases emerge organically when documents share entities like names, reference numbers, or project codes.
| Parameter | Type | Description |
|---|---|---|
| Source | entry point | Where documents come from — manual upload, folder, Google Drive, or API connection. |
| Document | unit of data | A single uploaded file. Talonic extracts text, classifies the type, and captures every data point. |
| Field | data point | A single piece of structured data discovered in a document: a date, a name, an amount, a clause. |
| Field Registry | knowledge graph | The unified graph of all canonical fields — organized by maturity level, clustered semantically, with master extraction instructions. |
| Schema | output definition | AI-generated per document type (Generated), or user-defined for specific output needs (Template). |
| Job | quick run | A schema applied to a set of documents as a one-time task. Produces a structured grid: rows = documents, columns = fields. The fast path for ad-hoc work. |
| Spec | configuration | A reusable configuration over one schema: a composed rail of stages plus Data Policies, validation checkpoints, and an assembly rule. The production path. |
| Pipeline | execution | One compiled run of a Spec over a set of documents on the engine. Runs transfer, extraction, resolution, and validation per document, then assembly; held fields are reviewed from Products. |
| Case | document group | Related documents connected through shared entities (names, reference numbers, project codes). |
| Provenance | audit trail | Per-cell metadata: which phase filled it, confidence score, reasoning trace, source references. |
Understanding the relationship between these concepts is key to getting the most from the platform. When you upload documents, the extraction pipeline discovers every data point and feeds them into the Field Registry. The registry uses AI embeddings to cluster semantically similar fields — so "Vendor Name", "Supplier Name", and "Company Name" are recognized as the same concept. Over time, frequently occurring fields are promoted to higher maturity levels, and the platform synthesizes master extraction instructions that encode the best way to extract each field.
The Schema layer sits on top of the registry and defines what output you need. You can use auto-generated schemas that the platform creates for each document type, or build custom template schemas by selecting specific fields from the registry. When a schema is applied to documents in a Job, its four phases fill every cell, starting with free graph lookups and falling back to the Planner for the remainder. The result is a structured grid where each row is a document and each column is a field.
For work that recurs, you promote a schema into a Spec: a reusable configuration that adds a composed rail of stages, Data Policies for normalization, validation checkpoints that gate quality, and an assembly rule for combining related documents. Running a Spec compiles its rail and executes it as a Pipeline on the engine, processing each document through transfer, extraction, resolution, and validation in sequence. Fields that fail a blocking checkpoint are held for a human decision before they ship, and reviewers work them from Products in Review Mode. Jobs are the quick path for ad-hoc work; Specs and Pipelines are the production path you set up once and run repeatedly.
Cases add another dimension to document intelligence. When two or more documents share entities — like a common vendor name, reference number, or project code — the platform automatically connects them into a case. Cases provide a cross-document view that reveals relationships invisible at the individual document level. For example, a purchase order and its corresponding invoice might share a PO number, linking them into a case that lets you verify consistency across the two documents. The linking engine builds a bipartite graph of document-entity relationships and uses connected components to identify cases automatically.
Exploring Concepts via API
Every core concept in the platform has a corresponding API namespace. You can list documents, browse the field registry, inspect schemas, retrieve job results, and explore cases programmatically. For example, to see all fields discovered across your documents, query the field registry endpoint. The response includes each field's canonical name, maturity level (maturity: core, proven or candidate, alongside the frozen numeric tier 1 to 3), occurrence count, and data type — giving you a complete picture of your knowledge graph.
curl https://api.talonic.com/v1/fields \
-H "Authorization: Bearer $TALONIC_API_KEY"{
"data": [
{
"id": "fld_1a2b3c",
"canonical_name": "invoice_number",
"tier": 1,
"maturity": "core",
"occurrence_count": 342,
"data_type": "string"
}
],
"pagination": { "total": 156, "limit": 20, "has_more": true }
}The relationship between concepts is visible through the API as well. When you retrieve a job's results, each cell includes provenance metadata that tells you which pipeline phase filled it, the confidence score, and the reasoning trace. This end-to-end traceability from source document through the field registry to structured output is what makes Talonic auditable at every step of the pipeline.
curl https://api.talonic.com/v1/jobs/job_abc123/results \
-H "Authorization: Bearer $TALONIC_API_KEY"