AI in Plant Engineering: Breakdown Logs and Maintenance Plans

A small plant team can export six months of breakdown records, ask an AI assistant to give each entry a fault code, rank assets and components by how often and how long they fail, and draft a preventive maintenance schedule for the top repeat faults. An engineer then checks every interval and signs off anything safety-related before it reaches the work-order system.

The order matters. Most plants try to jump to the schedule, and the AI obliges with a tidy plan built on nothing. Do the fault coding first, count the repeats second, and only then write tasks. The three-person team in the worked example below ends up with six tasks instead of sixty, which is the point.

Follow me on Instagram@sagnikteaches

Start from the log you have, not the log you wish you had

Breakdown records live in three places: a CMMS (computerised maintenance management system), a spreadsheet, or a notebook by the control panel. All three can feed this. What you need for each event, in any format:

Connect on LinkedInSagnik Bhattacharya

• Date and time reported, and time back in production, or minutes lost.
• Asset name or number (the same asset spelled the same way each time is a bonus, not a requirement).
• The technician's note: what was wrong and what was done.
• Parts used, if recorded.
• Who attended, so you can ask the right person later.

If the notebook is the only record, photograph the pages and ask an AI assistant with image reading to transcribe them into a table. Check ten rows against the page; handwriting on a night-shift entry is where errors hide. Keep a column for "original text" that you never edit, and add the cleaned columns beside it. When a fault code is queried later, the first thing you will want is what the technician actually wrote.

Subscribe on YouTube@sagnikteaches

Take six months if you have them. Shorter than three months mixes seasonal effects with real patterns; longer than a year pulls in machines that have since been replaced.

Worked example: a three-person team and 148 work orders

This is an illustration with invented figures. Say a small plastics moulding plant has two injection presses, a chiller, a compressor, a granule conveyor and a packing line. The maintenance team is two fitters and an electrician, led by a maintenance engineer who spends half her week on other jobs. Over six months the log has 148 breakdown entries with notes such as "Press 2 leaking again, tightened", "conv jammed", "compressor tripped", and "chiller high temp alarm reset".

The engineer exports the table, removes technician names, and uses this first prompt.

Below is a six-month breakdown log from a small plastics moulding plant (148 rows: date, asset, note, minutes_lost, parts).

Step 1. For each row, propose a fault code in the form COMPONENT / FAULT, for example "Hydraulic hose / leak" or "Conveyor belt / mistracking". Use a short consistent vocabulary: reuse a code when two rows describe the same thing.
Step 2. Give a confidence (high, medium, low) for each code and quote the words from the note that made you choose it.
Step 3. Output a table: row number, asset, original note, fault code, confidence.
Step 4. After the table, list the codes you used with a count for each.
Do not invent details that are not in the note. If a note says only "reset" or "checked", mark it "Unclear" and low confidence.

The AI returns the table. A realistic slice (illustrative):

Of 148 rows, 112 are high or medium confidence and 36 low. The engineer and the two fitters spend 20 minutes in the canteen going through the 36, because only they know that "reset" on the compressor at night usually meant the intake filter. They fix 31 and leave 5 as unknown. That session is worth more than the AI step, because it also becomes the list of codes technicians will use from now on.

Count repeats three ways

A repeat fault is the same component failing the same way more than once. Ask for three views, each answering a different question.

Using the coded table, give me:
A. Count and total minutes lost by fault code, highest total minutes first (top 10).
B. For each of the top 5 codes, the assets involved and the dates, so I can see the gaps between repeats.
C. Any asset with 4 or more entries in the six months, whether or not the fault code repeats.
Then flag any code where the interval between repeats is getting shorter.

The illustrative result:

Two things leap out. Ranked by event count, the conveyor blockage looks worst (14), but ranked by minutes lost the chiller is the biggest single cost at 910 minutes from only seven events. And the hose leaks on Press 2 have gone from every six weeks to every three, which is the "interval getting shorter" flag. A plan built from the events table alone would have chased the conveyor.

Put a price on the minutes. If the engineer knows that an hour of press time earns roughly $850 in contribution (a figure from finance or from your OEE sheet), then the chiller's 15.2 hours is about $12,900 across six months, and the hose leaks' 11.5 hours about $9,800. Those two items justify a plan. The packing sensor, at 3 hours, does not.

Find the cause behind the code before you write a task

A preventive task only works if it addresses why the thing fails. For each top code, give the AI the raw notes and ask for hypotheses, not answers:

Here are the 8 Press 2 hose leak notes with dates and parts used. List up to four plausible causes, for each the evidence in the notes that supports it and the evidence that is missing, and the quickest check a fitter could do on the next occurrence. Do not recommend replacement intervals.

Illustrative reply: (1) a hose routed against a moving frame, supported by "weeping at fitting" on hose 3 four times, check for chafe marks on the next change; (2) fittings undertightened after hose changes, supported by "tightened" in five notes, check torque records; (3) hose age, evidence missing because the notes never record the hose date code; (4) pressure spikes, evidence missing. The fitter looks at hose 3 on the next stop and finds it rubbing on a bracket. The fix is a clip and sleeve, which costs $6 and deals with the four hose 3 events, half the Press 2 total. A technique like five whys prompts for recurring problems works well from this point.

The AI cannot see the machine. It can list what a mechanically minded person might look for, which is useful when the team is stuck, but the finding belongs to the fitter who held the hose.

Draft the schedule: one task per cause, with a reason attached

Only now do you ask for preventive maintenance tasks. Give it the confirmed causes, the asset manuals if you have them as text or PDF, and a limit on what the team can do.

Draft a preventive maintenance schedule for these four items for a team of three with about 12 hours a week for planned work. For each task give: asset, task in one line, who (fitter or electrician), time in minutes, trigger (calendar or running hours), the reason it addresses a logged fault, the source (manual page or "team experience, to confirm"), and a safety flag Yes or No.
Rules: use the manufacturer's manual intervals where I have attached them; where there is no source, say "interval to be set by engineer" instead of inventing one. Total planned time must stay under 12 hours a week.

A realistic first draft contains something like this (illustrative):

Total planned time: roughly half an hour a week averaged out (5 minutes for the four-weekly hose check, about 8 for the six-weekly coil clean, 15 for the compressor filter, and a few minutes of torque checks after hose changes). That is far under the 12-hour cap, so there is room for the conveyor task once its cause is known. Check the AI's own total line every time: drafts often add task times without dividing by the interval. The two safety rows say "Contractor" and "Competent person" with no interval, which is exactly right. If the draft had printed "every 12 months" there, you would delete it.

What the engineer signs off and what the AI never decides

Split the plan into two lists before anything goes into the work-order system:

1. Routine tasks (inspect, clean, lubricate, torque) that carry no safety flag. The maintenance lead can approve these, review them after three months, and adjust the interval from the log.
2. Safety-related items: pressure systems, lifting equipment, guarding and interlocks, electrical testing, fire detection, anything with stored energy, anything where a missed task could hurt someone. A named, competent engineer decides the interval, writes the method, and signs. If your plant has a written scheme of examination or a statutory inspection regime, that document overrides anything the AI drafted.

A good test: ask whether the task, if done wrongly or skipped, could injure someone. If yes, it is in list two. In the example, the refrigerant circuit and pressure vessel rows are there. Add the engineer's initials and a date in the plan file so the sign-off exists as a record; the AI's draft is not a record of approval.

When the AI proposes something the logs cannot support

Three failures show up most often in drafts:

• A confident interval with no source. "Replace hydraulic hoses every 2,000 running hours" sounds plausible and may be right for one manufacturer and wrong for yours. Reject any interval whose "source" is blank; use a manual, or run for three months and set it from observed failure gaps.
• Merging different faults. Two "compressor trips" with different causes (a blocked filter, a failed contactor) merge under one code and get one task. Ask the AI to list the original notes under each code and read them.
• Counting after-the-fact. Breakdowns that were never logged do not exist in the data. If the night shift fixes small stops without entering them, the plan under-weights that machine. Ask the team which asset "always stops" but has few entries.

A short story from the example: the first draft proposed a weekly "full inspection" of the packing line, 40 minutes a week for a line that cost the plant 180 minutes in six months. The engineer deleted it. A plan that fills every hour has not been prioritised.

Test the plan against the next ninety days

Treat the plan as a trial. Enter the tasks in the CMMS or a shared sheet with a due date, and add one column for "found something" so the technician records what they saw, even if it was nothing. At 90 days, export the log again and ask for the same three counts. The illustrative targets for the example: hose leaks on Press 2 down from 8 to 2 or fewer in a quarter, chiller trips down from 7 to 3 or fewer, and no new top-five code. If a task never finds anything for three cycles, stretch its interval by half; if it finds something every time, shorten it. This is also how you earn trust in the plan with the people doing the work, who will have views on it.

Connect this to reading downtime logs for repeat stops if your line stoppages are logged by a different system, and to building the schedule from manuals when the manuals are your main source. This tutorial sits between them: it is for plants where the evidence is the breakdown history, not the paperwork.

Before and after: rewriting a note so it can be counted

Most of the 36 low-confidence rows failed for the same reason, which is that the note recorded the action and not the finding. A short rewrite exercise is the cheapest way to make next year's log twice as useful. Ask the AI to rewrite five of your worst notes in a standard shape, then show the technicians the result.

Rewrite each of these five breakdown notes in the form: COMPONENT, what was found, what was done, whether it is likely to recur. Do not add facts that are not in the note; if a part is missing, write "not recorded".

An illustrative before and after:

The third row is the lesson. The AI cannot rescue an entry that holds no information, and a one-line template at the panel ("What part? What did you find? What did you do?") fixes it at source.

A second site: a bakery with two ovens and a mixer line

The method does not depend on plastics. Say a small bakery has two deck ovens, a spiral mixer, a divider and a cold store. Its log is shorter, 52 entries in six months, and the notes say things like "oven 2 not heating properly" and "cold store warm". Coded, 19 of the entries fall under three codes: oven element or thermostat faults (9), cold store door seal or defrost faults (6) and divider belt tracking (4). The cold store is not top of the count but has the highest stakes, because stock is at risk and food safety records matter. The AI ranks it by minutes lost, but the owner ranks it by consequence, and rightly adds it to the plan with a daily temperature check and a call-out agreement with the refrigeration contractor. The lesson is that the counts tell you where to look, and your own sense of consequence decides what goes into the plan first.

The cold store's temperature limits and any regulated records are for the food-safety lead to set and sign, in the same way the pressure vessel is for the competent person in the plastics example.

A monthly ten-minute review prompt

Once the first plan is running, do not repeat the whole analysis. Keep the coded log as a sheet, add the new month's rows, and run this:

Here is the coded log with a new month appended (rows 149 onwards). Using the same fault codes, tell me: (1) any code with a new event this month and how many days since its previous event; (2) any asset with its first-ever entry; (3) any PM task whose "found something" column shows a fault three cycles in a row; (4) any new note you cannot code with the existing list, with a suggested new code. Keep it to one page.

An illustrative reply: "Press 2 hose leak recurred on hose 1, 29 days after the previous event on hose 3, so a different hose; packing line: first entry for the labeller; new code suggested: Labeller / misfeed." The point is the change from last month, not another ranking. Add the new code to the printed list only after the team agrees it.

Keep a one-page "stopped and why" chart on the wall beside the panel, with last quarter's top five codes and minutes lost. Technicians who can see the cost of a fault tend to write better notes about it, and the chart gives the engineer a short, fact-based item for the monthly production meeting.

Keep the fault code list alive

The most valuable output is not the plan; it is the list of fault codes. Print it, keep it at the panel, and put it as a drop-down in the CMMS or sheet. Next time, the AI step shrinks from coding 148 rows to checking 15. Add a rule that "reset" or "checked" is not a note: every entry names the component and what was found. A technician can type that in a minute, and it makes every later analysis cheaper. If you are also worried about losing know-how as people retire, capturing what your best machinist knows sits naturally alongside it, and for a view of what is realistic with sensors, predictive maintenance for a small workshop is the honest next question.

Where the time goes

For a plant of this size, expect about two hours for the export and cleaning, 30 minutes for the first coding pass, 20 minutes for the team review of low-confidence rows, 45 minutes for the counts and cause hypotheses, and an hour or two for the engineer's review and sign-off. A day in total, spread across a fortnight. Any general-purpose AI assistant that reads spreadsheets will do; use a business plan where your data is not used for training, and remove technician names before upload. If you would rather work through your own log with someone, an AI implementation consultation is the setting for it.

Questions a maintenance lead usually asks first

Do I need a CMMS before I can do this?

No. A spreadsheet export or even a photographed paper log typed into columns is enough. A computerised maintenance management system makes the export cleaner and the plan easier to track afterwards, but the analysis works on any table with a date, an asset, a fault description and a repair time.

How many breakdown records do I need?

Around 80 to 100 entries across six months is enough to spot the worst two or three repeat faults on a small plant. With fewer than 30 records, read them yourself; the AI will tidy the notes but patterns will be thin and easy to over-read.

Can AI set safe inspection intervals for pressure systems or lifting gear?

No. Statutory examinations and anything protecting people have intervals set by regulation, the manufacturer and your competent person. Use AI to list which assets might fall into those groups, then let the responsible engineer decide the interval and sign the plan.

What if technicians write very short or inconsistent notes?

Expect it. Ask the AI to propose a fault code for each note and mark its confidence, then correct the low-confidence ones in a 20-minute team session. The corrected list becomes your fault code list for future entries.

Further reads

• Purchase Order Tracking: Build a Supplier Chase Sheet With AI — Chase the spares the plan says you need before a stop.
• Check a Bill of Materials With AI: Template, Gaps and Revisions — Check spare parts lists against what the plan needs.
• AI Quality Control for Small Manufacturers: Where to Start — See where machine condition shows up as scrap.
• Supplier Corrective Action Request: Draft a SCAR With AI — Raise a formal request when a bought-in part keeps failing.
• Six AI Applications in Manufacturing That Need No New Machines — Other jobs on the same site that need no new equipment.
• Factory Energy Audit With AI: Find Peak Loads and Idle Waste — Use the same cleaned asset list for an energy review.
• AI for Civil Construction: Plant Pre-Start Checks and Service Schedules — How a small civil contractor drafts plant pre-start checks, service intervals and a defect log from manuals with AI, with every line traced to a manual page.
• Farm Equipment Maintenance Log: AI Builds Service Schedules From Manuals — Turn tractor and implement manuals into a service schedule, a log with hour-meter reminders and short repair histories, with the manual always the final word.
• MRO Inventory Management: AI-Set Minimums for Maintenance Spares — One factory's spares sheet, built from work orders and a criticality score, with min and max rules and an obsolete-parts check.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: manufacturers' maintenance manuals for the assets in question and your own breakdown records; the worked example uses illustrative figures.