From recurring schedules and meter-based triggers to an unplanned breakdown work order: one system, one audit trail. You build the templates once; the operational records form themselves out of everyday activity.
The configuration that rarely changes. Getting these four right is most of the work, and it is work you do up front rather than over and over.
Generated from what actually happened, rather than maintained by hand.
A Plan falls due, or something breaks. Either way a Work Order is created, moves to In Progress, and can only reach Done once three conditions are met.
A machine working harder should be serviced sooner, not on the same calendar date as one sitting idle. All three trigger types are available.
| Trigger | How it fires | Example |
|---|---|---|
| Calendar | Every N days, regardless of usage | Monthly inspection, due on the 1st whether the machine ran 10 hours or 300 |
| Meter | Every N accumulated running hours | Service every 500 running hours, not every 60 days |
| Both | Whichever comes first | A heavily loaded machine still gets serviced on time, even before its calendar date arrives |
An advance-notice window creates the next occurrence early, so the work is visible and can be planned before it actually falls due.
The questions maintenance and QA teams usually ask before deciding.
No. Required spare parts must be fully consumed before the Complete button becomes active, and that is enforced server-side, not in the interface.
Yes. Every spare part has a minimum stock level, and dropping below that threshold raises a reorder alert automatically.
Yes. Meter-based triggers fire on accumulated running hours, and a combined Calendar+Meter trigger fires on whichever threshold is reached first.
Yes. The completion flow is identical, the audit trail is identical, and it is classified against the same failure mode catalogue.
Yes, per task, using the same hash-chained signature mechanism as regulated production steps.