ADR-0091: Release Modes — Single-Person Record Release With a Structural Four-Eyes Floor¶
- Status: accepted (Nicolas 2026-07-22, train session — R1 "agree", R2 "very good" + the clarification recorded in §2, R3 "agree", R4 "agree")
- Date: 2026-07-22
- Deciders: Nicolas Burri, design by Claude. Origin (2026-07-19): meeting notes and similar "proof the process ran" records are single-person-releasable in the legacy system; forcing four-eyes on them is pure friction.
- Relates to: ADR-0003/0030 (review policies — the mechanism home), ADR-0046/0047 (four-eyes), ADR-0049 (document categories — the floor's anchor), ADR-0064 (per-document workflow roles), ADR-0089 (recurring obligations — the synergy consumer).
- Regulatory frame: ISO 13485 §4.2.5 requires records to be identifiable, legible, retained — it does NOT require independent approval; §4.2.4 requires review + approval for documents. The category split (ADR-0049) maps exactly onto that clause split.
Decision¶
- A release MODE on the per-(scope, type) review policy —
STANDARD(submit → approve → release, exactly as today) orDIRECT(an authorized role holder releases straight from DRAFT). No new lifecycle, no new states: DIRECT is a policy-permitted transition, so everything downstream is untouched — effectivity, retention, disposal, addressees, acknowledgement, training obligations, audit. - DIRECT permits, never forbids (Nicolas's R2 clarification, pinned): record types may stay STANDARD; and on a DIRECT-configured type, any individual document may still be routed through the full submit → approve → release flow by choice. The shortcut is granted, the ceremony remains available.
- The structural floor: DIRECT is configurable ONLY for RECORD-category types. PRESCRIPTIVE and TEMPLATE types cannot be set to DIRECT — enforced server-side and in the schema, not by convention. Prescribing documents always get independent review (§4.2.4); templates propagate into every instantiation, so they keep the same floor.
- Guardrails under DIRECT: the release is a deliberate, attributed, audited act (RELEASED event with actor; change info on revisions); the comments-resolved release gate still evaluates; acknowledgement/training fan-out unchanged. Because there is no submit, the ADR-0064 workflow-role binding requirements do not apply to DIRECT releases (no empty-group block for a meeting note); a document routed through the standard flow on a DIRECT type gets the full ADR-0064 enforcement as usual.
- Configuration guidance, not tooling (R4): the scope-config surface documents the doctrine — before configuring DIRECT for a record type, ask whether the record (and the process step producing it) is needed at all. Nicolas's context, recorded because it names the deployment risk: regulatory advisors "love to go through the motions, whether they actually make sense or not" — the structural floor (§3) is the answer to ceremony-pressure: the dangerous relaxation is impossible, so the only debate left is about record types, where §4.2.5 requires no independent approval.
Consequences¶
- Additive migration (release_mode on the review policy, default STANDARD), LifecycleService gains the policy-gated DRAFT→RELEASED transition, scope-config review-policy tab gains the mode (RECORD-category types only — the UI never offers it elsewhere), seed examples.
- The ADR-0089 synergy: obligation-completing records (cloud verification, backup rehearsals) are exactly the single-person shape — DIRECT-mode record types make recurring obligations frictionless end to end. The two implement naturally as one wave.
- Separation/audit tests extend (DIRECT release by an unauthorized role 403s; PRESCRIPTIVE set-to-DIRECT rejected at the API and absent from the UI).
- REQ rows at the next baseline.
Clarification (2026-07-22) — implemented as a distinct release_flow column/field, not release_mode¶
Recorded at implementation time. §1 sketched the mode on the review policy as a column release_mode
(STANDARD | DIRECT). That name was already taken: review_policy.release_mode (V013, REQ-LC-007) is the
AUTOMATIC | EXPLICIT axis — whether a STANDARD flow's RELEASE fires automatically on the last approval or
waits for a manual act — and it is exposed on the review-policy DTO as releaseMode. The two are
orthogonal: STANDARD/DIRECT decides whether the submit→approve ceremony exists at all; AUTOMATIC/EXPLICIT
only qualifies a STANDARD flow's release trigger. So the ADR-0091 concept is implemented as a separate
additive column release_flow (V062, STANDARD | DIRECT, default STANDARD) and a separate wire field
releaseFlow on the review-policy read/write DTO (§4). The intent of §1/§4 is unchanged — only the
identifier differs to avoid the collision. Frontend contract note: the scope-config review-policy DTO
gains releaseFlow (STANDARD | DIRECT), NOT a releaseMode value; the getVersion action-reflection surface
gains an honest directRelease action (applicable/allowed/reason in {NOT_DIRECT_FLOW, NOT_RELEASER,
WRONG_STATE, UNRESOLVED_COMMENTS, TRAINING_QUESTIONNAIRE_MISSING}); the DIRECT release endpoint is POST
/api/documents/versions/{versionId}/direct-release (optional {effectiveFrom} body, like release).
Two guardrail interpretations, made explicit: (a) the DIRECT role gate mirrors STANDARD release exactly — the document's RELEASER binding (ADR-0064, copied from the type policy's RELEASE roles) — so enforcement and the getVersion reflection cannot diverge; and (b) a DIRECT-configured policy MUST name ≥1 RELEASE role (mirroring the existing EXPLICIT rule), so the single-person release stays an attributed, role-held act and never deadlocks — this replaces §3's "(or, absent roles, the release permission)" sketch, since LQMS has no functional RELEASE permission (release is role-gated throughout, ADR-0064). The comments-resolved gate still evaluates on the direct path; the training-questionnaire gate (ADR-0070 §3, "every path into RELEASED") does too; the approvals gate does not (there is no review round).