Introduction
An accounts payable manager opens the finance system on a Tuesday morning and finds that several supplier payments have already moved through the pipeline overnight. Credit checks ran. Invoice amounts were reconciled. Approvals cleared. No one worked late. An AI agent, triggered by an incoming event, executed the sequence on its own.
The processing was correct. The problem sits elsewhere. Ask who decided to release those payments, and no one can give a clean answer. The log names the agent as the executor. That is not the same as naming who held the judgment.
For most of the enterprise software era, one assumption held quietly underneath every audit trail: every action on a system eventually traces back to a human login. That assumption is now breaking. Autonomous AI agents act on events, not on sign-ins, and they resolve business questions before any person is in the room. This article argues that the enterprise response to this shift has focused on the wrong layer. Governance controls what happens after judgment occurs. The harder and more neglected question is who should legitimately hold judgment authority in the first place. That question leads to a discipline this article calls Decision Design™.
The Hidden Assumption Inside ERP Governance
On July 2, 2026, ERPSoftwareBlog, a partner-oriented publication in the Microsoft Dynamics ecosystem, ran an article by DAX Software Solutions, a Dynamics consulting firm. The argument was direct. Autonomous AI agents are entering core ERP functions faster than governance can keep pace.
The piece describes a concrete situation. On platforms such as Dynamics 365, agents can now run bank account verification, accounts payable processing, inventory management, and service-case routing. They trigger on events rather than on a human logging in. Because of that, the authors argue, controls such as audit logs, approval thresholds, scoped permissions, behavioral monitoring, and rollback should be designed before deployment rather than bolted on afterward. Left unmanaged, they warn, decisions that were never built to be reviewed will accumulate in a form that cannot be reviewed.
One qualification matters. This is not independent reporting, and it is not a standards-body document. A vendor that sells governance tooling wrote it. Read it with that interest in mind. Even so, the structure it describes fits a wide range of enterprises, and the underlying pattern deserves closer examination than a vendor checklist usually receives.
What the ERP Debate Actually Reveals
On the surface, the article is a control checklist: build audit logs, define approval flows, scope permissions. The specific items are useful. Audit logs that capture not only outcomes but the reasoning path that led to them. Approval thresholds tied to transaction size and reversibility. Permissions narrowed to each agent's function. Monitoring that watches for drift in behavior after deployment. Rollback that can unwind a chained sequence of actions.
Line those five controls up and a pattern appears. Every one of them governs what happens after a judgment has already been made. Record it. Halt it. Reverse it. In each case the judgment itself is finished before the control engages.
That leaves a gap the vocabulary of control cannot close. Accountability, audit, approval, permission: refine all four as carefully as you like, and a space remains. The gap is not a missing control. It is a missing question. None of these mechanisms decides whether a given judgment should have belonged to a human or to an agent at all. They assume that allocation was settled somewhere upstream, and they operate on whatever the allocation produced.
Why This Is No Longer an ERP Problem
The same structure appears far outside ERP.
A customer-support agent decides, in the moment, whether to authorize a refund. A procurement agent reads inventory levels and places a replenishment order. A cybersecurity agent detects suspicious traffic and cuts the connection. A hiring-support tool screens and narrows a candidate pool. A contract-review agent flags clauses and clears low-risk agreements. In each case, judgment proceeds from an event, without a human login, and the same question surfaces at every site: who decided this?
Regulators have begun to treat that question as central. The Japanese government asks developers of autonomous AI agents to build in mechanisms that ensure meaningful human judgment, given risks such as malfunction and privacy violation. The same reasoning appears in Japan's AI Guidelines for Business Ver1.2, published jointly by the Ministry of Internal Affairs and Communications and the Ministry of Economy, Trade and Industry. The direction is consistent with the wider policy landscape, where high-risk-system obligations and requirements for per-agent identifiers and auditability point the same way: human judgment has to be preserved somewhere in the process.
Notice what these mandates settle and what they leave open. They settle that human judgment must exist somewhere. They do not settle where. A requirement to keep a human in the loop does not specify which loop, or at which point in a workflow the human's judgment attaches. The place where a person intervenes is itself a design object. Drawing that line, deciding where legitimate human judgment begins and where it can be delegated, is the question no mandate answers for you.
Governance Is Necessary—but No Longer Sufficient
Governance handles the aftermath of judgment. It records, inserts approval gates, watches for deviation, and reverses when needed. These functions are necessary. In an environment of autonomous agents, they are also non-negotiable.
Governance does not answer whether a given judgment should have been delegated. An approval flow is a gate placed after someone decided to delegate. An audit log is a record kept after the delegation happened. Both presuppose that a boundary already exists between what the agent may decide and what a human retains. Drawing that boundary sits outside governance entirely. This is the precise sense in which governance is necessary but no longer sufficient: it is complete as a discipline for managing decisions after authority has been allocated, and silent on the allocation itself.
Three neighboring disciplines share the same blind spot, and it is worth naming why each falls short before turning to what fills the gap.
Digital transformation moves work onto digital rails and connects it with data. Processes accelerate and information flows. What digital transformation optimizes is throughput: how to make the work run. It does not ask which judgments a human should retain. In practice it tends to treat any step that contains a judgment as one more candidate for automation. Seen through an efficiency lens, judgment is just part of a process. The idea that judgment deserves separate treatment, and that its placement should be designed, is not part of the transformation agenda.
Automation is the technology that carries out delegated judgment. Write the rules, build the model, let the agent execute. Automation answers how to delegate. It does not answer how far to delegate. Almost any judgment can be automated in technical terms. That something can be automated does not establish that it should be. The line between "can be delegated" and "should be delegated" is not automation's job to draw.
AI ethics asks what judgment ought to look like: whether it is fair, explainable, and consistent with human dignity. These principles are indispensable. Yet a principle names a value; it does not locate a boundary in a workflow. "Preserve meaningful human involvement" is correct as a principle and underdetermined as an instruction. Whether that involvement attaches to the refund decision, the replenishment order, or the network-isolation call does not follow from the principle. The specific placement has to be chosen.
Four disciplines, one shared silence. Governance manages the aftermath, digital transformation manages the flow, automation manages the delegation mechanism, and AI ethics manages the principles. None of them owns the act of deliberately placing the line between human and agent judgment. That unassigned act is what the opening scene exposes, and it is what Decision Design™ addresses.
Decision Design
The earlier sections described a gap with no name. Decision Design™ is the name.
Fix the definition first and hold it fixed. Decision Design™ is the deliberate design of decision allocation itself: which judgments a human holds, which an agent holds, and under what conditions authority moves between them. The sections that follow restate this from three angles without paraphrasing it, because this concept loses its edge every time it is reworded. The value of repeating the same structure is precision, not emphasis.
Stated as a principle: Decision Design is not about improving decisions alone; it is about designing the authority structure within which decisions become institutionally legitimate.
What Decision Design™ designs
Decision Design™ designs the allocation of judgment. Inside any given workflow there are usually several distinct judgments. For each one, Decision Design™ specifies whether a human makes it, an agent makes it, or an agent makes it under stated conditions with a human retaining the rest. This act of assigning judgment to a holder is what the discipline calls Authority Allocation. The object of design is not the record of a decision and not the procedure for approving it. The object is the assignment: whose judgment this is.
What Decision Design™ is NOT
Decision Design™ is not the construction of audit logs. It is not the design of approval flows. It is not permission management. Each of those operates after a judgment, or around its edges. Decision Design™ sits one step earlier than all of them. It is the layer that determines whether a judgment should be delegated at all. Governance tooling assumes that determination has been made; Decision Design™ is the discipline that makes it.
What problem Decision Design™ solves
The problem Decision Design™ solves is that decision allocation gets set by default when no one designs it. A judgment was delegated because the tool happened to support it. A task was automated because the team happened to be short-staffed. Lines drawn this way are not designed; they are inherited from circumstance. Decision Design™ replaces the line drawn by accident with a line drawn on purpose, and it makes that line an explicit, defensible object of Institutional Governance rather than a byproduct of tooling and headcount.
Decision Boundaries
The central instrument of Decision Design™ is the Decision Boundary™. A Decision Boundary™ separates what an agent is authorized to decide from what a human retains, within a specific workflow. These are the Governance Decision Boundaries an organization must set deliberately.
Be exact about what a Decision Boundary™ is not. A Decision Boundary™ is not an approval workflow; an approval workflow is a gate placed after the choice to delegate has already been made. A Decision Boundary™ is not an operational threshold in the sense of a routine processing rule. Stated as a principle: Decision Boundaries are not operational thresholds; they are institutional demarcations of legitimate authority. A Decision Boundary™ defines where legitimate judgment authority begins, where it ends, where it transfers from human to agent, and where a human reclaims it.
Boundaries rarely come as a single line. Delegate small amounts and return large ones to a person. Delegate reversible judgments and retain irreversible ones. A workflow therefore contains several boundaries at once, each marking a transfer or reclamation of authority.
The point to hold onto is that a boundary always exists, whether or not anyone drew it. Even with no design at all, the line is somewhere; the system behaves as if a boundary had been set, because delegation is happening in fact. Without design, that line is unexamined and unowned. Decision Design™ is the work of drawing it consciously and being able to state where it sits and why.
Two enterprise cases make the abstraction concrete.
Consider ERP payment approval. An agent can verify a supplier's credit standing, reconcile the invoice amount, and approve payment. Where should the boundary sit? One defensible placement uses amount and reversibility. Small, routine payments go to the agent. Payments above a set amount, or first-time payments to a new supplier, return to a person. The reasoning is plain: a small routine payment is easy to recover from if it is wrong, while a large or first-time payment is hard to recover from. Here the boundary is two lines, one on the amount threshold and one on whether the counterparty is new.
Now consider cybersecurity incident response. An agent can detect suspicious traffic and cut the connection. The boundary here runs along the scale of impact. Isolating a single endpoint is a judgment the agent can hold, because the effect is local and a false positive is quick to recover from. Taking down a core system or an external-facing service is a judgment a person reclaims, because a decision that can halt the whole business carries too high a reversal cost. Again the boundary follows two axes: the scope of impact and the ease of recovery.
The two cases share their criteria. Reversibility, and the size of the damage if the judgment is wrong. Those two axes are enough to place most Decision Boundaries, and they give Authority Allocation a basis that is explicit rather than improvised.
Decision Logs
A boundary that shifts authority between humans and agents raises a further requirement: someone has to be able to reconstruct, after the fact, who held authority at each step and how it moved. The Decision Log™ meets that requirement. Stated as a principle: Decision Logs do not merely record outputs; they preserve accountability continuity across distributed judgment processes.
A Decision Log™ is not an audit log by another name. An audit log records what was executed. A Decision Log™ records the authority under which it was executed. Three functions distinguish it. First, it preserves authority transitions: at each point where judgment passed from human to agent or was reclaimed, the log captures that the transition occurred and on what basis. Second, it preserves Accountability Continuity: as a single decision travels across several agents and several hands, the log keeps the chain of responsibility unbroken, so that no step is orphaned from an accountable holder. Third, it supports institutional traceability: an outside reviewer, an auditor, or a regulator can follow the sequence and see where legitimate authority sat at every stage.
The distinction matters most in exactly the situation the article opened with. When payments clear overnight and the log names only the executing agent, an audit log answers "what ran." It cannot answer "who held the authority." A Decision Log™ is designed to answer the second question, which is the one that establishes Institutional Legitimacy after the fact.
From Governance to Judgment Architecture
Put the pieces together and the shape of the missing layer becomes clear. Governance manages decisions after they are made. Digital transformation manages the flow of work. Automation manages the mechanics of delegation. AI ethics manages the principles judgment should honor. Each is necessary. None is sufficient alone, and none, individually or in sum, deliberately places the boundary between human and agent judgment.
Decision Design™ operates above all four. It is the Judgment Architecture layer: the level at which an organization structures Authority Allocation, sets its Decision Boundaries, and preserves Accountability Continuity through its Decision Logs. Judgment Architecture is not a competitor to governance, transformation, automation, or ethics. It is the layer that gives them a coherent object to work on, by settling who legitimately holds judgment before the other four disciplines manage the consequences.
This reframing changes what "human in the loop" means in practice. The phrase is usually read as a control to be added. Read through Judgment Architecture, it becomes a design decision to be made: which loop, at which boundary, held by whom, recorded how. A mandate can require that a human remain involved. Only Decision Design™ specifies where that involvement legitimately sits, and only a Decision Log™ proves, afterward, that it sat there.
Conclusion
Autonomous agents severed judgment from the human login. The result is the situation the article opened with: decisions that are made without anyone having decided. Audit logs, approval flows, and permissions harden everything around a judgment. The placement of the judgment itself lies outside all of them.
The real governance challenge is no longer whether AI makes decisions. It plainly does, at event speed, across ERP, procurement, security, support, and hiring. The challenge is whether institutions have intentionally designed who legitimately holds judgment authority, or whether they have let that authority be allocated by tooling and circumstance. A boundary exists either way. The only question is whether an organization drew it on purpose and can account for it, or inherited it by accident and cannot.
That is the work ahead. Not better records of decisions already made, but a deliberate architecture of who decides. The organizations that treat Authority Allocation as a design object, rather than a default, will be the ones that can still answer the simplest question about any automated action: who decided this, and by what legitimate authority.
Decision Design is a judgment architecture framework proposed by Ryoji Morii, founder of Insynergy Inc., for structuring authority, accountability, and decision boundaries in AI-augmented organizations.
Source note. This article was developed from a practitioner piece by DAX Software Solutions, published on the Microsoft Dynamics partner publication ERPSoftwareBlog on July 2, 2026 (a vendor-contributed article). The concepts of Decision Design™, Decision Boundary™, and Decision Log™ are consistent with SSRN Working Paper No. 001.