From issue to operational decision

An output interruption is reported. What should the team do next?

Follow Inverter 02 at Riverside Industrial Solar: identify the interruption, investigate the existing work, review a proposed response and see what still needs to happen before an outcome can be established.

Riverside is a fictional operating case shown in the actual product. The records stop short of an approved visit or verified repair. This walkthrough follows the decisions—not a claim that every stage has been completed.

01 · Issue recorded · Response needed

Identify the equipment and the question to investigate.

An output-interruption alert identifies Inverter 02, its site and medium severity. The team needs to distinguish an equipment problem from a gap in the readings. Gen318 puts the alert and response context together; the physical cause and operational impact remain unresolved.

Output interruption · Inverter 02 · Medium severity · Impact assessing · Active.
Output interruption · Inverter 02 · Medium severity · Impact assessing · Active. Inspect full-size detail →

Next owner: operations. Open the response context and check what has already been investigated before planning another visit.

Investigate the existing response
02 · Investigation · Existing work found

Use the existing work to make the next decision.

Ask connects two records for the inverter: an earlier inspection that is still open and a completed source-data review. The review found an undetermined cause and recommended continued monitoring. That gives operations a useful next step: inspect the open job’s scope before sending another team.

The displayed alert links to the completed source-data review; Amina Yusuf owns its response context.
The displayed alert links to the completed source-data review; Amina Yusuf owns its response context. Inspect full-size detail →
The saved Ask answer cites the completed review and the separate open inspection. Neither establishes the equipment cause.
The saved Ask answer cites the completed review and the separate open inspection. Neither establishes the equipment cause. Inspect full-size detail →

These are different event-linked jobs on the same asset, not successive states of one work order. The inspection was created on 7 September; the source-data review was completed on 8 September before this Ask handover. Ask makes that history inspectable through source citations.

Next owner: operations. Reconcile the existing inspection with the source-data finding and decide whether any additional work is needed.

Inspect the proposed response
03 · Action review · Proposal expired

Review the scope before authorising more work.

The proposal brings together source-reading checks, before-and-after evidence and the need to reconcile the open inspection. An authorised operator must assess that scope. This proposal expired without approval: it created no work order, assigned no technician and sent no equipment command.

Expired inspection proposal: scope, required skills, safety notes and approval boundaries remain visible.
Expired inspection proposal: scope, required skills, safety notes and approval boundaries remain visible. Inspect full-size detail →

The answer above and this proposal come from separate turns of the same investigation. The proposal’s accompanying final answer was withheld; the displayed handover is the earlier saved response.

Next owner: an authorised operator. Review the existing job first. If additional work is justified, prepare a fresh proposal for review; the expired draft cannot be approved.

See the work still outstandingInspect the retained Ask record →
04 · Field work · Inspection unassigned

Give the next visit a clear owner and scope.

“Investigate inverter output interruption” remains Created and unassigned. This is the existing inspection Ask found—not a job created by the expired proposal. Its scope asks for inspection and findings; no attendance or repair has been recorded.

Open inspection 7809fc95: Created, unassigned, with no confirmed fault or repair outcome.
Open inspection 7809fc95: Created, unassigned, with no confirmed fault or repair outcome. Inspect full-size detail →

Next owner: the operations coordinator. Confirm scope and assign a suitable technician. The technician workflow supports acknowledgement, check-in, findings and field evidence. Those steps remain to be carried out for this inspection.

Understand what would establish an outcome
05 · Outcome verification · Not established

Keep “work completed” distinct from “problem resolved.”

The completed source-data review shows why the distinction matters. Its technician record says “cause undetermined” and “monitoring only.” The supervisor reviewed that record and kept the equipment inspection open. This is prior context for the inspection—not its completion or a verified repair.

Completed source-data review 264987d7: undetermined cause, monitoring only.
Completed source-data review 264987d7: undetermined cause, monitoring only. Inspect full-size detail →
Required before-and-after photos are missing. No post-repair verification is recorded.
Required before-and-after photos are missing. No post-repair verification is recorded. Inspect full-size detail →
The supervisor reviewed the record; its evidence strength remains label only.
The supervisor reviewed the record; its evidence strength remains label only. Inspect full-size detail →

Next owners: the field team and supervisor. Record the inspection findings and required evidence, then assess whether the conditions for post-repair checks are met. A supervisor’s review records a human judgement; it does not fill missing evidence or certify a successful repair.

What is needed before verification can run?

Verification needs eligible records, sufficient received and trustworthy telemetry, an applicable signature or approved policy, the observation window and enabled processing. This case has no verification record, and no verification worker was running at capture. The required observation window must follow the applicable verification basis. Time alone will not establish an outcome.

Plan your setup

Match the workflow to your team and equipment.

These are implementation requirements to discuss for your deployment. The demonstration build does not establish production availability or a commercial entitlement.

Monitoring and field response

Start with a supported vendor account or mapped local signals. Confirm site assignments and operator or technician responsibilities. Viewing an issue and creating a work order do not themselves command equipment.

Ask and reviewed proposals

Ask needs its provider, feature and role access configured. Action proposals have additional controls. Equipment commands follow a separate enabled execution path with permission and safety checks. Ask and proposal drafting were enabled only in this isolated demonstration; no proposal was approved and equipment control remained off.

Client and portfolio outputs

Agree the site scope, reporting period, service definition and available records. Investor access is limited to portfolio memberships; finalisation requires an owner. Report access does not imply access to every operator screen.

Evidence and repair review

Evidence assessment, post-repair checks and supervisor review have their own setup and permissions. Confirm the authorised reviewers and required records. A human review is not independent certification.

Check your equipment →

Walk through the decisions your team needs to make.

Bring an operating question, your equipment mix and the people responsible for response. We will show how an issue, investigation, work order and outcome check fit together—and discuss the access and records your deployment would need.

Request an operations walkthrough →

Supporting outputs: client report · portfolio report · programme evidence preparation