Change Review

Change review is the governance practice of checkpointing changes to schemas, shared dialects, and reference primitives before they take effect in live workflows. In Talonic it is exercised mainly through the Spec draft/publish flow and Review (the Review Queue and Field Review, worked from Products), which together stop unreviewed modifications from reaching production data pipelines.

Two surfaces implement the checkpoint. Pipeline changes stay in a draft Spec (/specs) until you explicitly publish them, and flagged fields are held for review before delivery. Products in the sidebar is the review hub: its Status column shows which data products need review, each product opens in Review Mode, and the Decision log tab records every decision with the reviewer's email. Treat publishing a Spec and clearing review as the moments where a second pair of eyes verifies a change.

Change review is particularly important for workspaces that feed downstream systems through delivery bindings. A small change to a schema field mapping or a reference primitive value can ripple through to every document processed after that point. The review process creates a checkpoint where a second pair of eyes can verify the change before it goes live.

Most teams formalize this review discipline as soon as their workspace transitions from development to production. During the initial setup phase, you can iterate quickly by publishing Spec changes directly. Once your schemas, dialects, and reference data are stable and data is flowing to downstream systems, route changes through draft Specs and Record Review to protect against accidental modifications that could disrupt live pipelines.

Workspace Settings has a Change Review tab, reached from the user menu, that lists proposed changes to shared dialects and reference primitives with a pending view, a history view, and approve or reject (with a reason) actions. The approval workflow behind it is not active yet: dialect and reference edits currently save directly, so the tab stays empty. Until it is switched on, the draft Spec and the review of flagged fields are the checkpoints that actually hold a change back.

• Schema changes — field additions, removals, mapping updates, and format constraint modifications.
• Shared dialect changes — date format, number locale, delimiter, and encoding updates.
• Reference primitive changes — new versions of lookup tables and key-value modifications.
• Delivery binding changes — modifications to outbound delivery destinations, field maps, or signal filters.
• Routing rule changes — additions or modifications to document routing rules that assign schemas automatically.
• Format constraint changes — regex pattern updates or fallback behavior modifications on schema fields.

There is no /v1/workspace/settings endpoint and no dedicated change-review API. Governance is expressed through the resources that already carry draft/publish and approval state: a Spec stays in draft until published, and fields that trip validation are held for review (/v1/field-reviews, with record-level review at /v1/review) before delivery. Treat publishing a Spec and clearing review as the checkpoints where a second pair of eyes verifies a change before it reaches live pipelines.

Change review is the governance layer that protects production workspaces from unintended disruptions. In a production environment, a small change to a schema field mapping or reference data value can ripple through to every document processed after that point. By keeping pipeline edits in a draft Spec until they are published, and by clearing flagged fields in Review Mode before delivery, a second pair of eyes can verify the technical and business impact before the change goes live. This is particularly important for organizations with compliance requirements where changes to data extraction rules must be documented and approved.

A common workflow for teams transitioning from development to production is to publish Spec changes directly during the initial setup phase for faster iteration. Once schemas, dialects, and reference data are stable and data is flowing to downstream systems through delivery bindings, formalize the draft/publish discipline. From that point forward, any modification (whether it is adding a field to a schema, updating a reference data version, or changing a delivery binding filter) lands in a draft Spec and is reviewed before it is published into the live pipeline.