Preventive or corrective? And the asset's maintenance record

2 minfacility_manager

The auditor's usual question: «how much of your maintenance is planned, and how much is firefighting?» The answer needs a split that is not guessed.

The kind is earned by lineage, not by negation

KindWhen
Preventivethe card was born from a maintenance plan
Correctiveborn from a fault report that was accepted and converted
Otherneither plan nor report: installation, improvement, stock-take, relocation

«Not preventive» does not mean corrective. A real facility's board carries much work that is not repair; counting it as corrective inflates the failure figure in front of an auditor and ruins any later reading of asset health.

And if both causes meet — a plan-born card that later had a report attached — it stays preventive: birth outranks attachment, which keeps the on-screen preventive count identical to the schedule-compliance measure.

Practical note: a repair a technician writes straight onto the asset with no prior report shows as «other». If your team logs repairs directly, route the work through a report (even one you log yourselves) so it earns its lineage.

The asset's maintenance record

The asset page carries a card gathering everything that happened to this part: work written directly on it, and work generated by its maintenance plans — one row per job however many streams feed it.

Above it a strip answers before you read the table:

  • Last preventive — when it was last serviced.
  • Last corrective — when it last failed.
  • Next preventive — the nearest unfinished due date (an overdue one stays visible; we do not prettify the picture).

And a kind filter shows only what concerns you.

When maintenance fails

A maintenance task that was carried out and fixed nothing is not really «complete». From the task card: «A failure needing treatment» — write the reason and a corrective action is born, inheriting the card's links to standard clauses, so the treatment shows in the clause file instead of the clause turning green over a live defect.

And the system never infers failure from a closure or a delay: failure is a human testimony that states its reason.

Read next

More in this collection