An agent that identifies a likely charging fault has answered one question. A charging operator still has to decide whether the proposed action is permitted, whether it can interrupt a session, and how recovery will be confirmed. Those decisions determine the product's operating boundary.
This article draws on Mohammed Cherifi's Auralink SDC preprint. The paper describes an edge architecture combining confidence-based escalation, retrieval, an inference runtime and coordinated agents. Its evaluation took place in a controlled environment. The evidence discussed here is research; field acceptance would require evidence for the particular product, equipment and operating context.
Separate diagnosis, permission and recovery
A useful fault-handling product needs three distinct answers:
| Decision | Evidence to examine | Acceptance question |
|---|---|---|
| What is likely wrong? | Telemetry, fault history, documentation and the uncertainty of the diagnosis | Is the diagnosis sufficiently supported for this type of incident? |
| What may happen next? | Operator policy, equipment restrictions, session state and an approved action catalogue | Is this specific action permitted on this specific asset now? |
| Did the action help? | Observable postconditions, service state and subsequent fault behaviour | Has the service recovered, or must the incident remain open? |
A confidence score belongs in the first row. It cannot grant permission in the second or establish success in the third. Keep these checks separate when defining the product and its interfaces.
Use the architecture to expose ownership gaps
The research architecture is useful as a way to ask concrete integration questions. Who owns the telemetry contract when firmware changes? Which documentation version supports a diagnosis? What happens when connectivity is lost? Which operator can interrupt an action? Who reconciles a local agent's view with the fleet incident record?
The Open Charge Alliance describes OCPP as the communication protocol between charging stations and charging management systems. Protocol support and successful service restoration are separate things to verify.
Record an owner and an observable result for each interface. Otherwise, a technically convincing demonstration can leave the operating team without a clear way to explain or stop the system.
The same discipline applies to escalation. An escalation should include the observations, the proposed action, the relevant uncertainty and any actions already attempted. An operator needs enough context to make the next decision without assuming the model's explanation is correct.
Define the evaluation before choosing a release date
Start with a narrow incident family and a bounded operating environment. Specify the equipment and firmware covered, the input conditions, the actions that remain prohibited and the people responsible for exceptions.
Evaluate the system on the whole workflow:
- Diagnostic correctness, including cases where the right answer is uncertainty.
- Whether prohibited or inappropriate actions are refused.
- Whether connectivity loss or incomplete telemetry leads to the agreed behaviour.
- Whether an attempted remediation achieves the defined postcondition.
- Whether the operator can investigate, interrupt and recover from a failed attempt.
Distinguish model response time, complete diagnostic time, action time and verified recovery time. Time to first token measures only the start of generated output; it does not measure service restoration. Report test conditions and unsuccessful cases alongside successful ones.
Build an economic case from observed work
A laboratory resolution percentage cannot establish avoided technician visits or realised savings. A field business case needs the actual incident mix, the work that would otherwise occur, the cost of mistaken actions, operator review effort and the cost of maintaining the system.
For each eligible incident category, record the current handling process and compare it with the proposed process. Count a dispatch as avoided only when the evidence supports that counterfactual. Keep projected benefits separate from measured operational outcomes.
The next commitment
Before expanding autonomy, write a short decision record: the incident family, the permitted actions, the accountable operator, the evidence still missing and the condition that would stop the evaluation. That makes the next investment reviewable.
If an EV-charging product faces an unresolved architecture, operating-boundary or launch decision, a Product Decision Review can examine that decision and its evidence. The research remains a reference for questions to investigate; deployment acceptance belongs to the specific product and operating context.
