46. Recurring maintenance programmes and usage readings
Create independently approved recurring calendar/usage authority and attributable due-work evidence for one managed serialized instance without introducing a background scheduler or bypassing exact-stock maintenance controls.
Purpose
Create independently approved recurring calendar/usage authority and attributable due-work evidence for one managed serialized instance without introducing a background scheduler or bypassing exact-stock maintenance controls.
Stores Supervisor author/generator, different Stores Supervisor or Quality Inspector approver, Stores Officer usage recorder/executor and read-only Auditor
MPR-… v1 ACTIVE · HOURS-01 readings 0 → 250 · occurrence 1 due at 250 hours → MWO-… PLANNED → independent execution and release.
Before you begin
- One non-retired managed serialized item instance exists
- The actor has assigned-site scope and sufficient clearance
- A governed meter exists for usage-based triggers
- Different named author, executor and release users are available
- Calibration-controlled work has an eligible same-instance certificate before passing completion
Recurring authority, immutable evidence and operational boundaries
A stable HOURS or CYCLES identity belongs to one managed instance and accountable site. It does not read a machine automatically.
Each dated value retains its source, previous reading and idempotency key. Values and dates cannot move backwards, and retained evidence cannot be updated or deleted.
Title, type, trigger, baselines, intervals, lead days, instructions and task template are immutable and SHA-256 checksummed. Amendments create another version.
The author/submitter cannot approve their own version. Approval supersedes the prior approved definition for future generation without rewriting prior work.
Calendar and usage thresholds derive from the approved baseline plus interval × occurrence, preventing completion timing from silently drifting the approved schedule.
No background scheduler creates work. An authorised planner deliberately generates only when the approved boundary is reached; an idempotency key makes retries safe.
Generated work uses the same exact-serial stock block, different planner/executor, approved checklist, calibration certificate gate and independent release as one-off work.
The feature cannot invent usage, control equipment, move stock at programme approval/generation, release serviceability, purchase parts, allocate labour/cost or send external messages.
Procedure
- 1
Register a usage meter when HOURS or CYCLES will govern due state.
- 2
Create and submit immutable programme v1 with one or both anchored triggers and the required task template.
- 3
Approve the exact version as a different release authority.
- 4
Record attributable monotonic usage readings as observed; never estimate or overwrite history.
- 5
Review the deterministic next occurrence and choose Generate work when ready.
- 6
Execute and independently release the generated work through the established maintenance lifecycle; reconcile the programme/version and generation snapshot on the work order.
Expected result
- Programme definitions are immutable, checksummed and independently approved
- Usage readings are append-only, monotonic and idempotent
- No work is generated before an approved trigger boundary
- Generation is a named human action, never a scheduler side effect
- A managed instance has at most one active maintenance work order
- Generated completion checklist names match the approved task template
- Planner, executor and releaser remain different named users
- Site, clearance and classification rules apply
- Programme and generation actions do not change stock
- Only existing start/release transitions affect the exact blocked/unrestricted stock identity