PI System Governance: A Practical Framework for Managing PI Data, AF, Lineage, and Change
The PI System often becomes one of the most important operational data platforms in an industrial organization. Over time, though, it can also become harder to manage.
Teams add PI Tags, AF Elements, calculations, interfaces, displays, and downstream applications. Engineers change configuration. New users build on existing data. Old resources often remain long after their original purpose is gone.
The environment may still work, but it becomes harder to understand, trust, and maintain.
PI System governance is the set of practices used to keep operational data understandable, trustworthy, traceable, and controlled as the PI environment changes.
A practical PI System governance program should cover six areas:
Ownership and standards
Context and asset models
Data health and fidelity
Lineage and dependencies
Change management and auditability
Lifecycle and continuous monitoring
The purpose is to reduce operational risk, make the PI environment easier to maintain, and make its data more useful for operations, analytics, and AI.
PI administration and PI governance are different
PI administration focuses on keeping the environment running. That can include managing PI Data Archive servers, maintaining interfaces and connectors, configuring tags, supporting Asset Framework, managing security, and troubleshooting problems.
Governance deals with a different set of questions. Should this tag still exist? Who owns it? Is it mapped to the right asset? Is it still used? What depends on it? Has it changed, and what could be affected if it changes again?
A useful distinction is that PI administration keeps the system operating, while PI governance keeps the data and configuration understandable, trustworthy, and controlled. Mature PI environments need both.
1. Define ownership and standards
Governance starts with ownership. In many mature PI environments, teams know who manages the infrastructure but have less clarity around who owns the meaning, use, and lifecycle of the data.
A PI administrator may be responsible for a tag technically, but that does not automatically mean they should decide whether the tag is still needed, whether the engineering unit is correct, whether it belongs in AF, or whether a calculation is still valid.
Those decisions often require input from operations, engineering, reliability, automation, and data teams.
Ownership can be assigned at different levels depending on how the organization works. Common examples include site owners, process-area owners, asset owners, data owners, AF model owners, and application owners.
Standards matter as well. At a minimum, organizations should define the conventions that prevent the most confusion and rework, such as:
PI Tag naming conventions
AF naming standards
Required descriptions
Engineering unit standards
AF Template standards
Calculation naming standards
Rules for creating new PI resources
Rules for retiring unused resources
The goal is not to document every possible rule. Start with the standards that help people understand what exists, why it exists, and how it should be maintained.
2. Govern context and asset models
A PI Tag can contain useful process data without giving a person or application enough context to understand what the value means.
This becomes more important when the same PI data is used by reliability teams, data scientists, Power BI users, cloud applications, AI systems, and enterprise data platforms.
Asset Framework can provide much of this context. It can show which equipment a value belongs to, where that equipment sits in a hierarchy, which measurements are related, which assets share the same template, and which calculations apply to them.
AF can also become inconsistent over time. Different sites may model the same type of equipment differently. Templates can diverge, attributes can be duplicated, and hard-coded tags can remain outside the asset model.
A governance program should periodically review whether important operational data has enough context. Useful checks include:
Are important PI Tags mapped to AF Attributes?
Are asset hierarchies consistent?
Are AF Templates used where they make sense?
Are attribute names and descriptions clear?
Are engineering units correct?
Are duplicate structures present?
Are obsolete structures still in use?
Not every historical tag needs a complete semantic model. Start with the data that supports critical operations, reporting, analytics, and AI.
3. Monitor data health
Governance also applies to the values themselves. A PI Tag can exist, update regularly, and still provide poor information.
Common problems include stale data, missing values, flatlined sensors, incorrect scaling, failed calculations, data gaps, timestamp problems, sensor drift, incorrect source mappings, and unexpected process behavior.
A value can look valid and still be wrong. For example, a pressure sensor may continue to report a plausible number after it stops responding correctly. A simple range check may not catch the problem because the value still falls inside the expected range.
For important operational data, teams should monitor stale values, unexpected flatlines, missing data, abnormal ranges, failed calculations, source mappings, engineering units, and changes in expected behavior.
Historical behavior and relationships between measurements can also help reduce false positives. A tank level, laboratory result, pressure measurement, and valve state should not all be evaluated with the same rules.
Data health should be monitored continuously rather than waiting for someone to notice that a trend looks wrong.
4. Understand lineage and dependencies
One PI value can support many downstream applications.
A typical path might look like:
PLC or DCS → interface or connector → PI Tag → AF Attribute → PI Analysis → PI Vision → Power BI → AI application
A change anywhere in that chain can affect downstream users, but many organizations cannot easily answer basic questions such as where a value came from, which calculations use it, which displays depend on it, or what would be affected if it changed.
That is both a governance problem and a maintenance problem.
Without lineage, teams often rely on tribal knowledge. That becomes risky when experienced engineers leave, systems are migrated, or new teams start using data that was created years earlier.
For important resources, teams should establish traceability across source systems, interfaces, PI Tags, AF Attributes, PI Analyses, PI Vision displays, reports, data platforms, and AI applications.
Indirect dependencies matter too. A PI Analysis may depend on several AF Attributes, each of which depends on multiple PI Tags. The output may then feed several dashboards or applications.
Good governance makes those relationships visible before someone has to reconstruct them during an incident.
5. Govern configuration changes
PI environments change constantly.
Engineers modify tag configuration, scan rates, compression settings, exception settings, AF Attributes, AF Templates, PI Analyses, interfaces, data sources, and displays. Most of those changes are legitimate, but they can still create downstream problems.
The issue is often visibility.
Teams should be able to answer:
What changed?
When did it change?
Who changed it?
Why did it change?
What can the change affect?
Consider a PI Analysis whose input gets changed. The analysis may continue to run, the PI Vision display may continue to show values, and a downstream AI model may continue to consume the result.
Everything appears operational, but the meaning of the data has changed.
For important configuration, organizations should maintain an audit trail that records the resource that changed, the previous configuration, the new configuration, who or what made the change, when it happened, why it happened, and what downstream resources may be affected.
The strongest approach combines audit history with lineage. That lets teams understand both what changed and what that change can affect.
6. Manage the PI lifecycle continuously
PI governance should not be treated as a cleanup project that happens every few years.
PI environments grow continuously. New tags are added, projects introduce new interfaces, plants add assets, AF structures evolve, displays are replaced, analytics teams create new dependencies, and AI applications begin consuming existing data in new ways.
A PI environment that is well governed today can become difficult to manage again if those changes are not reviewed.
A continuous governance process should periodically review:
New PI Tags
New AF resources
New calculations
New downstream dependencies
Unused resources
Duplicate resources
Data quality issues
Configuration changes
Ownership gaps
The aim is to make governance part of normal PI operations rather than a periodic recovery effort.
PI System governance checklist
Use this checklist to assess a PI environment.
Ownership and standards
Is there a clear owner for important PI data?
Are naming standards defined?
Are engineering unit standards defined?
Are AF modeling standards documented?
Are teams clear on who can create or change important resources?
Context and asset models
Are important PI Tags mapped to assets?
Are AF hierarchies consistent?
Are AF Templates used consistently?
Are descriptions clear?
Are duplicate structures present?
Are obsolete structures still in use?
Data health and fidelity
Are important tags updating as expected?
Are stale values monitored?
Are unexpected flatlines detected?
Are missing data periods visible?
Are calculations monitored?
Are units and scaling correct?
Does the data still represent the physical process correctly?
Lineage and dependencies
Can you identify the source of important PI data?
Can you trace PI Tags into AF?
Can you trace calculations?
Can you identify PI Vision dependencies?
Can you identify reporting dependencies?
Can you identify AI and analytics consumers?
Change management and auditability
Can you identify important PI configuration changes?
Can you identify who made the change?
Can you identify when it happened?
Is the reason for the change documented?
Can you identify downstream impact?
Lifecycle and monitoring
Are unused resources identified?
Are duplicate resources reviewed?
Are new resources governed?
Are changes monitored continuously?
Is governance reviewed regularly?
Who should own PI System governance?
PI System governance is usually a shared responsibility. Depending on the organization, it may involve PI administrators, automation engineers, OT teams, reliability engineers, process engineers, data engineers, IT teams, analytics teams, and business or asset owners.
The PI administrator should not be expected to make every governance decision. The people who understand the technical system, the physical process, and how the data is actually used all need to be involved.
The operating model can vary, but technical and operational ownership should be clear.
What does a mature PI System governance program look like?
Organizations do not need to solve everything at once. A practical maturity path is:
Inventory → Standardize → Trace → Monitor → Govern continuously
Start by understanding what exists. Identify important tags, AF resources, calculations, displays, interfaces, and downstream applications.
Next, apply standards for naming, modeling, metadata, and ownership. Once the environment is better understood, establish lineage so teams can see where important data comes from and where it is used.
Monitoring should follow. Data health and important configuration changes need to be visible as they happen.
The final step is to make governance part of normal PI operations. At that point, the organization is not relying on periodic cleanup projects to restore order.
Why PI System governance matters for AI
AI raises the cost of poor governance because AI applications can consume operational data at much larger scale.
An experienced engineer may look at a trend and recognize that a value does not make sense. An AI application may continue consuming the same value unless there is enough context, monitoring, and governance around the data.
AI also benefits from information beyond raw values, including asset context, equipment relationships, engineering units, lineage, data health, change history, and ownership.
A PI environment that is difficult for engineers to understand will also be difficult for AI systems to use correctly.
How Tycho Data supports PI System governance
Tycho Data helps industrial teams understand and govern operational data across the PI environment.
Osprey provides visibility into PI data health, lineage and dependencies, PI and AF relationships, configuration changes, audit history, and downstream usage.
This helps teams answer practical questions such as where a value came from, whether the underlying data is healthy, what changed, who changed it, and which resources or applications depend on it.
The purpose is to make governance easier to maintain as the PI environment grows and becomes more connected to analytics and AI.
Frequently asked questions
What is PI System governance?
PI System governance is the set of practices used to keep PI data, Asset Framework models, calculations, configuration, and downstream dependencies understandable, trustworthy, traceable, and controlled over time.
It covers both how the environment is structured and how it changes.
What is PI data governance?
PI data governance focuses on how operational data in the PI System is owned, described, structured, monitored, changed, and used.
It can include data standards, ownership, AF modeling, data quality, lineage, change management, and lifecycle management.
What is the difference between PI administration and PI governance?
PI administration focuses on operating and maintaining the PI infrastructure.
PI governance focuses on whether the data and configuration inside that environment remain understandable, trustworthy, traceable, and controlled as the system changes.
Who owns PI System governance?
PI System governance is usually shared across PI administrators, OT teams, automation engineers, process engineers, reliability teams, data teams, and business owners.
The exact operating model varies by company, but technical and operational ownership should both be clear.
How do you govern PI Asset Framework?
PI Asset Framework governance typically includes standards for asset hierarchies, AF Templates, Attributes, naming, descriptions, engineering units, ownership, and change management.
Organizations should also review duplicate, inconsistent, and obsolete AF structures over time.
Why is lineage important for PI System governance?
Lineage shows where PI data comes from and where it is used.
This helps teams understand dependencies, troubleshoot problems, assess the impact of changes, and reduce reliance on tribal knowledge.
How do you audit a PI System?
A PI System audit should review important configuration changes across PI Tags, AF resources, calculations, interfaces, and other components.
For significant changes, teams should know what changed, when it happened, who made the change, why it was made, and what downstream resources may be affected.
How does PI System governance support AI?
AI needs more than access to operational values. It benefits from context, traceability, trustworthy data, and an understanding of how the data changes over time.
Good PI System governance provides that foundation.
Do you need to govern every PI Tag?
No. Start with the PI data that supports critical operations, reporting, analytics, and AI.
Governance should be prioritized based on business impact and usage rather than trying to apply the same level of effort to every tag.
Is PI System governance a one-time project?
No. PI environments change continuously as new tags, calculations, interfaces, displays, asset models, and consumers are added.
Governance should therefore include continuous monitoring and regular review.