Due status answers when calibration work needs attention. Requirement lifecycle answers whether the schedule is operational. These are related, but they are not the same field.
Obsidian Metra calculates due status on the Metra. It is derived when records are read and is not stored as a permanent status that users update manually.
See the Calibration status reference for the complete lifecycle transition and due-state tables.
official due states
For the dashboard work queue, the states are:
| State | Meaning |
|---|---|
current | The active requirement is earlier than its warning window |
due_soon | The active requirement has entered its warning window but is not yet due |
due | The next due date is today at the equipment site's local date |
overdue | The next due date is earlier than the equipment site's local date |
suspended | The requirement schedule has been deliberately suspended |
Draft requirements have scheduling state not_applicable and are included in the default dashboard queue so unfinished commissioning work remains discoverable. Retired and archived requirements are excluded. Due-state summary counts cover active and suspended schedules; their denominator differs from the default queue.
How the calculation works
The Metra applies the rules in this order:
- A suspended requirement is
suspended. - An active requirement with a next due date before the current site-local date is
overdue. - An active requirement due on the current site-local date is
due. - An active requirement on or after the next due date minus its warning period is
due_soon. - An active requirement with a later due date is
current.
An active requirement must have a next due date. Missing official schedule data is an integrity error, not a current requirement.
Site timezone and calendar dates
Due dates are calendar dates, not moments in the viewer's timezone. The system converts one request-time UTC instant into each assigned site's stored IANA timezone, then compares the site's local date with the requirement's next due date.
This means two sites can have different due states at the same instant when they are on opposite sides of local midnight. Daylight-saving changes do not turn date-only due dates into elapsed-hour calculations.
The requirement and dashboard display the site timezone and local date used. Verify a site's timezone in Create sites and location hierarchies before relying on its schedule.
No completed calibration yet
“No completed calibration” describes schedule provenance, not a separate dashboard Due status option.
When a requirement is first activated, its initial due date is the scheduling baseline. The date is scheduling data, not approved calibration evidence. It can still be current, due soon, due, or overdue even though no approved calibration event has yet moved the schedule.
After an acceptable calibration event is approved, the next due date is calculated from the performed date and the interval snapshot submitted with that event. The requirement records whether its current due date came from the initial due date, a manual adjustment, or an approved calibration event.
Intervals and approved dates
Days and weeks use their calendar units. Months and years use calendar arithmetic rather than fixed 30-day or 365-day approximations. End-of-month baselines preserve valid end-of-month behavior, including leap years.
Editing an interval or warning period does not silently replace an already approved next due date. Use the controlled Adjust due date action, permission, reason, and current record version when the date itself must change.
Safe interpretation
- Treat the displayed Metra state as official; do not recreate it from your device clock or a spreadsheet.
- Check lifecycle before treating
not_applicableas completed work. - Check the next-due-date source when investigating why a date changed.
- Use the dashboard's Due from and Due to filters for date windows, not manual status guesses.
- Resolve site-timezone errors before making compliance decisions.
Next steps
Read evidence currency separately
The server also projects evidence currency. Initial evidence required, Current approved evidence, Approved evidence due soon, Approved evidence due, Approved evidence overdue, Approved evidence is not current and Not checked describe the applicable approved evidence, independently of the schedule badge. An unacceptable result, changed requirement revision or missing approved event cannot be made current by saving a future initial date.
Review requirement prerequisites from its detail page or work-order planning. Planning a draft communicates outstanding work; execution still applies the current method, reference range, site, date, technical authority and independent approval checks. Equipment release is another controlled decision.
Voiding or superseding a calibration recalculates the schedule from effective acceptable evidence. An overall passing result with failed or indeterminate measurements or failed device procedure evidence remains unacceptable for scheduling. Recalculation does not use that evidence to advance the due date or release an equipment hold.