Understand due status

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:

Draft, retired, and archived requirements are not_applicable in requirement views and are not part of the active dashboard work queue.

How the calculation works

The Metra applies the rules in this order:

1. A suspended requirement is suspended.
2. An active requirement with a next due date before the current site-local date is overdue.
3. An active requirement due on the current site-local date is due.
4. An active requirement on or after the next due date minus its warning period is due_soon.
5. 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 approved initial due date is the scheduling baseline. 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_applicable as 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

• Use the calibration dashboard
• Create a calibration requirement
• Record calibration work