This glossary defines every term the Talonic platform uses, with exactly one meaning per word. If a page, API response, or teammate uses a word differently from how it is defined here, this page wins. Terms that were renamed keep working in the API: machine identifiers such as enum values and field names never change, so the Renamed terms table at the end maps every historical name to its current one.
Foundation
Parameter
Type
Description
Organization
tenant
The top-level account that scopes all data. Users belong to organizations via memberships with a role: owner, editor, or viewer.
Source
ingest channel
Where documents come from: manual upload, a cloud connector (Google Drive, SharePoint, S3, and 9 more), or a dedicated-key API source. A Source is always an ingest channel; where a VALUE comes from is its origin (see Provenance).
Document
unit of data
One uploaded file (PDF, image, spreadsheet, email, and 25+ formats). The unit of OCR, classification, and extraction. A document is a file; the data inside it becomes records and cells.
Document Type
classification
The AI-inferred category of a document (Invoice, Contract, Bill of Lading). Drawn from the Ontology: the Talonic base taxonomy plus your Customer Overlay of custom types.
Ingestion
process
Getting documents into the platform, before any extraction. The ingestion target (upload, extract, or ingest) controls how far processing runs automatically.
Extraction and capture
Parameter
Type
Description
Extraction
process + result
OCR plus AI pulling fields out of a document, and the per-document result object you retrieve from /v1/extractions. Extraction is never a synonym for a Job or a run.
Quick extract
endpoint
The one-call upload-and-extract API (POST /v1/extract). The fastest way to get structured data from a single document.
Capture
discovery mode
Open-discovery extraction: finds ALL data points in a document with no target schema, including whole tables. Captured values form the first value layer.
Digest
summary
A dense, deterministic condensation of a document (type, section outline, salient facts) stamped at extraction time and used by downstream stages.
Planner
extraction AI
The AI that reviews gap patterns in a run and produces typed extraction strategies for unresolved cells. Formerly called the "agent" in extraction contexts; "Agent" now refers only to the in-product copilot.
Batch
deferred processing
Documents grouped for deferred inference at roughly half cost with a 48-hour delivery window (/v1/batches).
Fields and the registry
Parameter
Type
Description
Field
data point
A single piece of structured data: a date, a name, an amount, a clause. A Registry Field is a canonical concept in the Field Registry; a Spec Field is a target column in your Schema.
Field Registry
knowledge graph
Your organization’s unified graph of canonical fields discovered across all documents: semantically clustered, maturity-graded, and enriched with master extraction instructions. The single source of truth for field definitions.
Field Maturity
lifecycle
How proven a Registry Field is: Provisional (newly discovered), Established (recurring and useful), Canonical (universal and fully trusted). API responses carry the numeric tier field: 3 = Provisional, 2 = Established, 1 = Canonical.
Cluster
grouping
A semantic grouping of related fields discovered through embedding similarity, so "Vendor Name", "Supplier Name", and "Company Name" resolve to one concept.
Output shape
Parameter
Type
Description
Schema
column shape
The target output shape you author: which fields (columns) the structured result has. Managed at /v1/schemas.
Spec
production configuration
A Schema plus everything needed to run it in production: the composed rail of stages, Data Policies, validation checkpoints, and an assembly rule. Schemas define shape; Specs define shape plus behavior.
Rail
stage sequence
The composed stage sequence of a Spec: Source, Field Registry, Extraction, Resolution, Validation, Data Product. Compiling the rail produces a Pipeline.
Data Policy
normalization ruleset
A first-class, versioned ruleset that turns structured values into resolved values: lookups, transforms, casts, formatting, computations, and gates. Applied by Resolution.
Dialect
output conventions
Output formatting conventions: date format, number locale, delimiter, null and boolean representation.
Execution
Parameter
Type
Description
Job
quick run
The fast path: an ad-hoc run of a Schema over documents producing a structured grid (rows = documents, columns = fields). Created via /v1/jobs or the Extract button. Formerly also called a "structuring run".
Pipeline
production run
One run of a Spec over documents on the engine, producing a Data Product. Each document flows through Transfer, Extraction, Resolution, and Validation; assembly and review triage follow. "Pipeline" always means a Spec run, nothing else.
Transfer
free phase
The zero-cost phase that fills Spec fields directly from the Field Registry with no AI call. The share of cells filled this way grows as your registry matures.
Resolution
policy phase
Applying Data Policies to structured values: normalization, lookups, casts, and formatting. Resolution always means policy application, never registry name-matching.
Validation
checks + gates
In-pipeline checks producing verdicts: field rules, cross-field coherence, evidence checks, capture cross-checks. A Gate is a validation checkpoint with a severity; blocking gates route failures to Review. Validation never means accuracy measurement (that is Benchmarks).
Data and provenance
Parameter
Type
Description
Record Set
table
A table-like collection of records at one value layer, such as a Job result set or a Data Product table.
Record
row
One row in a record set. Today usually one source document. The ladder: Document (file), Record (row), Cell (value), Claim (fact).
Cell
value
One field value for one record: typed, versioned, and carrying confidence, status, origin, and provenance.
Value layers
lifecycle
The semantic states of cell values: capture (raw discovery), structured (schema-guided), resolved (policy-normalized), product (canonical, validated output).
Claim
fact
A deterministic (subject, predicate, object) fact synthesized from fields and spans, with an evidence quote and a grounded flag. Retrieved via /v1/documents/{id}/claims.
Provenance
audit trail
Where a value comes from: its origin, confidence, resolution type, source span, and reasoning trace. Per cell. Document-level ancestry is called lineage; supporting quotes on cases and claims are called evidence.
Span
source location
The located verbatim text region in the source document that backs a value. May be marked approximate when recovered after the fact.
Assembly and cases
Parameter
Type
Description
Assembly
composition stage
The Spec stage that groups related documents by a shared field value and composes each group into one output record.
Anchor
seed document
The document in an assembly group whose values seed the composed record.
Amendment
override document
A non-Anchor document that overrides selected fields on the composed record when its rule fires, typically newest-signed-wins.
Data Product
output artifact
The assembled, validated output dataset of a Pipeline, with sharing, export, and delivery.
Case
document group
Documents automatically connected through shared entities such as names, reference numbers, or project codes. A case ends in the Closed state (the API value is "resolved" for compatibility).
Linking
discovery engine
The link keys, document links, and entity graph that discover cases.
Anomaly
inconsistency
A structural inconsistency detected within a case, such as conflicting field values across linked documents.
Quality and review
Parameter
Type
Description
Benchmarks
accuracy measurement
Measuring extraction accuracy against labeled data. Benchmarks are distinct from Validation: Validation gates a live run, Benchmarks measure accuracy offline.
Ground Truth
labeled data
A curated set of documents with known-correct field values: the gold standard Benchmarks compare against.
Review
human decisions
The umbrella for all human decision surfaces. Record Review: record-level decisions before export. Field Review: cell-level decisions on held values. The Review Queue in the navigation collects both. Approve and Reject are the actions.
Matching
reference comparison
Comparing extracted values against Reference Data with exact or fuzzy strategies. Reconciliation is a Matching mode that verifies a whole run against a reference dataset.
Reference Data
lookup dataset
Uploaded or synced lookup tables (CSV/XLSX) that drive Matching and Resolution lookups.
Delivery, events, and billing
Parameter
Type
Description
Delivery
outbound edge
Routing produced data to external systems: Destinations receive it, Bindings decide what goes where in which format.
Destination
connector instance
A configured endpoint data is delivered to: webhook, SFTP, S3, Azure Blob, Google Drive, OneDrive, or Google Sheets.
Binding
delivery rule
The delivery configuration tuple: which event, which deliverable and format, which destination, which field map.
Event
timeline fact
A fact on your organization’s timeline (/v1/events), named in the past tense: extraction.completed, document.ingested. Existing webhook subscriptions keep their legacy event names until you opt in to v2 names per endpoint.
Webhook
push channel
HMAC-signed push delivery of events to your endpoint, with retries.
Credit
spend unit
The universal unit of spend for metered operations. One balance, one rate table.
Usage
consumption record
Consumption accounting: tokens, operations, and per-document cost. The Usage page shows both.
Plan
billing policy
Your billing and enforcement policy: self-serve or enterprise. Distinct from the API tier, which governs throughput, and from Field Maturity.
Agent
copilot
The in-product AI copilot (Cmd+I): a conversational assistant that can query your workspace, mine fields on demand, and navigate for you. The only thing called "Agent" on the platform.
Renamed terms
These historical names were retired in favor of a single canonical vocabulary. Old API routes keep working as aliases, and machine identifiers (enum values, field names, webhook event names on existing subscriptions) never change.
Parameter
Type
Description
Structure / Structuring run
renamed
Now: Pipelines (the surface) and Job (the quick run).
Extraction (as a run)
renamed
Now: Job. Extraction refers only to the process and its per-document result.
Approval Queue
renamed
Now: Record Review, under the Review umbrella.
Validation (accuracy pages)
renamed
Now: Benchmarks. Validation refers only to in-pipeline checks and gates.
Tier 1 / 2 / 3 (fields)
renamed
Now: Canonical / Established / Provisional maturity. The numeric tier field remains in API responses.
Inputs / Ingest (navigation)
renamed
Now: Sources.
Agent (extraction phase)
renamed
Now: Planner. API enum values such as agent_derived are unchanged.
Golden sample
renamed
Now: Ground Truth.
Usage & Registry (page)
renamed
Now: Usage.
Customer (admin)
renamed
Now: Organization.
Integration safety: renames affect words in the product and documentation, not machine contracts. Enum values, API field names, database identifiers, and webhook event names on existing subscriptions are frozen. Where a frozen identifier differs from the spoken term (tier vs. maturity, agent_derived vs. Planner-derived, resolved vs. Closed), this glossary is the mapping.
Frequently asked questions
What is the difference between a Job and a Pipeline in Talonic?+−
A Job is the quick path: an ad-hoc run of a Schema over documents that produces a structured grid. A Pipeline is the production path: one run of a Spec (a Schema plus rail, Data Policies, validation gates, and assembly) on the engine, producing a Data Product.
What is the difference between a Schema and a Spec?+−
A Schema defines the target column shape: which fields your output has. A Spec is that Schema plus everything needed to run it in production: the composed rail of stages, Data Policies for normalization, validation checkpoints, and an assembly rule.
What do Canonical, Established, and Provisional mean for fields?+−
They are Field Maturity levels in the Field Registry. Provisional fields are newly discovered, Established fields recur and are proven useful, and Canonical fields are universal and fully trusted. API responses carry the numeric tier field: 3 = Provisional, 2 = Established, 1 = Canonical.
Did Talonic renames break my API integration?+−
No. Renames affect product and documentation vocabulary only. API routes keep working via aliases, and machine identifiers (enum values, field names, webhook event names on existing subscriptions) never change.
What is the difference between Validation and Benchmarks?+−
Validation is the in-pipeline checks and gates that produce verdicts on a live run and can route failures to Review. Benchmarks measure extraction accuracy offline against Ground Truth: curated documents with known-correct values.