Authority Model
Who Can Approve What
Authority mapping turns “who is allowed” into an enforceable system primitive. The authority model defines roles, approval requirements, escalation routes, and override constraints based on risk band and action class.
Authority Principles
Authority must be explicit, enforceable, and auditable. Social assumptions are not governance. Layer-7 encodes authority so systems can route decisions correctly and deny when authority is absent.
Explicit routing
Every risky action maps to a required approver role set with signature counts.
Least privilege
Roles can approve only within scoped domains. Privilege is not universal.
Audit integrity
Approvals and overrides are recorded in the decision ledger with actor identity and intent.
Role Levels (Reference)
Roles are organized by control scope. Implementations can rename roles, but must keep clear separation between operational approval and executive exception authority.
| Level | Role (example) | Scope | Typical approvals |
|---|---|---|---|
| L1 | Operator | Routine, low-risk actions | Read access, non-sensitive tasks |
| L2 | Supervisor | Team-level scope | Medium risk writes, limited changes |
| L3 | Manager | Department scope | High-risk actions in defined domain |
| L4 | Security / Compliance Officer | Cross-domain governance | High/critical security, data, infra actions |
| L5 | Executive Approver | Exception authority | Critical actions, emergency exceptions |
Signatures & Verification
Approvals must be verifiable. In production, signatures should be tied to identity (JWT claims, mTLS identity, or signed payloads). Every approval includes an intent string to prevent ambiguous “rubber stamp” approvals.
Approval record
Verification rules
- Identity must be authenticated (no anonymous approvals).
- Role must match required route for this decision.
- Signature must be unique per actor per decision.
- Approvals must be logged before execution is allowed.
Mapping Tables (Risk Band × Action Class)
These tables are the practical “router.” They map decisions to required roles and signature counts. Adjust per organization, but keep the pattern: risk increases → approvals strengthen.
Core action classes
| Action class | Low | Medium | High | Critical |
|---|---|---|---|---|
| read_public | None | None | L2 (1) | L3 (1) + L4 (1) |
| read_sensitive | L2 (1) | L3 (1) | L3 (1) + L4 (1) | L4 (1) + L5 (1) |
| write_data | L2 (1) | L3 (1) | L3 (1) + L4 (1) | L4 (1) + L5 (1) |
| deploy_code | L3 (1) | L3 (1) + L4 (1) | L4 (1) + L3 (1) | L4 (1) + L5 (1) multi-sig |
| transfer_funds | L3 (1) | L3 (1) + L4 (1) | L3 (1) + L4 (1) | L4 (1) + L5 (1) multi-sig |
| rotate_credentials | L3 (1) | L4 (1) | L4 (1) + L3 (1) | L4 (1) + L5 (1) multi-sig |
Escalation Routes
If required approvers are unavailable or an exception is required, escalation must be deterministic and logged. Escalation is not “asking louder.” It is an encoded routing path.
Reference escalation
- L1 → L2: routine block / missing context
- L2 → L3: medium-to-high risk promotion
- L3 → L4: security/compliance involvement required
- L4 → L5: critical actions and exceptions
Escalation constraints
- Escalation must include reason and timeout.
- Escalation must not weaken requirements (no “approve anyway”).
- Escalation events must be recorded in the ledger as transitions.
Overrides (Controlled Exception Path)
Overrides are allowed only when explicitly permitted by policy and only when performed by elevated authority. Overrides must be treated as special decisions with explicit markings and review requirements.
Override requirements
- Role: L4 or L5 depending on action class
- Reason: mandatory structured reason string
- Scope: must be limited (time-bound and target-bound)
- Review: post-execution review required