Data pipelines
Distinguish a graph draft, a saved definition, a run and a recurring schedule
A data pipeline describes how records move through configured steps. Its plan is a versioned graph of nodes and edges. A run executes a saved version. A schedule requests later executions. These are separate objects and actions.
Graph, version and execution
| Object | Purpose |
|---|---|
| Draft | Working changes you are authoring and reviewing |
| Saved version | Recorded graph configuration used for execution |
| Run | One execution with its own status, steps, outputs and errors |
| Schedule | Recurring execution settings, saved separately |
Nodes can read endpoints, transform records, map ontology facts, invoke a forecaster or write results. Edges connect declared ports so downstream steps receive the intended data. A graph shape does not prove that external reads or writes succeeded.
The authoring lifecycle
Describe the task to the Studio assistant or configure the graph through its supported controls. Inspect proposed changes, validate the graph and save a version. Run it separately, then inspect source records, step outputs and the destination.
Configuration preflight checks supported configuration and bindings. It does not process a sample dataset or preview real output. A saved graph does not automatically create a recurring schedule.
Example: measurements to a reporting table
An ingress endpoint reads equipment measurements. A transform prepares the required columns. An egress endpoint writes them to a reporting table. The source and destination each need the appropriate installed capability and permissions. After saving and running, compare the receiving table with a known source record.
Policy metadata expresses intended behavior; enforced write semantics and authorization come from the configured policy and runtime path. Check those before treating a graph label as an approval guarantee.
Build a first pipeline
Data Pipelines explains the graph and lifecycle. Your first pipeline includes a complete bounded database-to-database example. Run history explains execution inspection and recovery.