ADR-0003: Fixed Life Cycle States with Configurable Review Processes¶
- Status: accepted
- Date: 2026-06-04
- Deciders: Nicolas Burri
- Refined by: ADR-0030 (review & life-cycle realization model), ADR-0066 (amends the fixed lifecycle: IN_REVIEW gains a second exit besides reject — WITHDRAW, the author side reclaiming its own version)
Context¶
Document life cycles must be configurable, "especially concerning the review processes" (project_overview.md). The motivating negative example is the current Comala-workflows- plus-Jira setup: highly complex to configure, yet unable to express simple policies such as a four-eyes rule. The design goal is therefore expressiveness for review policies, not flexibility of the state machine itself.
Options Considered¶
Option 1: Fixed state set, configurable review processes¶
States are built into the system; what is configurable per scope and document type is the review/approval process and transition permissions.
- Pros: every feature (derive rules, search filters, reports, audit queries) can rely on well-defined states ("only released versions may be derived"); configuration surface stays small and auditable; simple policies are simple to express.
- Cons: unusual workflows requiring genuinely different states cannot be modeled.
Option 2: Fully configurable state machines¶
Admins define arbitrary states and transitions per document type.
- Pros: maximal flexibility.
- Cons: reproduces the Comala problem — high configuration complexity while simple policies still need explicit support; every feature must handle arbitrary states; "released" degrades from a state to a per-configuration attribute.
Option 3: Configurable states mapped to fixed semantic categories¶
Custom state machines whose states must each map to a built-in category (working / in-review / effective / retired); features key off categories.
- Pros: custom vocabulary and extra states with feature-safe semantics.
- Cons: more machinery than currently needed.
Decision¶
Option 1. The life cycle state set is fixed:
DRAFT ──submit──▶ IN_REVIEW ──all approvals──▶ RELEASED ──revoke──▶ REVOKED
▲ │ │
└──────reject───────┘ └──new version──▶ DRAFT (next version)
Configurable per scope and document type (the review policy):
- Required approvals: a set of role-based requirements, e.g. "1 × Quality Manager AND 1 × Project Lead", each optionally with a minimum count.
- Four-eyes rule: the author of a version cannot count as one of its approvers. Default: enforced. May be relaxed only by explicit configuration (visible in audits).
- Transition permissions: which roles may submit, approve, reject, release, revoke.
- Release mode: automatic on last approval, or explicit release step by an authorized role (e.g. to set an effective date).
Version semantics: editing a RELEASED document never mutates it — it starts a new DRAFT version; the released version stays effective until the new one is released (it then becomes superseded) or stays in force if the draft is abandoned.
Option 3 is the designated evolution path: the four fixed states would become the default semantic categories, so later migration is additive, not breaking.
Consequences¶
- The domain model gets
review policyas an explicit, per-scope/document-type configuration entity — small enough to display and audit on one screen. - Approvals are recorded per version with user, role-in-which-approved, and timestamp — this is the approval history required for audit reproducibility (ADR-0001 context).
- Rejection feedback (review comments) needs a home in the domain model — TBD in the domain discussion.
- Features may hard-code state semantics (e.g. derive requires RELEASED, ADR-0002) — that is the point of this decision.
- If a future document type genuinely needs different states, the answer is migrating toward Option 3 — not weakening the fixed set with per-installation special cases.