INSIGHTS / AI GOVERNANCE + HUMAN AUTHORITY
ARTICLE 04
Automation, AI, and
Capability tells you what a system can do. Authority defines what it may do, under which conditions, using which evidence, and who remains responsible when the consequence becomes real.
Explore the authority boundary ← Back to Insights
Execution proceeds inside a defined mandate.
Movement stops when permission or evidence is insufficient.
The work preserves context and routes to a named owner.
01 / CAN VERSUS MAY
Capability describes the possible. Authority defines the permitted.
A tool, automation, or AI system may be technically capable of sending a message, changing a record, routing a request, generating a document, updating a status, deleting data, or committing a decision. That list describes access and function. It does not describe mandate.
Authority begins with a different set of questions.
- Should the action happen under these conditions?
- Whose authority does it use?
- What evidence supports it?
- What boundary limits it?
- If the result is wrong, who can see the failure and recover the work?
THE AUTHORITY CHECK
From possible to permitted.
Capability enters the check. The current authority boundary determines the outcome.
The evaluated boundary makes an outcome route available.
Outcome
- State
- What is true now?
- Consequence
- What would this action commit?
- Permission
- What mandate applies here?
- Evidence
- What supports this action?
- Owner
- Who holds the decision?
- Recovery
- Who can see and correct failure?
Bounded movement uses existing permission; the system cannot extend its own mandate.
A reading model, not a universal decision algorithm. An approval still authorizes only its defined action.
02 / CAPABILITY AND ACCESS
Capability describes the possible.
This distinction matters because capability tends to expand faster than operating permission. A new integration can expose another action. A more capable model can interpret more context. Neither development silently changes the commercial, financial, legal, or customer authority of the system.
Access enables an action. Authority legitimizes it.
Good control therefore treats authority as an explicit part of system design. It is attached to a state, a type of decision, a consequence boundary, and a recovery path—not inferred from what the technology happens to support.
Capability answers can; authority answers may. Access is not mandate, and reversibility is not permission.
03 / START WITH CONSEQUENCE
Before asking how smart the system is, ask what happens when it is wrong.
The right authority boundary begins with consequence. A formatting error in an internal draft does not carry the same weight as an incorrect customer commitment, an unauthorized scope change, a financial movement, a security decision, or an irreversible deletion.
These are not universal risk tiers. They are prompts for examining the real operation. A low-consequence, reversible movement may tolerate automatic execution with monitoring. Customer-facing communication may require tighter rules or review because the recipient will treat it as the business speaking. Commercial, financial, security, data, legal, and contractual actions may each require named approval based on the organization's actual obligations.
Examine the whole consequence.
Contextual prompts, not numbered risk tiers.
Reversible does not mean permitted. Define the mandate and whether recovery creates another obligation.
Reversibility is part of this judgment, but it is not a universal permission slip. Reversing a record may be easy while reversing the customer's expectation is not. Judge the whole consequence, then set authority proportionately.
Data sensitivity and access boundaries belong in that judgment. Read our security approach and privacy policy for the relevant project and website context.
04 / WHERE AUTOMATION MAY ACT
Let the system act where movement is bounded, legible, and recoverable.
Automatic action belongs in territory where the trigger is clear, required input is known, the current state is valid, and the rule for movement is deterministic. Permission should be narrow enough that the system cannot quietly extend its own mandate.
Good candidates often include routing, synchronizing, formatting, storing, notifying, creating internal tasks, or moving known data between approved states. These are general examples, not declarations that every instance is safe. A notification can still disclose protected information. A synchronization can still overwrite authoritative data. The local consequence decides the boundary.
- Input / stateClear trigger
- Input / stateKnown input
- Input / stateValid state
- Rule / authorityDeterministic rule
- Rule / authorityBounded permission
- Consequence / evidenceLow or reversible consequence
- Consequence / evidenceAuditable result
- Failure pathDefined failure path
Automatic execution requires all eight conditions to hold together.
A controlled AI automation system does not merely know the happy path. It records what it did, detects when the conditions no longer hold, and moves the work into a safe state instead of improvising beyond authority.
05 / WHERE AI MAY ASSIST
Assistance can create value without transferring the final decision.
Many useful applications of automation and AI sit between manual work and autonomous action. A system can summarize a record, classify a request, extract facts, compare options, draft a response, prepare evidence, identify an anomaly, or suggest the next action while a person retains authority.
This is not automation falling short. It is often the correct control design. Preparation can be repeated and accelerated without pretending that the final judgment is deterministic or that the system owns the consequence.
Prepare the work. Preserve the decision.
AI assistance carries evidence to a person who holds authority; it does not inherit that authority.
PREPARATION → AUTHORITY
Held at human authority. Preparation cannot authorize action.
- Approved records and current state
- System observes
- Summarize · compare · draft · prepare
- Present evidence
- Review evidence and exercise authorityAuthorized person decides
- Permitted action
- Result recorded
Prepared work waits here. A named person holds the decision.
Conceptual sequence; no real approval or business action occurs.The handoff must make the distinction visible. Label drafts as drafts. Show the evidence behind a recommendation. Keep the current state and proposed action separate. The person should know what the system observed, what it inferred, and what decision is now being requested.
A draft is not a decision. A recommendation is not authorization. High confidence is not mandate. Assistance does not transfer ownership of consequence.
06 / ESCALATION IS A STATE
Escalation is an operating state, not an error message.
A controlled system should know when its conditions are insufficient. Missing input, conflicting records, low confidence, an unknown condition, policy conflict, unusual request, scope change, failed integration, customer dispute, or consequence above the approved boundary can each trigger escalation.
The important design move is to preserve the work when it stops. “Could not complete” is not a usable handoff. The escalation should retain the work item, current state, relevant context, available evidence, reason for stopping, new owner, and the decision required.
- Work item The subject of the decision stays unambiguous.
- Current state The operation can see where movement stopped.
- Context and evidence The next owner can verify what is known.
- Stop reason The failed condition or crossed boundary is explicit.
- Named owner Responsibility transfers instead of dispersing.
- Required decision The route back to movement or closure is defined.
This is where the visible workflow becomes essential without needing to be mapped again. Escalation changes state and ownership. The resolved decision must return to a known point, with its evidence attached, so the operation can resume or close honestly.
A security concern or insufficient evidence can also require a controlled stop. A resolved decision may return the item for more information before movement or closure.
Keep the work intact when conditions fail.
Stopping is correct operation when permission or evidence is insufficient. Resume only at a defined state, with authority and evidence attached.
STOP → PRESERVE → OWNER
Movement stopped. The work and evidence remain attached.
- Normal state
- Condition fails
- Stop
- Preserve context
- Assign owner
- Required decision
- Resume / return / close
Condition failed. Movement has stopped; the work is retained.
Conceptual sequence; a real decision requires an explicitly authorized owner.07 / NAME HUMAN AUTHORITY
“Human in the loop” means little until the human and the decision are named.
Human authority should be designed with the same precision as automated movement. Which person or role acts at this state? What exactly are they deciding? Which information must they receive? What authority do they hold? What follows approval, rejection, or a request for more evidence?
Several responsibilities are often compressed into one vague review step.
- examines the work.
- authorizes a defined action.
- changes the normal rule under explicit mandate.
- accepts responsibility for a stopped item.
- decides how that item returns, changes, or closes.
Examine the work and evidence; review alone does not authorize the action.
A checkbox beside an unnamed role is not governance. A useful approval gate records the person, decision, evidence, time, and resulting state. In more contextual agentic systems , this explicit mandate is what prevents flexible reasoning from becoming undefined authority.
A meaningful approval gate presents the proposed action, decision requested, evidence, consequence, and approving person or role. Record the time, outcome, and resulting state. Review alone does not authorize action.
08 / CONFIDENCE AND PERMISSION
Confidence can change the route. It cannot grant permission.
Confidence is useful when it reflects something meaningful about an interpretation. Low confidence may tell the system to request information, present alternatives, or escalate. It can be one signal in deciding whether the conditions for action are present.
High confidence does not override permissions, policy, customer commitments, commercial authority, legal authority, security boundaries, or defined approval gates. A system can be very certain about an action it is not allowed to take. It can also be confidently wrong because the source is incomplete, the condition is novel, or the measured confidence does not match the real decision.
Treat confidence as an input with a defined consequence. Below one boundary, stop or ask. Within another, assist and expose uncertainty. Only allow action when every other authority condition also holds. Confidence belongs inside the control system; it is not the control system.
The route changes. The boundary stays.
Confidence can influence routing. It does not create authority.
Uncertainty may require another route.
09 / AUTHORITY BEFORE AUTONOMY
Design the authority boundary before increasing autonomy.
Once the workflow is visible, examine each consequential state rather than asking for one autonomy level across the entire process. The same system may route a complete intake automatically, draft a contextual response for review, escalate a scope change, and wait for human approval before making a commitment.
For each state, make the boundary answerable:
A design surface for one workflow state—not a completed assessment.
- Movement
- Authority
- Control
Name the automatic action and its exact permitted state.
This produces a more useful conversation than “How autonomous can it be?” It connects capability to consequence, evidence to permission, and every stop to an owner. Our delivery method uses those boundaries to keep implementation aligned with the real operation.
Structure makes controlled execution possible. Workflow makes the real movement visible. Authority decides who—or what—may move it next.
Six coordinates of authority.
State · consequence · evidence · permission · owner · recovery
Delegated authority must name the actor, permitted action, and boundary. Least privilege limits access to the work required. Define approval expiry so changed conditions require a new decision. Override traceability records who changed the normal rule, under which mandate, and why. Explicit stop conditions protect a controlled stop state; recovery and decision recording make the next movement answerable.
The goal is not maximum autonomy. It is the right authority, held by the right actor, at the state where the consequence becomes real.