How to Review the PI System Audit Trail Without Drowning in Noise
The PI System can record a large amount of audit information. That is useful when you need to understand who changed a PI Point, when a configuration changed, or whether work followed an approved change process. The problem is that large PI environments can generate so much audit activity that finding the few changes that matter becomes difficult.
Audit records can include activity from administrators, engineers, applications, service accounts, interfaces, and automated processes. A periodic review can quickly turn into thousands or millions of events, many of which have little value to the person doing the review. PI users have raised this issue in the AVEVA Community, including cases where automatic batch and system activity made several years of audit history impractical to review manually.
A useful PI System audit trail review needs to help teams separate expected activity from configuration changes that deserve investigation.
What is the PI System audit trail?
The PI System audit trail records activity and configuration changes that teams may need to investigate later. Depending on the PI component and how auditing is configured, this can include PI Point configuration changes, data edits, security or administrative activity, and Asset Framework changes.
Auditing is configurable, so the first step is understanding what your environment actually records. For PI Data Archive, auditing must be enabled before a historical change occurs if you expect to retrieve that change later. Some metadata may still tell you who most recently changed a resource or when it was modified, but that is different from having a full history of changes.
PI Audit Viewer has traditionally been used to search PI audit information. AVEVA also offers PI Audit Reporter to centralize audit trail data and support enterprise searching, review, and reporting. Regardless of the tool, teams still need a practical way to decide which events deserve attention.
Why PI audit trails become noisy
Audit volume grows quickly in an active PI environment because human users are only one source of activity. Applications, service accounts, interfaces, analyses, and other automated processes can also generate records.
That creates a difficult review process. A team may have a detailed audit trail and still struggle to answer basic questions: Which important configuration changed? Was the change expected? Who or what made it? Was it part of an approved change? Which operational systems depend on the resource that changed?
The result is often a manual workflow where someone filters records, exports data, compares events, and tries to separate routine system behavior from changes that deserve investigation. That can work in a small environment, but it becomes hard to sustain at enterprise scale.
What should you actually look for in a PI audit review?
Treating every audit event as equally important creates unnecessary work. Start with resources and configuration that can affect operations.
For PI Points, pay particular attention to changes that affect how data is collected, interpreted, or stored. Examples include:
Point source or source mapping changes
Compression settings
Exception settings
Engineering units
Zero and span
Scan or collection configuration
Tag renames
Important metadata changes
These changes are not necessarily problems. What matters is whether they were intentional and whether the people who depend on the data understand the impact.
Asset Framework should receive the same treatment. Changes to AF Attributes, templates, asset hierarchies, data references, or PI Analyses can alter what users see even when the underlying PI infrastructure continues to run normally.
Usage helps determine priority. A configuration change to an unused historical tag has a very different risk profile from a change to a tag that feeds several PI Vision displays, an important PI Analysis, and an AI application.
A practical PI audit review workflow
A useful audit review starts with scope rather than with the audit table itself.
1. Start with critical assets and data
Identify the parts of PI that matter most to operations. This may include critical process tags, important AF Attributes, production calculations, reliability data, control room displays, regulatory data, or information used by analytics and AI.
This narrows the review from "what changed anywhere in PI?" to "what changed to the resources we actually care about?"
2. Define which changes deserve review
Different change types carry different levels of risk. A description update may have little operational impact, while a change to a Point source, engineering range, calculation input, compression setting, or AF data reference may need immediate attention.
Define the change types your team wants to review and use those rules to focus the audit process.
3. Filter predictable system activity
Service accounts, interfaces, analyses, and applications can generate repeatable audit activity. If that activity is understood and controlled elsewhere, it can overwhelm a manual review.
The appropriate filtering approach depends on operational and regulatory requirements. The goal is to separate known system behavior from events that need a person to investigate without removing records the organization is required to retain.
4. Group related changes
One engineering task can create many individual audit events. Reviewing every field update as a separate incident makes the audit trail harder to interpret.
Group records that occur around the same time, affect the same resource, and come from the same user or process. Several individual entries may turn out to be one engineering change.
5. Compare before and after
An audit record becomes much more useful when the reviewer can see exactly what changed.
For important configuration, compare the previous and current values. Knowing that someone edited a PI Point is far less useful than seeing that CompDev changed from one value to another or that the Point source was modified.
That context helps the reviewer decide whether the change deserves attention.
6. Identify who or what made the change
The actor matters. Named user accounts make it easier to connect changes to engineering work, while shared accounts make investigations harder because the audit record may identify the account without identifying the person responsible.
Service accounts should also be easy to recognize so teams can distinguish automated activity from human configuration changes.
7. Determine what depends on the changed resource
This is where audit review often becomes difficult. The audit trail may tell you that a PI Tag changed, but that alone does not show whether the tag feeds an AF Attribute, a PI Analysis, a PI Vision display, a Power BI report, or an AI application.
That downstream context can completely change the importance of the event.
8. Document the reason for the change
Important changes should have a reason. Where possible, connect PI configuration changes with the change request, work order, project, incident, or other record that explains why the modification occurred.
That becomes valuable months later when someone asks why a tag, calculation, or AF configuration changed.
Why lineage makes audit review more useful
Audit history and lineage answer different parts of the same investigation. Audit history tells you what changed, while lineage shows where the affected data comes from and where it is used.
Consider this dependency:
PI Tag → AF Attribute → PI Analysis → PI Vision → analytics or AI
If the source mapping on the PI Tag changes, the PI Server may continue running, the analysis may continue executing, and the PI Vision display may continue showing values. Nothing has technically failed, but every downstream consumer may now be using different source data.
The audit record gives you the change event. Lineage helps show which applications and users may be affected. During troubleshooting, this allows teams to focus on recent changes upstream of the problem instead of searching the entire PI environment.
How often should PI audit logs be reviewed?
There is no single review schedule that works for every PI environment. Critical resources may need continuous monitoring or near-real-time notification when important configuration changes. Broader governance reviews may happen weekly, monthly, quarterly, or as part of an established change-management or compliance process.
Event-driven reviews are also useful. After a major outage, migration, control-system update, PI upgrade, or unexpected data-quality incident, reviewing recent configuration changes can narrow the investigation. The frequency should reflect the importance of the resource and the consequences of an unexplained change.
PI System audit review checklist
For important PI resources, a practical audit review should answer:
What resource changed?
What configuration changed?
What was the previous value?
What is the current value?
When did the change occur?
Who or what made the change?
Was the change expected?
Is there a documented reason for the change?
Is the resource operationally important?
Which AF Attributes depend on it?
Which PI Analyses depend on it?
Which PI Vision displays use it?
Which reports, analytics, or AI applications use it?
Did data behavior change around the same time?
Does someone need to investigate the change?
If answering those questions requires several people, multiple tools, and a long manual investigation, the organization has more than an audit logging problem. It has an audit review problem.
Audit trails are more useful when connected to data quality
Configuration changes and data-quality problems often need to be investigated together. Suppose a flow measurement starts behaving differently on Tuesday afternoon. A data-quality monitor may detect the change, but that does not explain why it happened.
If the audit history shows that an engineer changed the Point source or scaling earlier that afternoon, the team has a much stronger starting point. The same logic applies to compression changes, calculation inputs, AF data references, and other configuration that can affect how operational data behaves.
Connecting configuration history with data behavior helps teams move more quickly from detecting a problem to understanding its likely cause.
How Osprey approaches PI audit review
Osprey treats audit review as part of a broader PI System observability and governance workflow. It adds context around PI resources and configuration changes so teams can review changes alongside lineage, data health, and downstream dependencies.
This reduces the amount of manual searching required after an issue. PI administrators can see which resources changed and what may depend on them, while engineering and operations teams get more context about why the change matters.
The goal is to focus attention on meaningful changes rather than create another place to browse audit records.
Frequently asked questions
How do I view PI System audit logs?
PI Audit Viewer is a traditional AVEVA utility for searching PI audit information. The information available depends on which PI components are being audited and how auditing is configured. AVEVA also offers PI Audit Reporter for centralized audit trail review and reporting across PI environments.
What should I look for in a PI audit trail?
Start with changes to operationally important resources. Review modifications to source configuration, compression and exception settings, engineering units, ranges, AF Attributes, templates, calculations, and other configuration that can change the behavior or meaning of data.
Then determine whether the change was expected and which downstream applications depend on the affected resource.
How long should PI audit history be retained?
There is no universal retention period for every PI environment. Retention should follow the organization's operational, regulatory, validation, legal, and change-management requirements.
The retention policy should be defined intentionally rather than allowing technical cleanup settings or defaults to determine how long audit information remains available.
How do I find who changed a PI Tag?
If appropriate auditing was enabled before the change, the audit history can help identify the user or process associated with the modification. PI Points may also expose information about the most recent changer and change date, although that does not replace complete historical audit data.
Named accounts make this information much more useful than shared identities during an investigation.
How do I reduce noise in PI audit logs?
Start by identifying the types of events that matter to the review and separate them from predictable automated activity. Service accounts and other automated processes can generate large volumes of records that make manual review difficult.
Any filtering approach should still follow the organization's audit and compliance requirements. The goal is to make review practical while retaining the records that need to be preserved.
Can PI audit logs show downstream impact?
Audit logs identify changes, but understanding downstream impact usually requires dependency or lineage information.
If a PI Point changes, lineage can show whether that Point feeds AF Attributes, calculations, displays, reports, analytics, or AI applications. Combining audit history with lineage makes it easier to decide which changes deserve immediate attention.
Review PI changes with their downstream context
The value of an audit trail comes from understanding which changes matter, why they happened, and what they can affect. Osprey connects PI configuration changes with lineage, data health, and downstream usage so teams can investigate important changes without manually reconstructing the dependency chain.