Auto-resolution without losing the audit trail

A solar plant loses output on one string. Nobody is on site. The generation curve bends, a model recognises the shape, and a ticket exists with a severity, an owner and a first diagnosis before any person has looked at a screen. That part is ordinary engineering now. The hard part arrives three weeks later, when someone asks why the ticket was raised, why it went to that team, and who decided it was finished.

We built the auto-ticketing layer inside iConcept PowerTech's grid platform in Indonesia. Telemetry streams from plant hardware into a central system, models trained on historical generation data pick out pre-failure signatures, and critical issues are raised and routed without a human in the loop. Making that work took a few months. Making it defensible took longer, and it is the part worth writing about.

Three different things get called automation

Most disagreements about automated ticketing are really disagreements about which of three steps is being automated, and they are not equally risky.

1. 01Auto-raise: turn a signal into a ticket. Low risk. The worst case is noise, which is a tuning problem.
2. 02Auto-route: assign a team, a priority and an SLA clock. Medium risk. A wrong route costs time, and the cost is invisible until the deadline is missed.
3. 03Auto-resolve: close the ticket without a person confirming it. This is a claim that a condition on physical plant has cleared, made by software, recorded as fact.

Operators are generally comfortable with the first two long before they are comfortable with the third, and they are right to be. The argument is usually won by showing the record, not by improving the model.

What the record has to contain

The test we use is simple. An engineer who was not there, working a year later, with the model since retrained twice, should be able to reconstruct the decision exactly. That requires storing more than the outcome.

• The input window of telemetry that triggered it, stored as it was seen, not recomputed later from the warehouse
• The identity and version of the rule or model that fired, and the threshold in force at that moment rather than the threshold in force today
• The routing decision and the rule behind it, including the fallback if the primary owner was unavailable
• The action taken, whether any human confirmed it, and what they saw when they did
• Timestamps from one clock, with the plant's local time recorded separately for anyone reading it on site

One detail that seems small and is not: give the automation a named identity, and a different one per function. A ticket history that says the actor was System tells a reader nothing. A history that says the actor was the inverter-anomaly monitor, version 4, tells them which code to open. It also means that when a component is retired, its actions remain attributable to something that once existed rather than to a generic account still in daily use.

Closing a ticket is a claim

Absence of an alarm is not evidence that a fault cleared. It can equally mean the sensor stopped reporting. Auto-resolution therefore needs positive evidence, sustained for a defined period: output back within the expected band for the irradiance, telemetry still arriving, no correlated fault upstream. Where that evidence is not available, the ticket stays open and waits for a person. Plenty of tickets wait for a person. That is an acceptable outcome, and pretending otherwise is how automation loses its licence to operate.

The second rule is about repeats. If the same signature returns on the same asset inside a defined window, auto-resolution is suppressed and the ticket is escalated to a human with both histories attached. A fault that resolves itself four times in a fortnight is not four resolved faults. It is one unresolved fault and a reporting problem.

The trail is what buys the next increment

Every operations team we have worked with starts by wanting the automation narrowed. They agree to widen it once they have spent a few months reading the records and finding that the machine's decisions are boring and correct. The audit trail is what makes that period survivable. It is also the only thing that makes a bad automated decision recoverable, because the alternative is a closed ticket, a plant that is still down, and no way to establish which of those two facts came first.