The tag list managed through Control Plane is also available to your ETL pipelines as a read-only data dictionary table called Tag List. Understanding how it connects to pipelines is important when setting up or migrating workspaces.
Tag List as a Data Dictionary
When Control Plane is enabled, the tag list appears as a data dictionary table named Tag List in the workspace. This table:
Is read-only in the pipeline editor — it can only be modified through Control Plane (via the UI or CSV upload)
Contains all tag schema fields (machine, source, name, raw_tag_name, data_type, aggregate, forward_fill) plus semantic fields (display_name, default_aggregation, stat_type, display_hide, unit_of_measure, scale_of_measure)
Can be referenced in pipeline template Jinja expressions, just like any other data dictionary
Pipelines can use {{ Tag List }} references in their templates to look up tag configuration at runtime. This replaces the previous pattern of embedding tag data in custom, ad-hoc data dictionary tables.
Control Plane Map Machines Operator
With Control Plane enabled, pipelines use a new Control Plane-aware Map Machines operator instead of the legacy Map Machines operator. This operator reads machine and tag configuration directly from the Control Plane data (facilities, machine types, machines, and the Tag List) rather than requiring this data to be defined inline in the pipeline configuration.
This means:
Pipeline definitions are simpler — machine and tag data is managed centrally in Control Plane, not embedded in each pipeline
Changes propagate automatically — when you update machines or tags in Control Plane, the operator picks up the changes at the next pipeline run without needing to modify the pipeline itself
⚠️ Warning: When migrating an existing workspace to Control Plane, all legacy Map Machines operators must be replaced with the Control Plane-aware version, and any Jinja expressions referencing prior tag data dictionaries must be updated to reference the Tag List data dictionary. After these changes, redeploy pipelines to recompute dependencies.
📝 Note: The final name of the Control Plane Map Machines operator may differ from pre-release documentation. Refer to the operator list in your pipeline editor for the current name.
Pipeline Dependency Tracking
With Control Plane enabled, pipelines automatically track dependencies on the assets they use. When you deploy a pipeline, it records which machines, machine types, and tag list data it depends on. After deployment, Control Plane monitors these dependencies and flags when changes require attention.
The standard pipeline dependencies (data dictionaries and templates) continue to work as before. Control Plane adds dependencies on:
Machine assets used by the pipeline
Machine Type assets used by the pipeline
Tag List rows for the machine types referenced by the pipeline
This dependency tracking is what drives the edit mode and revert behaviors described below.
Edit Mode
A pipeline enters edit mode when any of its dependencies have changed since it was last deployed. Edit mode signals that the pipeline's deployed configuration is out of date and a redeployment is needed to pick up the latest changes.
Changes that trigger edit mode:
Change | Why It Triggers Edit Mode |
|---|---|
Add, remove, or rename a tag | Tag list structure changed |
Change a tag's data type, aggregate, or forward fill | Tag list schema field changed |
Change a machine's name or machine type assignment | Machine identity changed |
Change a machine type's name | Machine type identity changed |
📝 Note: Edit mode is scoped to affected pipelines only. A tag list change only triggers edit mode for pipelines that reference the affected machine types. Editing tags for a machine type not used by a pipeline will not put that pipeline into edit mode.
Changes that do NOT trigger edit mode:
Some changes are excluded from dependency checks because they only affect display or metadata, not pipeline behavior:
Change | Why It Does Not Trigger Edit Mode |
|---|---|
Change a tag's display name, default aggregation, stat type, display hide, unit, or scale | Semantic fields — applied via overlay at read time |
Change a machine's display name, description, or image | Display-only metadata |
Change a machine type's display name | Display-only metadata |
Tag semantic fields (display name, default aggregation, stat type, display hide, unit of measure, scale of measure) are applied through a metadata overlay at read time. These changes take effect immediately in platform analytics views — charts, selectors, and column pickers reflect the update without any pipeline action.
📝 Note: The semantic overlay currently applies to cycle machine types only. Part types, downtime, and defect models are not yet covered.
⚠️ Warning: External ODBC connections always reflect pipeline-embedded metadata, not the semantic overlay. To update metadata visible through ODBC, the pipeline must be redeployed regardless of whether the change is schema or semantic.
Revert to Deployed
If a pipeline is in edit mode and you want to discard the pending changes, you can revert the pipeline to its deployed state. This restores the pipeline and its dependencies to the configuration that was active at the time of the last deployment.
When you revert a pipeline with Control Plane enabled:
Machine and Machine Type assets are reverted only if their identity fields changed. If only display-only fields were modified (display name, description, image), those edits are preserved — the revert does not touch them.
Tag List rows are reverted using a partial merge: only the rows belonging to machine types used by this pipeline are restored to their deployed state. Rows for other machine types are left unchanged. This prevents reverting one pipeline from overwriting tag changes made for a different pipeline.
Data dictionaries and templates are reverted as they would be without Control Plane.
⚠️ Warning: If the tag list column structure has changed since deployment (columns added or removed), the partial merge cannot be performed and the revert falls back to a full restore of the entire tag list to its deployed state.
Validation
Control Plane automatically validates your workspace configuration when changes are made. Validation is continuous — issues are flagged as you work so you can resolve them before deploying pipelines.
What gets validated:
Asset Type | Validation Rules |
|---|---|
Facility | Required fields (factory name, display name); unique factory name across the workspace |
Line | Required fields (line name, display name); unique line name within its facility |
Machine Type | Required fields (name, display name); unique name across the workspace |
Machine | Required fields (machine name, display name, machine type, facility); unique machine name; valid machine type and facility references |
Tag List | All machine values must reference an existing machine; if a machine is deleted or renamed, tags referencing it are flagged as violations |
Dependency-driven revalidation:
When you change one asset, related assets are automatically revalidated:
Renaming or deleting a machine → tag list is revalidated (tags may now reference a non-existent machine) and facility is revalidated
Renaming or deleting a machine type → machines of that type are revalidated
Renaming or deleting a facility → machines in that facility are revalidated
If validation issues are found, they appear as warnings in the workspace. Resolve all validation issues before deploying pipelines.