AI for Scheduling in Energy

The nomination for tomorrow has to be in before gate closure and the desk is short of one number. A generator told somebody by telephone that a unit will return later than planned, the confirming email has not arrived, and the person who took the call has gone home. Two floors down a planner is rebuilding next week, because a planned interruption has to move: the switching programme will not be approved in time, and the notices served on customers a fortnight ago must now be withdrawn and issued again against a new date.

Both of those jobs are called scheduling. They are not the same job.

Gate closure and the permit office

In most industries scheduling means a diary. In energy it covers two jobs with almost nothing in common.

The first is scheduling and nomination to the network: volumes declared to a system or transmission operator in a prescribed format, against a deadline fixed by code rather than preference, with imbalance consequences when the declaration and the physical position diverge. That is trading and operations running to a hard clock.

The second is work scheduling in the field: outage and maintenance windows, permits to work, switching schedules, planned interruptions, crews and access. That is where the administrative volume sits, governed by safety machinery rather than a calendar.

They share a word and a deadline culture. Around the first an agent can carry the paperwork and none of the judgement. In the second it can carry a great deal.

The declaration itself is a trading judgement

What to nominate is a position taken by licensed people who answer for it. An agent has no honest claim on that decision, and dressing a suggested volume up as a recommendation is how a guess acquires authority it has not earned. Its honest claim is the work wrapped around the decision: the inputs that feed it, the check against what was contracted, the proof the submission landed, and the reconciliation afterwards.

The hour before the deadline

The inputs arrive from different parties, in different formats, at different times, and some arrive by voice. Contracted volumes. Traded positions. Availability declarations from plant. Revision notices from shippers and counterparties. Forecast updates. Estimates standing in for reads that never came through.

An agent can gather that set in one place, timestamp and attribute each item, show what is outstanding against the clock, and flag where two sources disagree before anybody builds a number on top of them. Then it can check the draft submission against what was contracted or traded and name every line that does not tie, with the source of each side of the difference. None of that is the decision. It is the difference between a desk deciding with a complete input set and a desk deciding from memory at speed.

Proof that the submission landed

A file is submitted, and then it is accepted, rejected, or accepted in part with a code attached. Those acknowledgements get read when somebody remembers to look. An agent can watch for them, parse them, and raise the rejections and the ones that never came. The same applies outward: confirmations owed by counterparties and shippers, held as a list of who owes what and since when, chased on a schedule.

The most valuable output here is the dullest. A deadline that will be missed, flagged while it can still be met, because the input it waits on has not moved for hours.

What the meters said afterwards

Weeks later the metered and settlement data says what actually flowed. The gap between what was nominated and what was measured has to be explained line by line, and the usual failure is that nobody explains it until a settlement query forces the conversation.

This is good agent work, being high volume and entirely evidence based. Compare declared against metered against settled, per point and per period, and write a short explanation for each difference naming the records it rests on. Some will not resolve, and that residue is useful in itself: a short list of things worth a person's time.

Planned work is a paperwork exercise with a crew attached

A planned job on a network is not a slot with a crew against it. It is a bundle of documents and agreements that must exist, be approved and be in the right hands before anybody touches anything.

An outage window agreed with whoever controls the network. A switching programme written and approved. A permit to work issued and accepted on site. Isolation proved. Statutory notices served on affected customers. Road space and traffic management. Landowner access. Crews holding the right authorisations.

Each has a different owner, a different lead time and a different failure mode, and most live in systems the scheduling tool cannot see. The schedule is the last to learn that one has slipped.

Permit first, then the slot

Elsewhere a slot becomes real as soon as a person and an hour exist. Here it becomes real when the safety documentation does. Without the permit, the agreed isolation and the approved switching plan, the entry is a fiction with a crew booked against it.

Scheduling systems record the job, the duration and the resource. They rarely record whether the documentation behind it is on track, so a plan can look complete and be undeliverable, and the discovery happens on the morning. The honest build is assembly and absence: pull together the permit and switching pack for a planned window, list what is missing, and name who owns each item and how long it usually takes.

Competent, and still not allowed near the apparatus

Elsewhere the constraint on who can do a job is skill, with certification as a proxy. In energy it is authorisation. A competent engineer who does not hold the authorisation for that apparatus, that voltage or that class of operation cannot lawfully do the work, and availability changes nothing.

Authorisations are narrow: specific to apparatus and voltage, sometimes to named sites, and they expire, lapse after a long absence or are withdrawn. Contractor authorisations have to be verified rather than assumed. The record usually lives where the scheduling system cannot reach it, in a safety rules register, a training database, or a spreadsheet kept by one person.

So the useful build is reconciliation. Read that register against the jobs in the plan, name the ones that cannot lawfully proceed as staffed, and list the authorisations expiring inside the planning horizon.

A notice already posted has its own clock

A slipped window in a factory costs money. One on a distribution network carries an obligation, because notices have already been served.

Planned interruption notices run to statutory minimum periods. When the date moves they do not simply become wrong. They have to be withdrawn and reissued, the reissue carries its own minimum period, and that arithmetic can make a date only days later impossible to serve. Customers on a priority register may be owed longer notice or an alternative arrangement that itself needs booking.

An agent can produce and track the notice set, hold the withdrawal and reissue sequence when the date moves, and tell the planner the earliest date the notice regime permits, which is often not the date the crews are free.

Lead times owned by other organisations

Much of what gates a planned window is not yours. Landowners and wayleave notice periods. Road space permits and traffic management bookings with fixed dates and overrun charges. Isolation agreed with somebody else's control room. A connected generator or large site that has to accept being off supply.

Each is booked in a different place, with its own notice period, and each can quietly drift out of line with the crew date. Nobody notices until the week of the job. Chasing and reconciling that set suits an agent well: who was asked, when, what they said, what is outstanding, and which dependency now sits outside the window it was booked to support.

The dates that carry a consequence

Gate closure. A notice period. A permit validity. A road space booking with an overrun charge. An authorisation expiry. A dispute deadline on a settlement run.

These live in different systems, owned by different teams, and almost nobody holds them on one page. The two halves of the word meet here, because an outage window that moves changes what plant is available, and availability is declarable, so a field date that slips quietly makes a market declaration wrong. The useful output is modest: one view of every date that carries a consequence, ordered by what breaks and when, with the owner named and the evidence behind it. Most of the value comes from that view existing rather than from anything clever.

Where AI fails here

Nomination and dispatch decisions belong to licensed, accountable people, and must not be framed as recommendations, because a recommendation shifts the centre of gravity of a decision even when everyone insists it is advisory.

A permit to work is a legal safety instrument. Its issue and acceptance are named human acts by authorised people who answer for them. No agent should draft, issue, accept or appear to approve one, and the support described here stops at assembling and chasing.

Switching sequences are safety critical engineering. A plausible looking sequence is more dangerous than none at all, because it invites review rather than authorship.

Real time conditions move faster than any plan, and the control room overrides the plan by design. Anything built here treats the plan as a proposal reality may reject, not as a source of truth.

Authorisation records are frequently out of date at source. Reconciliation surfaces questions, not answers, and early runs mostly reveal that the register is wrong rather than the plan.

The statutory notice regime is a compliance obligation, and a confident wrong date creates the breach the notice exists to prevent. Notice arithmetic needs checking by someone accountable before anything is served.

Where to start

Pick one half and one narrow process. On the trading side, take a single nomination type, build the input assembly and the post event reconciliation, then test it against submissions already made and see whether its explanations match the ones your team eventually reached. On the field side, take one planned interruption programme and build the notice set with its withdrawal and reissue logic, or reconcile the authorisation register against the next quarter of planned work and see how much of the plan survives.

Both are measurable against history, which is the point. If a build cannot be tested against windows you have already run, being unable to tell whether it works is the same as it not working.

Adopt AI Partners works on back office processes of this kind, starting from a baseline on your own records rather than a demonstration. To talk through which half of your scheduling problem is the better first candidate, write to hello@adoptaipartners.com.