ADR-0004: Global Catalogs for Roles and Document Types with Per-Scope Activation¶
- Status: accepted
- Date: 2026-06-04
- Deciders: Nicolas Burri
Context¶
Roles and document types must be configurable, and the required set differs per project. Two negative experiences inform this: (a) a QMS that imposed many roles that were useless to a given project, and (b) the general risk that free-form per-project definitions fragment the vocabulary that review policies and cross-project reporting depend on.
Options Considered¶
Option 1: Free-form definitions per project¶
- Pros: maximal project autonomy.
- Cons: review policies on base documents cannot reliably reference roles across projects; vocabulary fragments irreversibly ("SW Lead" vs. "Software Responsible"); cross-project queries and regulatory re-evaluation reports lose their basis.
Option 2: Global catalogs with per-scope opt-in activation¶
Definitions live in the global scope as curated data; each scope activates the subset it needs and staffs activated roles.
- Pros: shared vocabulary preserved; unused entries cost a project nothing; catalog is extensible data, not code; consolidation never needed because fragmentation never happens.
- Cons: a project needing a new role/type must request a catalog entry (a deliberate, small governance step).
Decision¶
Option 2, with a three-layer role model:
- Definition (global scope): catalog entry — name, description, translations. Curated, extensible at any time. Same pattern for document types.
- Activation (per scope): a scope opts in to exactly the roles/types it uses. Nothing is ever imposed on a scope.
- Staffing (per scope): users are assigned to activated roles; one user may hold several roles. The four-eyes rule (ADR-0003) binds to authorship, so multi-role users cannot self-approve.
Derive-time validation: deriving a document whose review policy references a role not activated in the target scope prompts the user to either activate and staff the role or consciously adapt the scope's copy of the policy — an auditable configuration change, never a silent fallback.
Free-form project-local roles are explicitly excluded for now; if catalog governance ever becomes a real bottleneck, adding project-local roles later is the easy direction (consolidating fragmented roles into a catalog is the painful one).
Consequences¶
- The domain model gets
roleanddocument_typeas global catalog tables plus per-scope activation tables (see arc42 §8.1). - Review policies may only reference catalog roles; validation enforces that active policies reference roles that are activated (and staffed) in their scope.
- Catalog maintenance (adding roles/types) is a global-scope permission — governance of that permission is configured like any other role-based right.
- Cross-project reporting and regulatory re-evaluation can rely on a stable vocabulary.