The Physics of Business

A modern factory can run through the night with the lights off. Machines cut metal, move parts, and assemble products with no one on the floor and no human confirming any single action. We trust them to do this unattended. It is worth asking, plainly, why.

The easy answer is that the machines are precise, or sophisticated. That is not the real reason. A machine tool is not intelligent. It does not understand what it is making. We trust it because of something underneath it: the constraints of the physical world it works in.

Everything a machine attempts runs up against reality in the moment. The metal has a hardness. The tool can only move so fast before it breaks. The arm can only reach so far. And notice what reality is actually enforcing. It does not judge whether a motion is a good idea or a bad one. It enforces something narrower and far more dependable: what is possible and what is not. Ask a machine to do the impossible and it does not quietly comply and leave a mess to be discovered later. It stalls. It stops. The impossible is not discouraged. It simply cannot occur.

But physics alone is not what makes the automation trustworthy, and it is worth being exact about this, because the whole argument turns on it. The space of the possible is vast, and most of it is wrong. A machine can drive its tool straight through the fixture holding the part; the metal does not forbid it. What physics gives you is not safety. It is a bounded, finite space of the possible to work inside. Safety is the next step, and it is reachable only because of that first one. Because the possible is already defined, engineers can carve out of it the much smaller space of the valid, the actions that are actually correct, and hold the machine to that. What you want on any given run, the desired, is a smaller space still, chosen from within the valid. So trustworthiness is not the machine staying inside what reality permits; reality permits a great many wrong actions. It is the machine being confined to the valid, a subset of the possible that could be defined only because the possible was defined first. Control engineers have understood this for a century. You do not get there by making the machine smarter. You get there by deriving valid from possible and never letting the machine leave it.

Hold onto that nesting: the possible, then the valid carved from it, then the desired chosen from within the valid. Something proposes an action, and something with authority lets it become real only if it falls inside the valid, and nothing can get around that gate. It is what the factory floor has. It is what the systems running the business almost never do.

The physics we stopped enforcing

Move from the factory floor to the systems that run the business around it. The ERP. The financial ledger. Order management, supply chain, the quality and compliance records. Ask the same question. When one of these systems commits a state change, when an order moves to fulfilled, a part is released to production, a payment is authorized, a lot is dispositioned, what plays the role that physics plays on the floor? What authority checks the change and rejects it if it is invalid?

The uncomfortable answer, in nearly every enterprise, is that nothing does the whole job. A database enforces a few structural constraints, and a workflow engine checks a few transitions, but the checks are scattered, none of them sits on the path of every change, and no single authority decides what is allowed. It is tempting to conclude from this that business has no physics, that operations are too fluid and too human to obey laws of the kind a machine tool obeys. That conclusion is wrong, and getting it wrong is the whole mistake.

Every business runs on a real physics. An order has a lawful sequence of states and cannot occupy two of them at once. A part cannot be released before its inspection clears. A payment cannot be authorized except by someone who holds the authority to approve it. A regulated batch cannot be cleared for sale until it meets the conditions its compliance rules require. These are not preferences or best practices. They are the real operating constraints of the business, as fixed as any limit on the factory floor. Violate one and something is genuinely broken, whether or not anyone notices in the moment.

The difference between the factory floor and the back office is not that one has physics and the other does not. It is that on the factory floor the constraints enforce themselves and in the enterprise they do not. The hardest physical limits never have to be built; the material and the machine are their own enforcement. In the enterprise, nothing in nature intervenes. Gravity does not prevent you from shipping against a credit hold. The laws are every bit as real, but they are inert. They will not enforce themselves. Something has to make them enforceable at the point of action, or they govern nothing at all.

Something has to play that role: a place where the real physics of the business is made enforceable before anything becomes real. Call it the operational substrate. In the enterprise it has to be built deliberately, and the central claim here is that the industry, for thirty years, did not build it. It built something adjacent and hired people to make up the difference.

Consider what an ERP system actually does. At its core it is a system of record. It stores the outcomes of business events. It is very good at telling you what is currently believed to be true. What it does not do, not as its central architected job, is own the question of whether a proposed change is allowed. Whatever validations it carries are partial; it records that the order shipped, but it does not, at the moment of shipping, reliably enforce that shipping was allowed. The rule that should have prevented it lives somewhere else. In a validation script. In a customization that forks on the next upgrade. In an integration’s transformation logic. In a procedure document. In the trained judgment of a controller who is supposed to catch it. In an audit that will find it three quarters later.

None of this means the rules were never written down. Enterprises pour enormous effort into defining them. The failure is not that the rules are missing; it is where they live. Each one sits beside the write path rather than on it, so what looks like a system of gates is really a patchwork of notional ones: a change that does not pass through a given check simply goes around it. The rules are defined, and often enforced, everywhere except the one place that would make them binding.

So the loop does get closed. It simply gets closed by people. Reconciliation teams close it. Governance committees close it. Master-data stewards close it. Integration software closes it, endlessly translating between systems that disagree about the same fact. Internal audit closes it after the fact. An entire layer of the enterprise exists to continuously restore a coherence the software does not maintain on its own. The human organization is the feedback controller the architecture is missing.

Here the practical question, the so what, gets its first concrete answer. That missing controller is not free. It is a large and stubbornly persistent cost, and it is almost never named as one, because it is spread across a dozen departments and booked under a dozen headings. All of it is the running cost of a loop that was never closed in software. Much of the industry treats this as a fact of nature. It is not. It is the predictable overhead of an architecture with no closed loop, and because it scales with the size of the enterprise, it does not go away on its own.

What AI actually exposed

For a long time this was tolerable, because the proposers were slow. A human proposes a state change at human speed, and the human control loop, however expensive, could roughly keep pace. The system was incoherent, but within bounds the human layer could absorb.

Artificial intelligence removes that tolerance, and in doing so it exposes the architecture for what it is.

The market’s response to enterprise AI has concentrated almost entirely on one thing: making the proposer better behaved. The vocabulary is now familiar: guardrails, model governance, monitoring, red-teaming, research into why models do what they do. Every one of these is a serious effort, and every one addresses the same half of the problem: the quality of what the model proposes. They are attempts to build a better proposer.

Very few efforts address the other half. Very few ask the question a control engineer would ask first. Not “how do we make the model propose fewer bad actions,” but “what guarantees that an invalid operational state cannot become authoritative, regardless of who or what proposed it?”

This is the distinction the field is skating past, and everything downstream depends on it. It is the same split we began with, now named. The proposer perceives: it observes, infers, and suggests. A separate authority decides what is permitted to become real. On the factory floor the two are cleanly separated, and the loop is closed precisely because perception cannot write directly to reality; no confidence in the proposer overrides the boundary.

Enterprise software never enforced this separation, because it never had to. When the only proposers were people and the deterministic scripts people wrote, perception and authority were tangled together, and the human control layer papered over the difference. AI severs the arrangement. It is a perception engine of extraordinary capability and speed, now connected directly to systems that have no authority layer of their own, systems that record whatever they are told and rely on a downstream human loop to catch what should never have been recorded.

The result is not that AI behaves badly. Most of the time it behaves well. The result is that the enterprise cannot prove, at the moment of action, that what became real was allowed to. It cannot prove it because the guarantee was never located in the software. It was located in people, and people cannot review machine-speed action at machine scale. This is the second answer to so what, and it is the one that should concentrate the mind of anyone deploying capital or operations against enterprise AI. Part of why AI pilots stall on the way to production, and a part that gets too little attention next to model accuracy and unclear ROI, is that responsible deployment requires a guarantee today’s systems cannot give. The bottleneck is not the intelligence of the machine. It is that nothing decides, at the moment of action, what is allowed to become real.

The execution boundary

If that is the correct diagnosis, the correction is not exotic. It is the thing control engineering has required all along, applied to a domain that has managed to avoid it.

But it means being precise about the gate we are building, because it is not the gate physics provides. Return to the nesting from the factory floor: physics defines the possible, and valid is carved from it. The step we rarely credit is the first one. Defining the space of the possible is the expensive part, and on the factory floor physics did it for free.

Enterprise software gets no such gift. A database enforces types and a handful of structural constraints, but nothing in it knows that this order may not move to shipped, or that this approval may not happen before that inspection. At the level of business state, the space of the possible is effectively unlimited, because the technology forbids almost none of it. So before you can even tell a valid change from an invalid one, you have to do what physics did for free and define what is possible at all. Only against a defined space of the possible can validity be derived, and only then enforced. That definition, the model of which states can exist and which changes can occur, is the first and largest part of what a business’s operating system has to be, and it is the part the industry never built. It recorded outcomes into an unbounded space and left validity to be pieced together case by case, in scattered checks and human judgment, which is the best anyone can do when the possible was never defined.

So the gate an enterprise needs is good against bad, and there is only one way to make it as reliable as physics: define the possible, then make bad impossible within it. You build the system so that an invalid state is not flagged, not discouraged, not caught downstream and unwound, but genuinely cannot come into being, for every rule you can reasonably articulate. The reliability lives in the impossibility; the craft lives in the articulation. The more of what you mean by bad you can state as a rule, the more of it stops being a risk to manage and becomes an outcome that cannot happen.

Concretely, that means one point every change must pass through, a point that decides what is allowed. Call it the execution boundary. Every proposed change to the state of the business, without exception, has to go through it, and it enforces the real rules of the operation, which states are legal, which changes are allowed, who may authorize them, under what conditions, before anything becomes real. And it has to be unavoidable. Not one path for the application and a looser one for the automation. Not one set of rules for people and another for machines. People, AI agents, connected systems, partner integrations, data imports, overnight jobs: every way the state of the business can change runs through the same point, and that point decides.

The critical inversion is this. Authority moves off the proposer and onto the substrate. It stops mattering who proposed a change. A human, a trusted integration, and an autonomous agent are treated identically at the boundary. Each proposes a change, and the system admits or rejects it against the same rules. The proposer is demoted to what it always should have been, perception. The substrate is promoted to authority: it, and not whoever proposed the change, decides what is allowed to become real. And because that authority sits on the only path by which anything becomes real, a rejected change is not merely discouraged or logged. Like an impossible motion on the factory floor, it cannot happen at all.

Now the economics follow, and they follow as consequences, not features: things the architecture stops requiring rather than things you add to it.

If that one point enforces the rules, an invalid change cannot get in, so the downstream reconciliation that existed to catch invalid changes has nothing left to catch. The cost of the missing human controller does not shrink. It stops being necessary.

If every change resolves through one governed boundary against one shared model, integrations stop reconciling to each other and reconcile to that shared source of truth instead. The endless work of making systems agree with one another, the reason integration is a permanent cost rather than a one-time project, largely goes away.

If authority is recorded with the action at the moment it is admitted, audit stops being an archaeological reconstruction of what happened and why it was allowed. It becomes a query against a record that already contains the answer. Audit cost falls, not because auditors get faster, but because the thing they were reconstructing is now captured by construction.

If the governing rules live inside the boundary rather than in documents and committees around it, governance stops being a standing organizational function that compensates for the software and becomes a property of the software. The governance function’s work is not automated. It is absorbed.

And if the boundary can reliably reject an action that breaks the rules, no matter who proposed it, then, and only then, an autonomous agent can be given real operational latitude, because the cost of it being wrong is bounded by the system rather than by human review. Safe enterprise AI is not only a property of the model. It is also, and more durably, a property of the system underneath it. You cannot make the agent safe from the inside alone. You can make the boundary sound, and much of the agent’s safety follows from it.

None of these are optimizations of the current architecture. They are the current architecture’s overhead disappearing because the reason for it was removed. That is the difference between a feature and a consequence, and it matters commercially, because consequences of a foundational change are not competed away by someone shipping a better proposer.

Why a whole industry missed it

If the correction is this fundamental, the obvious question is why it went unaddressed for so long. Not because the industry lacks intelligence, but because it is path-dependent, and path dependence at the scale of an industry is a rational and powerful force.

Enterprise software inherited its core assumption, that the system’s job is to record state and that keeping that state legal is an organizational responsibility layered on top, from an era in which it was the only feasible design. Databases recorded; people governed. The assumption was never revisited when the constraints changed. Instead, thirty years of engineering, tooling, process, and career specialization accreted on top of it, and each layer made the assumption more expensive to question. This is the ordinary way a foundational choice becomes permanent: not because anyone defends it, but because an entire superstructure comes to depend on it.

The economics deepened the inertia. An architecture that requires a permanent human control loop is, from the outside, a large and durable services market. The reconciliation, the integration, the upgrade-and-recustomize cycle are not only costs to the enterprise; they are revenue to a substantial ecosystem that has little structural incentive to remove the incoherence sustaining it. Most governance products are built to sit around the system of record and observe it. Very few are built to move authority into it, because doing so dissolves the market for governing it from outside.

Underneath all of it is a categorical mistake so basic it is nearly invisible. The industry treats ERP as an application, a place where business data lives and processes are configured. But the system of record was always meant to be an operational authority system, the thing that decides what is allowed to become real. Treated as an application, it accretes features and customizations. Treated as an authority system, it would have decided what was allowed from the first line of code. The industry optimized the application for thirty years without noticing it had filed the category wrong.

The market is starting to point at it

It would be a mistake to claim no one is moving. The most interesting development of the last few years is that the market is beginning, independently and from several directions, to locate the problem in the right place.

The center of gravity in enterprise data appears to be shifting toward the execution and data layer. Oracle, for one, has been moving governance and policy closer to where operational data actually lives, rather than leaving it to a constellation of surrounding tools. Efforts like Nextdata and the broader data-contracts movement amount, in effect, to an argument that guarantees about data should travel with the data and be enforced at its source rather than asserted by downstream consumers. Different vocabularies, different starting points, but a common intuition is surfacing across the field. Governance asserted from outside a system does not hold, and enforcement has to move closer to the point where state is actually written.

This convergence should be read carefully and without overstatement. It does not mean the problem is solved. It means something more useful for anyone trying to understand where value will accrue. The market is independently confirming the location of the problem. When several serious, well-resourced actors begin moving toward the same region of the architecture from different directions, it usually signals that the region is real and that a category is forming around it.

But note what most of these efforts still do. They add a layer. A data-contract tier above the stores. A governance plane beside the applications. A policy service in front of the APIs. Each is an improvement, and each preserves the underlying assumption, that the system of record records, and that the rules are enforced somewhere next to it. That is still governance around the system rather than within it. The layer is thinner and closer than it used to be, which is genuine progress, but the loop is still not closed at the point where state is actually written. The proposer and the authority remain separable, and anything separable from the write path can be bypassed by a path that does not go through it.

The step the convergence is circling but has not yet taken is to stop adding a governing layer and to make the system of record itself governing, so that enforcement is not a service in front of it but part of it, and no write path can escape the boundary, because the boundary is the only way state changes at all.

What the next decade actually turns on

Which returns us to the beginning, and to a prediction the argument now makes difficult to avoid.

The next generation of enterprise automation will not be decided by which model reasons best. In the terms of this argument, a model’s reasoning sits on the perception side: it proposes. And perception is improving quickly and broadly. It is on its way to being a commodity, available to everyone, and it will not be where durable advantage lives. The decisive question is a different one. It determines whether an enterprise can safely let machines act, whether its operational data can be trusted, whether its automation compounds or quietly accumulates liability. The question is this: which system can decide, with certainty, what is allowed to become reality? That is not a question about intelligence. It is a question about control.

An enterprise that has such a system gets what cannot be bought as a feature or added by a better model: operational data it can trust by construction, and the ability to point autonomous agents at real operations knowing the boundary, not the agent, decides what commits. There is a further effect worth naming, because it is where the largest value tends to sit. When organizations share governed, authoritative records of what happened across such systems, when the same guarantees about what is allowed hold across a network of participants rather than stopping at one company’s edge, trust becomes transitive. Value then compounds the way infrastructure value compounds, not linearly with the number of users, but with the density of the network that comes to rely on it.

This is the architectural correction the field has been circling. Mimir Labs built a reference implementation of it, and did so by making the physics of the business the core of the system rather than something layered around it. Not another ERP, but a system in which one boundary decides what is allowed to happen rather than merely recording what did. In which the real laws of the operation, its legal states, transitions, authority, and conditions, are enforced at one boundary before anything becomes real, whether the proposal came from a human, an integration, or an autonomous agent. In which governance is not asserted around the system of record but is the system of record. It was built to this thesis before the market had broadly articulated the need for it, which is the ordinary way reference implementations tend to precede the categories they end up defining.

The deeper point is the one worth carrying out of this piece. For thirty years the incoherence of enterprise systems has been treated as a management problem, a process problem, a data-quality problem, an integration problem, and lately an AI problem. It is none of these, or rather it is the surface expression of something that sits beneath all of them. It is a control-systems problem: a proposer connected to reality with no authoritative boundary to close the loop. Physical automation solved it a century ago because physics handed it a defined space of the possible, from which the valid could be carved and made self-enforcing. Enterprise automation never solved it, not because business has no physics of its own, but because it never built the foundation that would define its possible and enforce the valid within it. The industry is now pouring its most capable proposers into that open loop and asking why the results cannot be trusted. The answer was never going to come from a better proposer. It was always going to come from closing the loop. Enterprise AI, in the end, is a control-systems problem wearing the costume of an intelligence problem, and the companies that understand the difference are the ones quietly building the layer everyone else will eventually have to stand on.