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.
- Type
- Framework
- Topic
- Governance
- Author
- AEGIS OS™
- Published
- Updated
Key takeaways
- Some decisions stay with a person permanently, not until the technology improves. Capability is not the variable being tested.
- Five decision classes carry a named human approver in every AEGIS deployment.
- The classification test has four questions: reversibility, who discovers the error, whose authority is being exercised, and whether the reasoning must be defensible afterwards.
- A boundary that exists only in policy is not a boundary. It is enforced in the system, recorded in the audit trail and attached to a named person.
Autonomy is not the goal
Most automation roadmaps treat human involvement as debt to be retired. That framing is wrong for any organization that carries obligations to clients, investors, regulators or counterparties. In those organizations, certain decisions are the accountability itself — removing the person does not remove the accountability, it detaches it from anyone who can exercise it.
The distinction that matters
Assistance and authority are separate. Intelligence may prepare, reconcile, draft, rank and explain any decision in this document. What it may not do is issue the decision.
The four-question classification test
AEGIS applies this to every step during the ARCHITECT stage. Any single 'yes' places the step behind an approval boundary.
- Reversibility — if this is wrong, can it be undone before it has an effect outside the organization?
- Discovery — would the error be noticed first by someone outside the organization rather than inside it?
- Authority — is this an exercise of a person's or entity's authority, such as a commitment, a signature, a price or a permission?
- Defensibility — will someone need to explain the reasoning to a regulator, counterparty, investor or court?
Why capability is absent from the test
None of the four questions asks how accurate the model is. A more accurate model reduces how often the boundary is exercised; it does not change who is accountable when it is.
Five decision classes that keep a named approver
| Intelligence may | Intelligence may not | Why | |
|---|---|---|---|
| Commitments to another party | Draft the terms, assemble the evidence, flag deviations from precedent | Issue, sign, send or amend the commitment | It binds the organization and cannot be quietly reversed |
| Money movement and pricing | Reconcile, calculate, prepare and explain the figure | Release the payment or publish the price | Irreversible and externally discovered |
| Permanent exclusions | Rank, screen, annotate and recommend rejection with reasons | Permanently remove an opportunity, applicant or record from the pipeline | A wrong exclusion is invisible; nobody audits what was never seen |
| Statements of fact about the business | Assemble the report, cite the source records, highlight variances | Publish it to investors, clients or regulators | Reliance is placed on it and it must be defensible |
| Access, permission and identity | Detect anomalies, propose changes, prepare the request | Grant, escalate or revoke access | It changes who else can act, compounding any error |
Encoding a boundary so it holds
A boundary written in a policy document and not in the system is a statement of intent. AEGIS treats a boundary as five concrete artefacts, all of which must exist before a role goes live.
Anatomy of an enforced approval boundary
- 01A named approver — a role held by a person, never a distribution list.
- 02A held state — the work waits in a defined status and cannot proceed without the decision.
- 03A decision record — who approved, when, on what version, with what changes.
- 04An expiry — an unapproved item escalates rather than sitting indefinitely.
- 05A review signal — the approver's edit rate, tracked, so the boundary can be narrowed or widened from evidence.
The fifth artefact is the one usually missing. Without an edit rate, an organization cannot tell whether the reviewer is genuinely reviewing or has become a button. A boundary nobody exercises is theatre, and it is more dangerous than no boundary at all because it implies scrutiny that is not happening.
When a boundary may be relaxed
- Never for the five classes above. Those are permanent.
- For other steps, only with recorded evidence: a sustained period of review with a low edit rate on a representative volume of real work.
- Only narrowly — relax the specific condition that proved reliable, not the whole step.
- Only reversibly — with the monitoring that would show the assumption breaking, and a defined trigger to reinstate it.
Sources and references
- AEGIS AI Use Policy — Published governance position. Align the five classes with its wording.
- AI Workforce page — Published approval-boundary examples per role — keep terminology identical.
Reviewed and published. The five decision classes reflect AEGIS implementation practice. No client example, sector reference or figure is described.
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
Human Approval Architecture
Designing approval boundaries so intelligence can draft, prepare and route work while people stay accountable for decisions.
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.