Assemblies

Assembly composes multiple documents into a single record: an anchor document seeds the composed record, amendment documents override individual fields, and a grouping field bins related documents together so each group produces one assembled record. Assembly is not a standalone surface or a query-time view; it runs as a pipeline stage in the Spec rail.

How composition works

When the assembly stage runs, it writes composed values as new cell versions tagged with source='pipeline_assembly'. The anchor document provides the base record; each amendment document overrides only the fields it carries, so later amendments take precedence over the anchor for the fields they touch. The grouping field determines which documents are folded into the same record, giving you full traceability from each composed field back to the document that supplied it.

Configure assembly when you need one record per logical entity assembled from several documents: an original contract plus its amendments, or an invoice plus its credit notes. Because assembly is a pipeline stage, it runs as part of the normal pipeline execution rather than as a separate manual step. Re-running the pipeline re-composes the records from the current document set.

• Assembly runs as a pipeline stage in the Spec rail, once after the pipeline finishes
• An anchor document seeds the composed record; amendment documents override individual fields
• A grouping field bins related documents into a single assembled record
• Composed values are written as cell versions tagged source='pipeline_assembly'
• Full traceability from every composed field back to its source document
• There is no /v1/assemblies endpoint; configure assembly as a pipeline stage

Exporting assembled output

The composed records flow into the data product that the pipeline feeds, so the assembled output is delivered and shared the same way as any other data product. Two CSV exports are available: the plain export contains the values themselves, and the audit export contains the handover trail. For a pipeline-backed product, cells still held in Record Review (pending_approval) are written empty in the plain export and as PENDING_REVIEW markers in the audit export; the held value never leaves the API.

# Plain CSV (values only; review-held cells written empty):
curl -s https://api.talonic.com/v1/data-products/PRODUCT_UUID/export/plain \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -o "q1_invoices.csv"

# Audit CSV (handover trail; review-held cells marked PENDING_REVIEW):
curl -s https://api.talonic.com/v1/data-products/PRODUCT_UUID/export/audit \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -o "q1_invoices_audit.csv"

# CSV values are never coerced to numbers — leading zeros
# on codes like ZIP codes and account numbers are preserved.

Because assembly is a pipeline stage, it follows the cadence of your pipeline runs. Each run re-composes records from the current document set: when an amendment arrives for an entity already in the corpus, the next pipeline run folds it into the anchor record and overrides the fields it carries. The versioned pipeline_assembly cells let you trace how a composed value changed across runs, which is valuable for audit workflows where you need to track what changed between document revisions.