Software Requirements: Recurring Obligations¶
Introduced in requirements baseline v1.8 (ADR-0089, extended by ADR-0094). Recurring QMS duties with defined intervals and record evidence (ISO 13485 §6.3 — e.g. cloud verification, backup rehearsals, environment checks): the opinionated replacement for calendar event series, structurally enforced and audited inside the QMS. An obligation is configuration; its executions are the records. This is a QMS-operations concern (STR-015), distinct from the person-and-document read-acknowledgement of REQ-TRN.
| ID | Requirement | Trace |
|---|---|---|
| REQ-OBL-001 | A recurring obligation shall be a per-scope, RLS-separated configuration object (not a controlled document — its executions are the records) carrying a name, optional description, a schedule (REQ-OBL-004), one or more responsible roles, an ACTIVE flag, and a completion criterion designating a RECORD-category document type in the scope. Define/edit/delete shall be gated by CONFIGURE_REVIEW_POLICY — the same scope-config gate that governs review policies and coverage rules (no new configuration permission is minted) — and authored on the scope-config surface; every obligation lifecycle act shall be audited. | STR-015, STR-003; ADR-0089, ADR-0073 |
| REQ-OBL-002 | Completion shall require no extra user action: a newly RELEASED record of the completion type in the scope is the evidence. Obligation status shall be DERIVED, never stored — the last completion is the latest effective RELEASED version of the completion type (else the obligation's creation time as the anchor), the next-due is the schedule's occurrence after the anchor (REQ-OBL-004), with a due-soon window and an OVERDUE verdict. The oversight derivation and the SQL scheduler sweep shall compute the SAME anchor and next-due arithmetic so the reported verdict and the sweep's task raise/resolve can never diverge. A self-contained scheduler sweep shall raise one OBLIGATION_DUE inbox task per responsible role (idempotent while OPEN) to the responsible-role holders, and reconcile it — a fresh completion or a deactivation that moves the obligation out of its window shall auto-resolve the open task; OBLIGATION_DUE shall not be manually resolvable (it resolves only through completion). |
STR-015, STR-023; ADR-0089, ADR-0038, ADR-0039 |
| REQ-OBL-003 | The system shall provide a per-scope obligations-status oversight roll-up (GET /api/scopes/{scopeId}/obligations-status) presenting each obligation's derived freshness state (OK / DUE_SOON / OVERDUE), last completion, schedule, and an aging summary. The oversight read shall be gated by a dedicated per-scope VIEW_OBLIGATIONS permission (the ADR-0080 per-view pattern; backfilled to every role already holding VIEW so today's reach is preserved), a caller lacking it refused (403), and RLS shall bound the returned data on top of the functional permission. |
STR-015, STR-011; ADR-0089, ADR-0080 |
| REQ-OBL-004 | An obligation's schedule shall be one of three kinds with per-kind parameters and validation: INTERVAL (every N days from the last completion — the default), MONTHLY (day D, 1–31, of every month), and YEARLY (month M, day D, of every year); named presets ("end of the month", "end of the year") are parameters, not kinds. The clamp rule shall guarantee the due date is never later than the nominal day — when a month has fewer than D days the occurrence is that month's last day (Feb → 28/29, Apr → 30; YEARLY Feb-29 → Feb-28 in non-leap years), "too soon rather than too late". Next-due shall be the first schedule occurrence strictly after the anchor (the last completion, else creation time), so one completion never satisfies two occurrences; dates shall be UTC calendar dates; and the sweep–derivation parity (REQ-OBL-002) shall extend to the calendar arithmetic, pinned against each other on the hostile cases (Jan-31 → Feb, leap years, an anchor exactly on an occurrence). |
STR-015; ADR-0094, ADR-0089 |