Framework
Human Approval Architecture
Designing approval boundaries so intelligence can draft, prepare and route work while people stay accountable for decisions.
- Type
- Framework
- Topic
- Governance
- Author
- AEGIS OS™
- Published
- Updated
Key takeaways
- An approval boundary is a structural property of the system, not a policy document. If the work can proceed without the approval, there is no boundary.
- Approval is worth something only when the approver can see what they are approving, and the reasoning behind it, in the time they actually have.
- Rubber-stamping is a design failure. When every item requires approval, none of them receive attention.
- Every boundary needs four things: a held state, a named approver, a visible basis for the decision and a recorded outcome.
The anatomy of a real boundary
- Held state
- The work stops in a defined status and cannot advance. Not a notification that work has already happened.
- Named approver
- A specific role with the authority to make this class of decision, with a defined deputy for absence.
- Visible basis
- What the intelligence produced, what it used to produce it, and what it was uncertain about — presented in the approver's view, not in a log.
- Recorded outcome
- Approved, rejected or amended, by whom, when, with any note. This is the audit trail, and it is written whether or not anyone ever asks for it.
The test that matters
Remove the approver for a day. If work continues to flow out of the organisation, the boundary was decorative.
Four levels of intelligence authority
Not every step warrants the same weight of approval. AEGIS assigns each step one of four levels, and the level is recorded alongside the workflow rather than left to convention.
| What intelligence may do | Where a person sits | Typical use | |
|---|---|---|---|
| Prepare | Assemble, reconcile, summarise, rank | Reads the output before any use | Diligence packs, committee preparation |
| Draft | Produce the artefact in full | Edits and issues it under their own name | Correspondence, memos, summaries |
| Route | Move work to the correct owner or queue | Owns the destination and can reroute | Triage, allocation, exception handling |
| Execute within bounds | Complete a defined, reversible step | Reviews by exception and on sample | Record updates, status changes, notifications |
Designing for finite attention
The scarce resource in any approval architecture is the approver's attention. A boundary that consumes more of it than the decision is worth will be bypassed within weeks, and the bypass will be informal and invisible.
- Batch low-consequence approvals; escalate individually only what is irreversible or unusual.
- Surface the exception, not the volume — what is unusual about this item relative to the last hundred.
- Show uncertainty explicitly. An approver who cannot see where the system was unsure cannot add anything.
- Measure time-to-approval. A queue that grows is telling you the boundary is in the wrong place.
Sources and references
Describes the AEGIS governance approach. Contains no client data and no compliance or certification claim.
Start with an Architecture Assessment
An Architecture Assessment turns these questions into a documented blueprint, readiness analysis, implementation roadmap and quote for your organization.
Related resources
Framework
What Should Never Be Fully Automated
Decision classes that require a named human owner, and how to encode those boundaries in an operating system.
Framework
AI Agents vs Automations vs Workflows
How agents, automations and workflows differ in scope, control and accountability, and when each one is the right instrument.