Governance
Approval is not a form
Control over an autonomous system works when it is a property of each action, set by what that action costs to get wrong, rather than a single gate placed around the whole system.
Governance in Atlas is not a gate around the system. It is a property of every individual action the system can take. Each class of action carries its own boundary, and that boundary is set by three things about the action itself: whether it can be undone, what it costs if it is wrong, and how far it reaches.
Those three answers decide whether an action runs on its own, runs after a named person approves it, or never runs without a person at all. Permissions, approvals and the record are part of the foundation every Atlas deployment is built on, and no deployment can switch them off.
A gate around the system fails in both directions
The usual way to govern automation is a switch. Either the system asks for approval before it acts, or it does not. It is simple to explain and simple to audit, and it fails in two predictable ways.
Set the switch to approve everything and the system produces a queue. Within a few weeks the people working that queue are approving dozens of routine actions a day, and they stop reading them. A click that approves an invoice correction looks exactly like a click that approves a contractual statement to a customer. The first time something serious goes through, the record shows that a person approved it, and nobody in the room believes that the person actually looked.
That is worse than having no approval at all. An approval nobody reads is not control. It is a record of control that did not happen, and it moves the responsibility onto the one person least able to have caught the mistake.
Set the switch the other way and the system acts freely on everything, including the handful of actions nobody would ever have delegated if they had been asked one at a time. Most organisations discover this the day after, and then turn the switch back, and then nobody uses the system.
Both failures have the same cause. One setting is being asked to govern actions that have nothing in common except that the same system performs them.
Three properties of an action decide how far it goes alone
Can it be undone
Correcting a field in an internal record can be reversed in seconds. A message sent to a customer cannot be unsent. A payment released cannot be recalled without cost. Reversibility comes first because it decides whether a mistake is an inconvenience or an event.
What does it cost if it is wrong
Some errors cost a few minutes of somebody’s attention. Some cost a customer relationship. Some cost money, and some create legal exposure. The cost of the error rather than its likelihood sets the ceiling on how much autonomy an action may have, because a rare expensive mistake is exactly the kind a confidence score underestimates.
How far does it reach
An action that touches one internal record stays inside the company. An action that reaches a customer, a supplier, a bank or a regulator leaves it. Once something has left, it is represented by the company whether or not anybody meant it to be.
Put the three together and the classes almost draw themselves.
Reading a record in a connected system, and preparing work: a draft document, a message, an analysis, a proposed decision. Reversible, cheap if wrong, and still inside the company. These run, and they are logged.
Writing back to a system that owns a fact, and anything that goes to a customer, a supplier or an authority. Harder to reverse, and represented by the company once it has gone. These wait for a named person.
Deletion, payment, anything with no reversal path, and any attempt by the system to widen its own access. Alongside them sits a fixed list that no rule a customer writes can delegate: price commitments, discounts, contractual statements, complaints, data protection requests, anything that mentions a lawyer. These never run alone, whatever the confidence and whatever the configuration.
The value of the grid is not that it is complicated. It is that it is legible. Anybody in the company can take a class of action, answer three questions about it, and predict what the system will do. Where each boundary sits by default is written down and visible; where it sits in a given deployment is a decision that company makes.
Approval is a record, not a click
An approval in Atlas is stored as a record of a decision rather than as the fact that a button was pressed.
It holds what ran, on whose authority, against which context and what it changed, and it holds the reasoning the decision was taken on rather than only the outcome. That makes one question answerable afterwards, which is the only question that matters once something has gone wrong: was this action permitted at the moment it was taken, given what was known at that moment.
Two rules sit underneath. A check that cannot be completed is a refusal, never a permission: where the authority behind an action cannot be established, because a directory is unreachable or a rule cannot be evaluated, the action stops rather than proceeds. The failure mode of the governance layer is to do nothing, which is a deliberate trade of availability for control.
And the logging is complete rather than selective, which means it covers the decisions that allowed an action and not only the ones that stopped it. Most of those entries will never be read. The ones that are will be read at the worst possible moment, by somebody who needs them to be complete.
Control that cannot be widened is not caution, it is a ceiling.
Autonomy widens per class, not per system
Because control sits on each class of action, autonomy can grow the same way.
A system does not become trustworthy all at once. It becomes trustworthy at routing requests long before it becomes trustworthy at drafting replies, and at drafting replies long before it becomes trustworthy at sending them. Each class can move separately, when the record shows that the system gets that kind of decision right and that its reasoning can be checked.
What moves is where the approval sits rather than whether there is one. Approval can move from every instance to the edge of a class, so that what sits inside the class runs and the exceptions escalate. Anything that leaves the company is drafted and reviewed, with a person in the loop by policy rather than by exception. How that widening is tuned for one product, per intent rather than globally, is the subject of a separate piece on Signal.
The company decides how far this goes. Atlas makes sure it can always see where the line currently is, and always move it back.
The objection worth taking seriously
This is more work than a switch. Somebody has to go through the classes of action a system can take and answer three questions about each of them, and a small company with a handful of processes might reasonably feel that a single approval step is enough to start with.
That is fair, and for a narrow first deployment it may even be true. The honest answer is that the classification is not additional work so much as work that was always being done implicitly, by whoever happened to be approving things that day. Writing it down once is cheaper than rediscovering it after each incident, and it is the only way the answer survives the person who knew it leaving the company.
Why control is not the brake
A system governed by a switch can only ever be trusted as much as its most dangerous action. Every other capability stays capped at that level, permanently, because there is no way to widen autonomy for the safe actions without also widening it for the unsafe ones.
A system governed per class has no such ceiling. Each kind of work can be handed over when it has earned it, and the evidence for that sits in the record rather than in somebody’s impression. Control built this way is not what limits how much a company can hand to its systems. It is what allows it to hand over more.
The mechanism this piece argues for, as it is actually built: where each class of action sits by default, what a person sees before approving, and what the record keeps afterwards.