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 through memberships, each with one Role.
Role
permission level
What a member may do, in ascending order: Viewer (read-only), Member (shown in the app as Contract Management: approves, corrects and overrides review items), Senior Member (shown as Senior Contract Management: adds complex-field decisions and pinning review fields), and Admin (manages members, roles and workspace-wide rules such as field deprioritization). The stored API value for Admin is owner.
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: Candidate (newly discovered), Proven (recurring and useful), Core (universal and fully trusted). API responses carry the frozen numeric tier field (3 = Candidate, 2 = Proven, 1 = Core) next to a named maturity value; filter with ?maturity=core|proven|candidate. "Tier" otherwise means only API throughput.
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, and Data Product at minimum, with optional Matching, Agent (via MCP) handoff, Resolution, Validation, and Assembly stages. Running the Spec compiles the rail into 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. For recurring production work, use a Spec and its Pipelines instead.
Pipeline
production run
One run of a Spec over documents on the engine, producing a Data Product. Each document flows through the composed phases (Transfer, Extraction, Matching, an optional Agent (via MCP) handoff, Resolution, Validation); assembly and review triage follow. "Pipeline" always means a Spec run, nothing else; the steps inside a Job are called Job phases.
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. Products is the review hub: its Status column shows what needs review, its Decision log tab records every decision, and each product opens in Review Mode. Approve remains the verb.
Review Mode
review workbench
The per-product review workbench opened from Products: the document beside a decision rail of fields to review, with Compare across linked documents, pinned fields, in-document search, and rule outcomes when opened from an app.
Review Queue
review list
The cross-pipeline list of held field values awaiting a decision (approve, correct, override). It is reachable by direct URL at /review/queue; day-to-day review starts from Products.
Recommendation
review action
What a reviewer without the right to decide a complex-tagged field leaves instead of a decision: a suggested action that a Senior Member or Admin can use when confirming, credited to the recommender.
Field deprioritization
review rule
An Admin's standing rule that a field is not reviewed for now: open items on it are demoted out of the queue with the stated reason, and later runs are demoted on arrival until the rule is lifted.
Matching
reference comparison
Candidate finding: linking a document to the Reference Data row it belongs to, using exact or fuzzy strategies. Reconciliation is a separate concept: business rules layered on top of matching outcomes.
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 external handoff stage in a Spec is always written Agent (via MCP); the extraction AI is the Planner.
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), Pipeline run (one run of a Spec), 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: Review Queue and Field Review, under the Review umbrella. Approve remains the verb.
Approval Gates
renamed
Now: Review Gates.
Review (navigation)
moved
Now: Products, the review hub (Status column, Decision log tab, Review Mode). /review stays reachable by direct URL.
Validation (accuracy pages)
renamed
Now: Benchmarks. Validation refers only to in-pipeline checks and gates.
Tier 1 / 2 / 3 (fields)
renamed
Now: Core / Proven / Candidate maturity (formerly Canonical / Established / Provisional). The numeric tier field remains in API responses.
Inputs / Ingest (navigation)
renamed
Now: Sources, opened from the header of the Documents page, where uploads happen.
Explore (navigation)
renamed
Now: Registry. The Field Registry is its default tab.
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, owner vs. Admin, senior_member vs. Senior Member), 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 Core, Proven, and Candidate mean for fields?+−
They are Field Maturity levels in the Field Registry. Candidate fields are newly discovered, Proven fields recur and are proven useful, and Core fields are universal and fully trusted. API responses carry the numeric tier field (3 = Candidate, 2 = Proven, 1 = Core) and a named maturity value.
Where do I review held values now?+−
Start from Products in the sidebar. The Status column shows which data products need review, each product opens in Review Mode, and the Decision log tab lists every decision with the reviewer. The older /review pages remain reachable by direct URL.
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.