MOM-305 · OPERATING RISKMOM-305 · OPERATING RISKMOM-305 is the Micro Operating Model for operating risk. It gives an enterprise the architecture to detect trouble, see what can spread, contain it, decide with settled authority, and recover the way it operates, not only the systems it runs on. A kill switch is one action inside it.
Enterprises will soon run thousands of models, agents and AI-enabled applications, on top of the applications, infrastructure, data, vendors and people already there. All of it will interact continuously.
Nobody adds interactions on purpose. They arrive with every new component, and they grow much faster than the components do.
Every complex system eventually reaches a point past which it cannot be understood, predicted or steered in time. Monitoring, committees and human supervision still exist beyond it, but they no longer see enough, fast enough. BlueHour calls this the Complexity Ceiling.
Nobody can say exactly where that point is for a given enterprise, and we do not pretend to. What can be measured is the direction of travel, process by process. Complexity Ceiling Management, MOM-304, helps determine when the system is approaching its operating limits. MOM-305 determines what the enterprise does about it.
The danger is not that a model gives a bad answer. It is that a small action travels. It reaches a system nobody had mapped as connected, other agents act on what it changed, and an hour later the problem is somewhere else entirely.
It works like debris in orbit, where each collision makes the fragments for the next. Sometimes the cause is an interaction nobody designed, anticipated or can easily explain afterwards. We call that a Black Pterodactyl.
By the time anyone sees it, the question is no longer which system failed. It is what the enterprise should stop, what it must keep running, and who decides.
That is an operating model problem, not a technology problem. It needs an operating model answer.
Any vendor can sell you an off switch. The hard part is knowing what to stop, what must continue, who has the authority to decide, and how the enterprise safely recovers. That is the problem MOM-305 is engineered to solve, and it cannot be solved during the event. It has to be designed before it.
MOM-305 runs the enterprise in five operating states. They are states of the whole enterprise, not AI risk levels. In each one, the architecture and the decision rights change.
The demonstration lets you move a fictional insurer through all five and watch the exposure, the authority and the allowed actions change. Open the operating states →
Puts a person in the process.
Gives someone the authority, the information and the responsibility to act.
MOM-305 names that person for every agent class and every operating state, before the event. During it, the CEO and the Board get straight answers to eight questions.
How do we stop the dangerous thing?
What intervention produces the lowest total enterprise harm?
Sometimes the answer is to stop an agent. Sometimes it is to isolate a workflow, or to hold 212 transactions while 4,100 legitimate payments proceed. Sometimes the greater risk is the shutdown itself.
In the demonstration, a procurement agent edits 212 payee records it should never have touched. $1.9M of payments are tied to them. The next payment batch runs in 34 minutes.
4,300 claimants paid late to protect 212. Claims, cash and customers all take the hit.
The 212 payments are held. $4.2M is paid on time to about 4,100 claimants. Total cost: about $18K in late-payment interest.
The objective is not maximum shutdown. It is minimum total enterprise harm while preserving controlled operation. So MOM-305 reports every state the way a CFO reads it: revenue and capital exposure, business interruption, customer and regulatory impact, reputation, time to recovery, and whether you still have the option to deploy the next model.
The purpose is not risk management for its own sake. It is to let an enterprise capture the economics of abundant intelligence without accepting operating risk it cannot see or control.
Halted at 41 minutes, the $1.9M is held. Halted after the batch at 60 minutes, it is gone and recovery becomes a legal matter. Delay does not add exposure in a straight line. It compounds.
Each clock is measured in drills, for every agent class, against what that process can absorb. The method is proposed rather than validated.
Systems back online is not recovery. Every component can come back and the enterprise still not work the way it did. We call that the Humpty Dumpty outage.
MOM-305 signs off recovery only when each of these is verified to be back within its intended boundaries:
MOM-305 is one of sixty Micro Operating Models in the BlueHour60. It does not solve enterprise AI governance on its own, and nothing should. More intelligence requires more architecture, not less.
It starts after Capital Discipline, never before it, and it leans on the models around it.
MOM-305 is activated on top of MOM-001. From your side it needs standing roles, not a project team.
What you receive first: the inventory of every agent class and what it can reach, the decision rights for each operating state, and the first drill, which measures how long it really takes to observe, halt and restore. Scope and price are set at activation, from what MOM-001’s ledger shows you run.
MOM-305 is activated after MOM-001, Capital Discipline. Authority is designed before the event, not negotiated during it. See what could propagate in your enterprise.
A note on where we are: MOM-305 is in design. The demonstration is built on a fictional company with illustrative data, because we will not show you another client’s numbers, and because we will not show you measurements we have not yet taken. The architecture and the method are ours.