FDE 4: Approvals design
Approvals are the human gate the whole engagement is accountable for. Design them from the discovery risk list, verify them in probe sessions, and tune them from pilot denial patterns.
Build the approval matrix
Section titled “Build the approval matrix”From the scope doc’s risky-actions list, classify every action class:
| Action class | Disposition | Approver role | What approver sees |
|---|---|---|---|
| (e.g., read ticket) | Allow (flow) | None | Logged, no gate |
| (e.g., draft reply) | Allow (flow) | None | Draft reviewable in transcript |
| (e.g., apply update) | Gate | Service lead | What, on-what, why, blast radius |
| (e.g., bulk change) | Gate or Deny-by-default | Duty owner | Same, plus explicit blast-radius statement |
| (e.g., out-of-scope system) | Deny-by-policy | None | Attempt blocked, session redirected |
Rules:
- Gate on risk, not volume. Irreversible, customer-visible, cross-system actions gate. Reads and drafts flow.
- Approvers by role, not name. “Service lead on duty” survives rotations; a named person does not.
- Deny-by-default for the truly out-of-scope. Some actions should not be approvable at all. Policy says no, not a person.
- Every gate reviewable. The approver gets what, on-what, why, and blast radius at decision time. Design sessions and tools so that context exists (see Skills, tools and MCP).
Verify the matrix: probe checklist
Section titled “Verify the matrix: probe checklist”- Each gated class fires its gate in a test session (not assumed from config)
- Gate content complete: what, on-what, why, blast radius all present
- Allow path: action runs, record complete
- Deny path: action stays denied, session continues sanely
- Deny-by-default classes actually unreachable via approval (no bypass path)
- Right role routes to the right humans (approver mapping tested, not just written)
Tune from the pilot
Section titled “Tune from the pilot”| Pilot signal | Reading | Action |
|---|---|---|
| Zero denials across many sessions | Rubber-stamping or gates too loose | Spot-check approvals; consider whether gates fire where risk is |
| Same denial repeatedly | Environment, goal, or policy wrong | Fix the design, do not blame operators |
| Routine work constantly gated | Policy tighter than workload | Loosen with evidence, keep risky gates |
| Approvers batching decisions | Fatigue setting in | Reduce gate volume (fewer, sharper gates) or add approver coverage |
| Confusion about what a request means | Tool or skill output unclear | Fix the what, on-what, why at the capability level |
The approval matrix
Section titled “The approval matrix”The matrix table above, plus: approver-role to humans mapping, review date, and pilot tuning log. It ships in the handoff pack and lives with the environment spec.
Next: Handoff transfers a verified, tuned build to the tenant team.