Calibration status reference
A calibration requirement exposes two different kinds of status:
statusis the persisted requirement lifecycle; anddue_statusis a derived read state calculated by the Metra.
Do not use one as a substitute for the other. An active requirement can be current, due soon, due, or overdue.
Persisted requirement lifecycle
| Value | Meaning | Due-state effect |
|---|---|---|
draft | The recurring obligation is being prepared | not_applicable |
active | The schedule is live and requires an official next due date | Derived as current, due_soon, due, or overdue |
suspended | The schedule is deliberately paused without resetting its next due date | suspended |
retired | The obligation no longer applies | not_applicable |
archived | The terminal record is retained as history | not_applicable |
Permitted lifecycle transitions
| From | Permitted target values |
|---|---|
draft | active, archived |
active | suspended, retired |
suspended | active, retired |
retired | archived |
archived | None |
Initial activation does not require a reason. Suspension, resumption, retirement, and archival require a reason. Retired and archived requirements cannot be updated or restored through the normal workflow.
Retirement or archival is blocked while the requirement has open calibration events.
Requirement activation prerequisites
Activating a draft requirement requires:
- an explicit initial due date;
- equipment with persisted status
active,quarantined, orout_of_service; - an active responsible member in the same organisation when one is selected;
- the required change-status permission and current record version.
Equipment in draft, retired, or archived cannot support requirement activation. Activation copies the initial due date into the live next-due-date schedule and records initial_due_date as its source.
Resuming a suspended requirement keeps its existing schedule; it is not a new initial activation.
Derived due states
| Value | Exact implemented meaning |
|---|---|
current | Active, with the site-local date before the warning window |
due_soon | Active, with the site-local date on or after next_due_date - warning_period_days, but before the due date |
due | Active, with next_due_date equal to the current site-local date |
overdue | Active, with next_due_date before the current site-local date |
suspended | The persisted requirement lifecycle is suspended |
not_applicable | The persisted lifecycle is draft, retired, or archived |
The dashboard work queue contains active and suspended requirements and therefore filters on current, due_soon, due, overdue, and suspended. not_applicable remains available in equipment requirement views.
An active requirement without a next due date is invalid persisted state and produces an integrity error. It is not treated as current.
Site-local official calculation
The Metra uses one UTC clock instant per request and converts it into the current equipment site's stored IANA timezone. It then compares date-only values using that site's local calendar date.
For example, at one UTC instant:
| Site context | Local date | Due date | Result |
|---|---|---|---|
| Site A, before local midnight | 2030-03-30 | 2030-03-31 | due_soon or current, depending on warning period |
| Site B, after local midnight | 2030-03-31 | 2030-03-31 | due |
The user's browser timezone does not override this calculation. Due status is derived rather than persisted because it can change when a site's local date crosses midnight even when no record is edited.
Next-due-date sources
next_due_date_source is persisted and has these implemented values:
| Value | Meaning |
|---|---|
initial_due_date | The activation baseline is still official |
manual_adjustment | An authorised user adjusted the due date with a reason |
approved_calibration_event | An approved acceptable calibration event advanced the schedule |
Changing interval or warning settings does not silently replace an already approved next due date. Due-date adjustment is available only for active or suspended requirements and is a controlled revision.