When AI reads the manual and builds the PM plan

“AI builds your maintenance plan” is the kind of sentence that should make an operations manager check their wallet is still there. So here is the mechanism, step by step, including the parts where it says no.

Step one: the manual becomes structured maintenance data

Take a string inverter’s service manual. Somewhere past the safety warnings there is a maintenance chapter. It says, in prose and tables, that the enclosure is inspected annually, the fan filters are cleaned at an interval that depends on the environment, the DC terminal torque is checked at a stated interval, and the unit is de-energised and locked out before any of it. The chapter also has a troubleshooting table: fault code, likely cause, action.

The extraction pulls each maintenance item out as a row: task, interval, basis (calendar or operating hours), the evidence a competent person would expect (a photo of the filter, a torque reading, a signature), and a safety flag where the manual requires isolation. Each row keeps a pointer to the page it came from. A plan whose interval cannot be traced to a document is a plan someone will argue about later.

Step two: manuals meet the register

The extracted rows are matched to asset classes in the register: this manual applies to these forty-two inverters, those two models of tracker controller, this generator. Where a site’s own regime library already says something (the annual thermography the O&M contract requires, the load-bank test the standard requires), the library entry is cited alongside the manual. Where the two disagree, the disagreement is surfaced rather than resolved silently.

Then the draft is produced. Per asset class, per plan: task, interval, checklist, required evidence, source citations. On an existing installation it is produced as a diff against the current plans: what would be added, which intervals would change, which assets currently have no plan at all.

Step three: the parts where it refuses

This is where the mechanism earns or loses trust, so it is worth being specific.

If the manual is silent on an interval, no interval is invented. The asset appears in a coverage report as “no regime found, needs manual definition”. A programme that covers 90 per cent of the register and says so is more useful than one that covers all of it and is guessing about a tenth.

If a regime is flagged statutory, the flag travels with it into the checklist, and any later proposal to lengthen the interval is advisory only and marked as such. The data may say the generator has passed thirty-six consecutive tests. The standard still sets the floor.

If two documents conflict (a translated manual and its original, two firmware revisions, an OEM interval and a warranty condition), the conflict becomes a question for the reviewer, with both sources shown.

Nothing enters the live schedule until a person approves it. Approval creates the real maintenance plans. Before that, the draft is inert.

Step four: the review

The planner sees the draft as something to disagree with. Per plan, they can accept, edit the interval or the checklist inline, or reject. Per asset class, they can approve in bulk once they have sampled enough to trust the pattern. Every edit is recorded, because the corrections are the most valuable data the process produces: they are the places where the site knows something the manual does not.

What this is not

It is not prediction. Nothing here forecasts a failure. It is retrieval over documents and arithmetic over the site’s own records. That is a smaller claim than “predictive maintenance”, and it has the advantage of not requiring years of labelled failure data that neither we nor most operators have.

It is not autonomous. Anything with a permit, an isolation step, a pressure system, or a statutory signature is signed by a named person. The software drafts and proposes. It does not sign.

Go-live is not the end of it either. Once the programme is running, corrective work orders start arriving, and each one is evidence. Fan failures between quarterly services on three sites are a reason to propose two-monthly, with the seven work orders attached. Six months after an approved change, a verification card reports whether it worked: failures on the affected class, PM labour delta, net cost, or “cannot attribute” when the outcome is confounded. Over time that produces a published record of how often the software’s proposals were accepted, corrected, or rejected. We think that record is a better thing to show a buyer than a promise.

Status

This is Facterra’s roadmap, specified to the acceptance criteria above, and we are building it now on an asset model that has been in production since 2017. The regime libraries for solar, storage and critical facilities plant are being built first because they are also the grounding corpus. If you have a register and a folder of manuals and want to see what a draft looks like on your own assets, that is a conversation we would like to have.