Concepts
Configuration and approvals
Configuration is a subsystem, not a settings table. Changes are proposed, reviewed and versioned, and the version in force at a decision is recoverable.
Written from docs/adr/0005, docs/adr/0008 — this page is written for an external reader rather than extracted verbatim
Rules, risk factors, form definitions, report mappings and thresholds are configuration documents: versioned, schema-validated and layered, with a platform default a tenant may override. A change produces a new version rather than mutating the current one.
Maker-checkerPermalink to this section
Approval is a single generic primitive rather than a separate workflow per surface. One approval-request table carries the proposed change, its author, its reviewer and its outcome, and every surface that needs four-eyes review uses it. A bespoke approval flow per feature is how a system ends up with one that quietly permits self-approval.
- The proposer and the approver must be different people.
- The proposal carries the full before-and-after, so a reviewer sees what changes rather than a summary of it.
- The outcome is audited on the same chain as everything else.
Content packsPermalink to this section
Regulatory content — risk factor sets, code lists, form definitions — ships as signed, versioned packs. A tenant records which version it has adopted, so two institutions on the same deployment can be on different pack versions and each decision is traceable to the one in force for that tenant at that time.