> ## Documentation Index > Fetch the complete documentation index at: https://docs.sensorup.com/llms.txt > Use this file to discover all available pages before exploring further. # Audit History > Complete audit trails for emission observations and events with full transparency and compliance tracking Audit History Banner ## What is Audit History? Audit History provides a complete, chronological record of every change made to your emission observations and events throughout their entire lifecycle. This powerful feature enables full data integrity, compliance reporting, and transparent tracking of all modifications—whether made by your team or automated systems. Every field change tracked Full audit trail for reporting Know who changed what and when ## Understanding the Two History Tabs The audit history feature tracks changes to two distinct types of records, each serving a different purpose in your emissions management workflow: **The Data Integration Log** Tracks changes to raw detection data, typically from third-party systems (like Continuous Monitoring Systems). This is mostly read-only and system-driven. **Key Question:** "Where did this data come from, and has the source changed it?" **The User Action Log** Tracks all actions your team takes on emission events—attribution changes, status updates, closures, and investigation activities. **Key Question:** "What has our team done with this event?" ### Visual Examples The audit history interface provides different views to help you focus on the information you need: **All Events History** View the complete audit trail combining both observation and emission event changes in a unified timeline. Audit history showing all events **Emission Event Only History** Filter to see only the changes made to the emission event itself—perfect for tracking team actions and decisions. Audit history for emission events only **Observation Only History** Filter to see only the changes made to underlying observations—ideal for verifying data source updates. Audit history for observations only ## Why Use Audit History? **Without audit history:** Can't verify data changes for compliance audits Can't track who made attribution or status changes Lost context when investigating events Manual timeline reconstruction is time-consuming **With Audit History:** Automatic, unchangeable audit trail Complete visibility into who changed what and when Regulatory-ready compliance documentation Instant access to complete event lifecycle ## Common Use Cases **Compliance Reporting** Track all modifications to emission data for regulatory reporting. View the complete history of any observation or event to demonstrate data integrity and proper handling procedures to auditors, with automatic documentation of every change made by your team or integrated systems. **Event Investigation** Understand how an emission event evolved from detection to resolution. See which team members attributed the event, requested inspections, and ultimately closed it out, providing full context for every decision and action taken throughout the event lifecycle. **Data Source Verification** Identify patterns in how continuous monitoring systems refine their data over time. Analyze how emission rates or attributions change as more information becomes available, helping you understand data quality and system behavior. **Attribution Tracking** When event attribution changes, review the complete history to see who made the change, when it occurred, and what the previous attribution was. This helps you understand the investigation process and verify that attribution decisions were made correctly. **Work Order Prevention** Before dispatching field teams, check the audit history to see if an inspection has already been requested or if work orders have been created. This prevents duplicate work and helps you coordinate field operations more efficiently. ## Getting Started **Ready to use Audit History?** The feature is automatically enabled for all emission observations and events. Follow these steps to access the complete history. Open any emission event or observation detail page from your emissions dashboard. Look for the **"History"** tab in the detail view. This tab appears alongside other information tabs. The history displays in chronological order (newest first) showing: * **What changed**: Field name and values (before/after) * **When**: Exact timestamp of the change * **Who**: User who made the change (or "System" for automated updates) * **Change type**: Creation, update, status change, attribution, etc. ## Understanding Observation History Observations are raw detection data, typically sent from third-party systems like Continuous Monitoring Systems (CMS) or occasionally created manually. ### What You'll See Most observations are **not editable** by users. Their history shows changes made by the **"System"** as external data sources (like CMS platforms) refine their data. You may see updates every 15-30 minutes for active monitoring systems as they: * Refine emission rate calculations * Update detection confidence levels * Adjust attribution as more data becomes available * Add additional metadata from processing pipelines The system tracks changes to all observation fields including: * **Emission Rate**: Value and unit (kg/hr, etc.) * **Detection Time**: Start and end times * **Attribution**: Asset and equipment references * **Status**: Detection status changes * **Additional Data**: Confidence intervals, processing metadata * **Media**: Links to images or videos Observations integrated from external systems are typically read-only to protect data integrity. The history log helps you understand: * Why an observation appears "locked" * That the data source controls the record * How the source system has refined the data over time ### Key Use Cases for Observation History **When:** Auditing a compliance report **Goal:** Verify the source of detection data and prove its integrity **Action:** Review the complete, unchangeable audit trail showing system-generated updates **When:** CMS data looks different today **Goal:** Understand what changed and when the system updated it **Action:** Find the specific field changes (e.g., emission rate) and their timestamps **When:** Questioning data integration **Goal:** Validate that the integration is working correctly **Action:** Confirm the observation was created by "system" and review original data **When:** Monitoring active CMS detections **Goal:** See if emission rates or attribution are still being updated or have stabilized **Action:** Check recent history entries for continued system updates ## Understanding Emission Event History Emission events summarize one or more observations into a single, actionable incident that your team manages, investigates, and resolves. ### What You'll See The event history is highly detailed. A single user action (like "Close Event") may result in multiple fields changing at once: * `status` → "CLOSED" * `closedBy` → User ID * `closureDate` → Timestamp * `statusReasons` → Closure justification The history log shows **one row for every single field** that changes, giving you a granular and complete record. All team actions are logged including: * **Attribution changes**: Moving events between assets or equipment * **Status updates**: Opening, closing, false alarming events * **Observation grouping**: Adding or removing observations * **Follow-up requests**: Requesting OGI inspections or repairs * **Field updates**: Changing dates, rates, or other properties * **Notes and documentation**: Adding investigation details Track the full journey from detection to resolution: 1. **Creation**: When the event was first detected (usually by system) 2. **Investigation**: Attribution refinements, observation additions 3. **Action**: Work orders, inspection requests 4. **Resolution**: Closure, false alarm designation, or ongoing monitoring ### Key Use Cases for Emission Event History **When:** Reviewing an active emission **Goal:** Get a complete picture of how the event has been handled **Action:** View the log of every action from creation to present **When:** Event attribution has changed **Goal:** Understand who changed it and when (e.g., from 'Facility A' to 'Pipeline B') **Action:** Find the attribution change in history with user and timestamp **When:** Auditing a closed event **Goal:** Verify closure timestamp and user for compliance **Action:** Review the status change entry showing who marked it closed and when **When:** Need to dispatch a field team **Goal:** See if an inspection has already been requested **Action:** Check history for work item creation to avoid duplicate work ## FAQ / Troubleshooting The "System" user appears when changes are made automatically by integrated data sources (like Continuous Monitoring Systems) or internal automated processes. This ensures you can distinguish between human actions and automated system updates. Observations from integrated sources are typically read-only to preserve data integrity. The history shows you changes made by the source system. If you need to modify data, you'll typically work with the emission event rather than the underlying observation. When you perform an action like "Close Event," multiple fields may change simultaneously (status, closed\_by, closure\_date). The history displays one row per field change for complete granularity. This helps auditors see exactly what data changed. Yes, you can export the complete audit history for compliance reporting. Contact your system administrator for export options, or use the GraphQL API to programmatically retrieve audit data. The audit history captures all changes from the moment the feature was enabled in your environment. For observations and events created before the feature launch, history tracking begins from that enablement date forward. The audit history is stored in an immutable event store, meaning changes cannot be deleted or modified after they're recorded. This provides legally defensible proof of data integrity for regulatory audits. ## Best Practices **Review history regularly** during investigations to understand the full context of an emission event **Use history for training** to help new team members understand proper workflows and procedures **Reference specific history entries** when communicating with regulators or auditors **Check observation history** before questioning data quality—the source may have refined it **Don't assume one history row = one action**—single actions may change multiple fields **Don't try to edit history**—it's intentionally immutable for compliance **Don't ignore system updates**—they provide valuable insight into data refinement **Don't skip history review**—it contains critical context for decision-making ## Related Features Learn how to manage emission events from detection to resolution Understand how to attribute emissions to specific assets and equipment Learn about different emission event statuses and lifecycle stages Create and track inspection requests and work orders *** ## Feedback & Support **Found a bug or issue with Audit History?** Contact your system administrator or SensorUp support team for assistance. **Have questions or suggestions?** Share your feedback to help us improve the audit history feature.