Photo by James Peacock on Unsplash

Most of my recent writing has made some version of the same argument.

Organizations repeatedly pay for things they declined to define once. An undocumented exception becomes maintenance work for everyone who inherits it. A policy outlives the conditions that made it correct because the rule was preserved and its boundary was not. A definition that means one thing in Finance and something adjacent in Operations becomes reconciliation every time the number crosses between them. Ambiguous work handed to AI does not stop being ambiguous; the ambiguity simply moves into context windows, prompts, retries, and operating expense.

The pattern is real, and I still believe the conclusion that usually follows from it.

Make the implicit explicit. Preserve the reasoning. Define the boundary. Build the process so that the next person does not have to reconstruct what the last person already knew.

There is a seductively short distance from that argument to another one, though, and I have become increasingly uncomfortable with crossing it without looking.

If undefined work is expensive, then defined work must be better. Similarly, if repeated judgment is costly, encode the judgment. If a person is making the same decision every week, turn the decision into a rule and let the system make it instead.

Often, that is exactly right. Often, but not always.

And after spending this much time arguing for the value of making hidden structure visible, it would be irresponsible not to spend some time on the other side: the cases where formalization removes something the system still needs.

I have one of those cases in front of me whenever somebody asks for access to a system.

The obvious architecture is simple. We know who the person is. We know their department, title, manager, location, employment status, and organizational position. We know which access roles people in similar jobs usually receive.

So map one to the other.

If you are in role X, grant permissions A, B, and C. If you move to role Y, remove them and grant D and E. Let identity drive entitlement automatically, eliminate the queue, remove the approval delay, and call the result mature.

I have had opportunities to build exactly that. And in some of those cases, I have chosen not to.

The question is why anyone responsible for automation would deliberately preserve a delay they already know how to remove.

The Workflow Says Approval

Draw the process from far enough away and the answer looks embarrassing: Someone needs access, so they submit a request, and another person reviews it. If approved, the access is provisioned.

Three steps, with a human bottleneck sitting inconveniently in the middle. The automation case almost writes itself.

The employee’s attributes are already known. The relationship between role and expected access can be modeled; most requests are predictable. Human approvers take time, create variance, go on vacation, miss notifications, and occasionally disagree with one another about cases that appear identical.

Sometimes they fail in more ordinary ways.

Some managers simply do not pay much attention to the alerts. Requests wait until they expire while the person who needs the access waits with them.

Others see the blocked work much more clearly than the authority being requested. To them, the request is not primarily Should this person have this permission? It is Someone cannot complete a task until I click this button.

The blocked work is immediate and visible. The risk created by additional authority is usually neither.

So they approve. Then approve the next one. And the one after that. Eventually the approval exists mainly to ensure that the workflow never stops.

No system can force an approver to exercise diligence. A notification cannot create curiosity. A required checkbox cannot guarantee scrutiny. A workflow engine can place a human in the chain, but it cannot make that human think.

That is a serious argument for automation. If the same request will be approved every time anyway, why preserve the delay?

If an approver receives the same request three hundred times, approves it three hundred times, asks no questions, communicates nothing, and could have predicted every answer from fields already present in the request, there is no judgment left in the workflow.

The person is not a control. They are latency.

Automate it.

But the mistake is assuming that every workflow shaped like this one contains the same thing, because provisioning is not necessarily the whole output of an access request.

Sometimes the decision is hiding inside the delay.

That does not make the delay free, or even justified. It means only that before removing it, we should know what else disappears with it.

The Normal Case Is Not the Actual Case

Role-based access works by classification, and people who share organizational attributes tend to share requirements. An accountant probably needs access to accounting systems, just as an analyst probably needs reporting tools, and someone supporting a particular region probably needs the data associated with that region.

This is useful because organizations cannot govern every routine decision as though nothing has ever happened before. The whole purpose of a role is compression. It takes a large number of recurring decisions and says: for people like this, under ordinary conditions, we have already decided.

But the compression is lossy, and organizations do not actually operate according to the neat borders of their org charts.

What happens when a Finance employee joins an acquisition integration for six months, or an analyst begins supporting a warehouse implementation? What if someone in Operations becomes the subject-matter expert for a reporting platform owned elsewhere, or a project requires a person to cross a boundary their title never anticipated?

Their organizational role has not changed, but their legitimate need has.

That means an automatic entitlement model now has a problem. It can reject the access because people with that title do not normally receive it, or it can expand the base role so everyone with that title receives something only one person requires.

Or it can begin encoding exceptions until the once-clean relationship between identity and authority becomes a second organizational model, maintained in parallel with the organization itself.

Or a human approver can do something much simpler: They can say yes, because the work this person is doing now justifies it.

That distinction is small enough to disappear in an architecture diagram and important enough to determine whether the architecture fits reality at all.

A job title describes the normal case, but a permission system has to govern the actual one.

Authority Is Not an Attribute

This points to a category error underneath some approaches to access automation.

Identity attributes describe a person in terms of their department, position, location, status, and manager.

Authority, on the other hand, describes a relationship between that person and something they are permitted to do.

Those are not quite the same kind of fact.

Knowing that someone works in Finance tells me a great deal about what access they are likely to need. It does not tell me everything they may legitimately need under every condition in which the organization might place them.

The distinction becomes clearer if we separate three questions that are often compressed into one.

• Identity asks: who are you?
• Entitlement asks: what do people like you normally receive?
• Authorization asks: are you allowed to do this here, now, under these circumstances?

All three can be automated.

But authorization can only be automated safely when the facts necessary to make the decision are representable in the system. The danger begins when we mistake the facts we have modeled for all the facts that matter.

A system may know the person’s role, project assignment, training status, current privileges, resource classification, and location. In many cases, that is enough; in others, the relevant context exists precisely because the request is unusual.

That confidence should be earned rather than assumed.

Formalization is leverage when the thing being formalized is sufficiently stable to deserve it. When it is not, the architecture can become exceptionally good at enforcing an incomplete understanding.

The system gets cleaner, but reality does not.

The Request Creates Information

There is another property of the manual request that is easier to miss because it does not appear in the permission object at all: the request itself tells you something.

Someone asking for access outside the normal pattern may mean that a new project has crossed an organizational boundary, or that a person’s responsibilities have changed faster than HR classifications did.

It may mean a dataset built for one group has become useful to another, or expose an emerging dependency between teams that no architecture diagram currently records.

And if the same atypical access is requested repeatedly, the exception starts becoming evidence that the standard itself may be wrong.

One deviation is a case – ten similar deviations are information about the rule.

Automatic provisioning can erase that signal by making the event ordinary before anyone has had the opportunity to notice that it became routine.

This is a strange property of friction: sometimes friction generates information.

We tend to evaluate a request by asking how quickly it travels through the system. But the requirement to request something can itself be an instrument: a point at which demand becomes visible.

An exception that has to be requested remains observable. An exception granted automatically can become ordinary before anyone notices that the standard changed underneath it.

None of this requires that every request remain manually approved. The request and the decision are separate architectural choices.

Automation can improve execution while degrading sensing. Sometimes that trade is still worth making.

Someone Knows

There is a second output: an approval creates awareness somewhere.

When access is automatically assigned because a policy matched an attribute, the system knows why the permission exists, and the log is perfectly capable of saying so: Role assigned because user matched rule X.

That is valuable evidence, but it is not the same as a person knowing that this particular user holds this particular authority for this particular reason.

A meaningful approval places awareness somewhere, and in the best systems, answerability with it.

That distinction matters precisely because human approval is imperfect.

An approver may ignore a request until it expires, or they may approve it without reading. They may decide, consciously or otherwise, that avoiding a blocked task matters more than evaluating the risk represented by additional authority.

A system cannot force diligence; that is part of why accountability matters.

Accountability does not guarantee that someone will make a good decision. It makes the decision attributable when they do not. A well-designed approval process can preserve who approved the request, what information was available, what justification was offered, what authority was granted, and under what conditions.

If the decision was careless, the explanation cannot simply be that the workflow passed. Someone made the decision. Someone can be asked about it. It does not create a perfect control. It deliberately places responsibility.

A human in the workflow is not a control – a human making a decision is.

And a system that preserves human judgment should also preserve who was responsible for exercising it.

The Conversation Is Part of the Boundary

An access request also creates a moment that automatic entitlement assignment usually does not.

The person is about to receive authority they did not have before, which is an unusually good time to say something.

But not everything said at that moment needs a human. If every requester should see the same policy, show it automatically. If everyone receiving a role should acknowledge the same handling requirement, collect that acknowledgment automatically. If the same warning belongs on every request, it is content, not conversation.

In short, if it happens every time – automate it.

The human interaction earns its place when what needs to be said depends on why the authority is being granted.

A temporary project may carry conditions that do not apply to permanent access. An unusual data request may cross a boundary the requester does not normally encounter. Elevated access, similarly, may require clarifying not only what the person can do, but what they are expected not to do even though the system technically permits it.

None of those things changes the security role, but the state of the system includes the behavior of the person using it.

Before the interaction, someone needs access. After a good one, someone has access, understands why they have it, understands the conditions attached to it, and knows that another person is aware of the grant.

The permission object may be identical either way; the operating state is not.

Sometimes the moment authority changes hands is itself part of the boundary.

Not Every Human Step Deserves to Survive

There is an obvious danger in this argument: organizations are exceptionally good at inventing noble explanations for processes nobody has had the courage to remove.

Call a delay governance and it can survive for years.

Call an approval accountability and no one has to ask whether the approver remembers clicking it.

Call a form an information-gathering interface and suddenly twelve required fields become evidence of maturity.

None of this follows automatically.

Human judgment is expensive, but cost does not guarantee quality.

It creates queues, introduces inconsistency, and depends on availability. It can carry bias or become a passive ritual. Beyond a certain volume, even excellent approvers stop investigating every request deeply enough for the word judgment to remain honest.

So before preserving a human checkpoint, I would ask five questions.

Is judgment actually occurring?
Could two reasonable people reach different answers because context changes? If every responsible approver should reach the same answer from information the system already possesses, encode the answer.

Does accountability meaningfully change?
Is someone answerable for allowing the action, or are they merely supplying a name for the audit record?

Does the interaction generate useful information?
Would seeing the request reveal an exception, a changing responsibility, an emerging dependency, or evidence that the current standard should be revised?

Does the interaction change behavior?
Is there something contextual about the grant that should materially affect what the requester understands or does afterward?

And finally: Is all of that worth what the decision costs?

A ten-minute decision made ten thousand times is not free, just as a three-day approval delay imposed on routine work is not justified by the possibility that one request in a thousand might be different.

Human judgment does not become valuable merely by being human.

The better question is whether the value exceeds the cost of continuing to carry it.

Automate Around the Decision

This leaves us somewhere more useful than the choice between manual and automated, and the better architecture separates judgment from execution.

A person does not need to provision the role manually merely because a person should decide whether the role is appropriate.

The system can collect the request, identify the requester, and show the approver the person’s existing privileges, organizational position, project context, training status, previous exceptions, and the risk associated with what is being requested.

• It can detect unusual combinations and route the request to the correct accountable owner.
• It can escalate requests that are about to expire rather than allowing silence to become an accidental denial.
• It can present generic policy material automatically and reserve human attention for the parts that depend on context.
• It can record the rationale, provision the approved resources immediately, set expiration conditions, and send notifications.

And it can observe the approval process itself.

• Which approvers approve nearly everything?
• Which requests routinely expire?
• Where are decisions consistently delayed?
• Which exceptions occur often enough that they should no longer be exceptions?

No system can force a human being to exercise judgment. It can, however, make the absence of that judgment visible; human discretion should not mean invisible discretion.

That is the architecture I find more interesting now: automation as the concentration of judgment rather than the subtraction of people.

Remove the searching, routing, copying, provisioning, reminding, documenting, and chasing so that the scarce human attention left in the process can be spent on the thing for which it was retained.

A system designed this way does not eliminate judgment; it makes judgment cheaper to exercise, harder to ignore, and harder to lose.

The Decisions We Should Keep

I still believe organizations pay an enormous tax for failing to formalize what they already understand. Definitions should not have to be renegotiated every time they cross a department, and stable exception logic should not live indefinitely in one person’s memory.

A recurring decision whose answer stopped varying years ago should not continue consuming human attention because nobody ever encoded what everyone already knows.

There is tremendous leverage in turning repeated judgment into durable structure, but there is a boundary to that argument.

Not every recurring human interaction is evidence of unfinished automation. Some are places where context enters the system, while others are where unusual demand becomes visible, and yet others attach responsibility to authority.

Some should remain decisions precisely because the world around them has not become stable enough for the answer to be safely decided in advance.

And none of that excuses a human process that does not work. An approval that expires unread is not governance, just as a manager who approves everything to avoid blocking work is not exercising meaningful scrutiny.

A process that depends on human judgment has to be designed around the uncomfortable fact that humans may decline to provide it.

The answer is not necessarily to eliminate the decision, but it may be to make the decision easier to make well, harder to ignore, and impossible to make invisibly.

That is the distinction I would put in front of any automation effort.

Do not ask only whether the human can be removed; ask what disappears with them.