Activity & Audit Trail

Mirox keeps a complete, chronological record of every meaningful thing that happens on your account — a change you make, a change a colleague makes, an event an on-site agent reports, an action taken by an AI assistant, or an automatic process running in the background. This record is called the Activity & Audit Trail.

Wherever something is created, changed, deleted, started, stopped, succeeds or fails, Mirox writes an event. Each event answers the same four questions, every time:

What happened (e.g. a park's grid feed-in limit was changed, an inverter went offline, a member was invited)?
Who or what caused it?
When did it happen?
How was it triggered — a person in the web app, an AI assistant, an on-site agent, or an automatic system process?

Unlike the Access Audit Logging page — which tracks remote network access to your plant devices (VPN and Proxy) — the Activity & Audit Trail tracks changes and events across the whole platform. The two complement each other: one answers "who reached which device", the other answers "who changed what, and what happened".

The Four Activity Streams

Every event belongs to exactly one of four streams, depending on what it concerns. This keeps each audience focused on the activity that is relevant to them.

Stream	Covers	Typical examples	Who can see it
Park	Everything that happens on or about a specific plant	Core-data edited, component discovered or lost, logger/network/VPN changes, production shutdowns, sensor faults, reports, files	Everyone with access to that plant
Organization	Changes to the organization itself	Members invited or removed, roles and permissions changed, portfolios, cooperations, accounting, organization settings	Organization moderators and above
Personal	Activity tied to your own account	Profile changes, security-relevant actions, sessions, personal tokens	You (and platform administrators)
Platform	Platform-level operations that are not tied to a single park or organization	Background infrastructure operations	Platform administrators only

You always see the streams that apply to you, and only the entries within them that you are permitted to see.

What Triggered It

Every event records how it was triggered, so you can always tell a human action apart from an automated one — and a change you made yourself from one made on your behalf. This is one of the most important columns for accountability.

Trigger	Meaning
User	A person acting directly in the Mirox web application.
AI assistant	An action carried out through an AI assistant / automation connected with an API token. Actions an assistant runs on your behalf are marked distinctly from your own clicks.
Agent	Reported by an on-site agent (the software running at the plant) — for example a component that appeared or disappeared, or a production change detected in the field.
Administrator	An action taken by a Mirox platform administrator on your park or organization. These remain visible to you — administrators cannot act on your data invisibly.
System	An automatic, internal process such as a scheduled job or background worker.

Priority

Not every event carries the same weight. Each one is assigned a priority so the important entries stand out:

Very low — cosmetic or informational.
Low — a change with no operational effect.
Normal — routine security- or access-relevant changes.
High — noteworthy operational events (e.g. an agent restart).
Very high — disturbances to data collection or connectivity.
Critical — irreversible or severe events (e.g. a deletion, or a major outage).

The activity timeline and table highlight higher-priority events, and you can filter to a minimum priority ("this level and above") to concentrate on what matters.

Outcome: Succeeded, Active or Failed

Many actions depend on an external system — a payment provider, an accounting service, a device at the plant. For these, Mirox audits the attempt, and the outcome is recorded on the event itself:

Active — an ongoing situation that has started but not yet resolved (for example an open production shutdown). Active events are highlighted so you can see at a glance what is still open.
Closed — completed successfully, or resolved.
Failed — the action did not succeed. Failed events are clearly marked, carry a short reason, and are raised to at least High priority so they are never lost in the noise.

This means a failed export or a rejected mandate is just as visible and traceable as a successful one — you are never left guessing whether something worked.

What Each Event Records

Open any event to see its full detail. Depending on the event, this includes:

The type of change and a human-readable title
Its category, trigger, priority and outcome
Timestamps — created, started, ended, closed, last updated
Who created it (and, for closed events, who closed it) — including name and account
What changed — for edits, a field-by-field comparison of the old and new values
The referenced object (e.g. the park, or the specific component) with a link to jump straight to it
For plant events: linked components, the people notified, and a seen-by list
Any support tickets raised from the event

All timestamps are shown in your browser's local time zone.

Where to Find Your Activity

The same underlying record surfaces in several places, each scoped to its context:

Activity page — a platform-wide view of events across all the plants you can access. This is the main entry point, reached from the navigation.
Park → Activity tab (on a plant's Core Data page) — the activity for that one plant.
Organization → Activity tab — the organization stream (moderators and above).
Profile → Activity tab — your personal activity.

Working With the Activity View

The activity view combines a visual timeline with a detailed table:

Timeline / calendar — a heat-map of activity over time. Day and month views group by category; the yearly view is a contribution-style calendar. You can freely pan and zoom, and the date picker follows along.
Table — one row per event, with the created time, type, category, trigger, priority, outcome, the referenced object, and how many people have already seen it.
Filtering — narrow by plant, portfolio, category, trigger and minimum priority. Filters are kept in the page address, so a filtered view survives a refresh and can be shared. The timeline reflects the same filters.
Details on demand — the table stays light and fast; the full payload of an event is loaded only when you open it, either inline or in a side panel.
Turn an event into a ticket — from any event you can create a support ticket, pre-filled from the event and linked back to it.

The "Seen by" Indicator

Plant events keep track of who has already looked at them. When you open an event's details, you are recorded as having seen it, and the table shows a running count. This helps a team know at a glance whether an important event has already been acknowledged by a colleague.

Platform administrators are a deliberate exception: they can review any event without leaving a trace — an administrator opening your event never appears in your seen-by list and never changes the count.

Who Can See What

Visibility follows the same permission system as the rest of Mirox:

Park events are visible to anyone with access to that plant (through ownership, a job assignment or a cooperation).
Organization events require a moderator role or higher.
Personal events are yours alone (plus platform administrators).
Platform events are restricted to platform administrators.

You only ever see events for plants and organizations you are already entitled to — the audit trail never widens your access.

Integrity & Retention

The Activity & Audit Trail is built to be trustworthy long after the fact:

No editing or deleting. Events are written by the system and cannot be altered or removed through normal use. There is no "edit" or "delete" path for an audit entry.
Write-once identity. Key identity details (such as the account and name of who acted, and the park or organization name) are stamped onto the event when it is created. Even if a user, plant or organization is later renamed or deleted, the event still shows who and what it referred to at the time.
Live names with fallback. While the referenced people and plants still exist, the view shows their current names; once they are gone, it falls back to the stamped snapshot — so the history stays readable months or years later.

Together with the Access Audit Logging, this gives operators of critical infrastructure the accountable, tamper-evident record that regulations such as the German KRITIS rules and the EU NIS2 directive require.

Access Audit Logging — tracks remote VPN and Proxy access to your plant devices
Permission System — decides who can see which activity stream
Authentication — how sign-in and account security work
Cooperations — how shared access is granted, and audited
Cooperation Restrictions — the limits that keep shared access within scope