Abstract
Every discussion of industrial AI eventually reaches the question of what a system may do without a person. The question is usually deferred as premature. It is not premature. It is the design decision that determines whether a deployment is defensible after an incident, and it costs nothing to settle before the capability exists. This paper argues that authority must be specified per action rather than per system, that evidence burden must scale with reversibility, and that the only thing which reliably catches an authority failure is a designed verification step rather than the care of the people involved.
The machine that started with my locks on
Early days at a plant, and I did not yet know the lockout system. I did not even know which electrical rooms the lockout points were in.
I had to climb inside a machine with a lot of lockouts on it, so I asked the electricians on shift to lock it out for me, and once they were done I added my own lock to the box. Then I spent all day inside that machine.
I crawled out. The shift supervisor asked if I was done. I said yes. He released the e-stop.
The machine started instantly. With my locks still on it.
The electricians had locked the wrong points. Nothing was actually isolated. The e-stop was the only thing holding it, and these plants run automated machines, so an e-stop is just a stop. Release it and the machine goes back to auto and runs on its own. The only sure isolation is a lockout.
They were good guys. Nobody was trying to hurt me. They just did not do it right.
And neither did I. I never bump-tested it. I never pulled the e-stop myself, from clear, to watch whether the machine would start before I climbed in. The single biggest failure in that story is mine, and it was a stupid easy little thing.
Why that story is about authority and not about safety
Every person in that chain was careful and competent and it still nearly killed me. So the fix cannot be "be careful," because careful was already fully deployed.
The fix is a designed verification step that catches the error no matter who made it.
The bump test. Pull the e-stop, which is the move that would normally turn the machine on, and watch. If it stays dead, your lockout is probably good, because the only thing left holding it is your isolation. Then call the control room and have them try to override it and get it rolling. If they cannot make it go, the lockout is good and the machine is truly dead.
If it starts, either when you pull the e-stop or when control leans on it, then the lockout did not do the job and there is still work to do.
In my story neither step happened. The machine was never confirmed dead before a body went in.
Now translate. A lock box is a claim about isolation. Trusting the lock box is not the failure. Treating the claim as the verification is the failure, and the entire authority question in industrial AI is the same shape.
"The agent has write access to the CMMS" is a claim about permission that somebody made, in the same voice and with the same confidence as "the machine is locked out." It may be true. It may describe the wrong points. Nothing about how confidently it is stated tells you which.
Authority is not a technical property
A system's authority is a decision the organization makes, not a capability the vendor ships. The same model can be an advisor, a drafter, or an actor, and the difference lies entirely in what the surrounding process permits it to commit.
This is why authority has to be specified per action.
Creating a follow-up notification, changing a priority, releasing a job to a schedule, and closing a permit are four different consequences with four different reversibilities. They should not share a permission, for the same reason that a man who is allowed to open a valve is not therefore allowed to sign the isolation certificate.
Evidence burden rises with consequence
The governing principle is that the evidence required should scale with what an action costs to undo. A reversible, low-cost, easily-noticed action can proceed on weak evidence. An irreversible one should require evidence a person has examined, with a name attached.
ADMITBench formalizes a version of this for industrial advisories, evaluating admissibility with non-compensatory checks across evidence, authority, procedure and consequences, so that strength in one dimension cannot offset failure in another. Extending it to actuation is the natural next step, and Anthropic's Model Hardware Standard preview signals that agents operating physical devices is a near-term concern rather than a hypothetical one.
There is also a regulatory direction forming around exactly this. California's SB 813 was enrolled on 30 August 2026 after the Assembly concurred 37 to 0. It would establish a California Artificial Intelligence Standards and Safety Commission and require the Government Operations Agency, by 1 January 2028, to select and regulate independent verification organizations: designated expert panels that assess the risk posed by an AI system, sector by sector, rather than accepting the developer's own assertion.
Whatever becomes of that specific bill, the shape of the idea is the bump test written into law. Somebody outside the chain of interest pulls the e-stop and watches, and the operator does not get to grade his own isolation.
The approval that outlived its assumption
There is a failure mode worse than an unauthorized action, and it is an authorized one whose authorization has quietly expired.
We had a spare motor, easily a hundred thousand dollars, and somebody parked it directly under the stranders, which is the highest vibration point in the mill. I agreed to that, and I want to be precise about why. There was a mechanism built to hold the shaft up so the rotor did not ride on the bearings. It worked. With the weight off the bearings the vibration had nothing to chew on. That was the correct mitigation and it was in place when I signed.
Then somebody removed the mechanism. No record, no rationale anyone could point to. The motor sat with full rotor weight on stationary bearings, vibrating, for three years. Another mill needed it, they installed it, and it failed in about three months.
When I raised it, the answer I got was "you signed off."
Yes. With the mechanism holding the shaft up. That sign-off died the day the mechanism was removed, and nothing in the system noticed, because the approval was recorded and the condition it depended on was not.
This is a live problem for AI deployments and it is going to bite somebody hard. An organization approves an agent's write access under conditions: read-only source, human review of every release, a specific data scope. Six months later the source changed, the review became a rubber stamp, and the scope widened. The approval is still on file. It is still being cited. It stopped being valid a long time ago.
Record the assumptions beside the approval, and re-run the approval when an assumption changes. Otherwise you are holding a piece of paper that describes a decision nobody would make today.
Verify the paperwork, not the assurance
I was told, flat out, that all the hands on site were certified to run the telehandler. I checked one down day. Not one guy was. Not one, and I had been told they all were.
Contractors will actively lie about certifications, or pass along a lie somebody told them, because "yeah, he's ticketed" is the answer that gets them on site. The day you find out otherwise is the day the machine is on its side, or a man is under it.
A ticket is a piece of paper. Ask to see the paper.
The equivalent question for a deployed system is not "does it have the right permissions." It is "show me the permission record, per action, and show me who granted it and when it was last reviewed." An assurance is not an artifact.
Authority without obligation is theatre
One more failure, because a paper about who signs is incomplete without it.
I found a guard that had fallen off a machine and worn into a three-inch drive shaft like it was on a lathe, down to maybe a quarter inch of steel left. I photographed it, emailed my supervisor, flagged it urgent, and put in the work order.
It got ignored. Two or three weeks later the shaft failed. When management hauled the maintenance team in to berate us for missing it, I showed them the photos, the email, and the work order.
Every authority in that chain functioned exactly as designed. The flag was raised by the right person, through the right channel, to the right recipient, with evidence attached.
Nobody had the obligation to act on it. Authority describes who is permitted to decide. Obligation describes who has to respond, and by when, and what happens if they do not. A system with clean authority boundaries and no obligations produces a perfect audit trail of a failure nobody prevented.
If you build an AI readiness system that raises findings, decide in advance who has to answer them and inside what window. Otherwise you have automated the production of ignored flags, which is a thing plants are already excellent at doing by hand.
What you are actually accountable for
The last thing a paper about signing has to answer is what a signature costs you when it goes wrong. The best answer I ever heard came from a plant manager correcting me.
An OSB plant I was at ran for weeks with out-of-spec board coming off the line. Not a batch. Weeks of production. When it eventually got dumped on the market graded out-of-spec, good for sheds and the like, there was so much of it that it dropped the price of good board for some time afterwards. The other OSB plants were furious, and fair enough.
The cause was a faulty thickness detector. Minor fix, done quickly.
The real failure was quality control, and I cannot tell you why they missed it. My assumption is that nobody was looking, but that is an assumption and I was not in that department.
The head of quality control was fired. Afterwards I was talking with the plant manager and said I agreed with the decision. He looked at me and said, near enough word for word:
> I want to make one thing clear. It was a mistake, a bad one, but that is not why I fired him. I > fired him because he did not have a plan so it would not happen again.
That reset something I had believed my entire career. I have always been the one who forgives mistakes, on the grounds that everybody makes them and only an asshole fires a man for one. My line was the repeat. Do it twice and we are having a different conversation.
His line was better, and it is the one worth writing into a governance framework.
The accountable failure is not the error, and it is not even the repeat. It is the absence of a plan to prevent the repeat.
Two things follow, and both matter more for an automated system than they did for a quality department.
It collapses the waiting period. Holding people to the repeated mistake means buying the second failure at full price in order to obtain information that was available for nothing the week before. The absence of a plan is the prediction. You do not need the repeat to know it is coming, and with a system operating at machine speed across an asset base, you may not get a comfortable interval in which to learn.
And it separates the person from the error cleanly, which is what makes it fair rather than punitive. Nobody is being held to account for being fallible. They are being held to the one thing that was entirely inside their control after the fact. Somebody who owns a failure and arrives with a plan has done the job. Somebody who owns it and arrives with nothing has told you the next one is already scheduled.
Now set that against a deployment.
When an agent-assisted decision produces a bad outcome, the reflex question is who is to blame, and it is the wrong question for exactly the reason it was the wrong question at that mill. The vendor will say the model performed within specification. The integrator will say the configuration was signed off. The plant will say it followed the recommendation. All three can be true at once and the board is still out of spec.
The question that resolves is the plant manager's. Who owed a prevention plan, and is there one? Not a root cause narrative, which is a document about the past. A change to the system, named, dated and owned, that makes this specific failure not recur.
That is also the only version of accountability a deployment can survive. If the answer to every AI incident is that a person gets removed, you will run out of people willing to sign, and everything else in this paper collapses, because all of it depends on named individuals being willing to attach their name to a decision. Hold them to the prevention plan instead and signing stays survivable.
One caution, and it cuts against my own argument. This standard is only fair if the person had the authority and the information to build a plan. Holding a man to a prevention plan for a system he was not permitted to change, or for a failure he was never shown, is the old blood sacrifice wearing better clothes. Which puts you back at the top of this paper. Specify the authority per action, and write it down before it is tested.
The rule that makes it acceptable on the floor
One rule does more work than any other, and it should be stated without softening.
No system may move a fact from unknown to known by its own inference. Only a named person with the relevant qualification can do that, and their name stays attached to the record.
This is not a limitation to be engineered away later. It is what makes the framework acceptable to a safety manager, an insurer, and the tradesman standing in front of the machine.
A plant that cannot say who signed cannot investigate its own incidents. And a plant that cannot investigate its own incidents does not get to keep operating the way it does.
Conclusion
Write the authority ladder before the capability arrives, because writing it afterwards means writing it under pressure, with a sunk investment in the room and a vendor holding a roadmap.
Specify per action, not per system. Scale the evidence burden to reversibility. Record the assumptions beside every approval so it expires when they do. Attach an obligation to every finding. And build one designed verification step that does not depend on anybody being careful, because in the story where I nearly died, everybody was careful, and careful was not enough.
Pull the e-stop yourself before you climb in.
References
- Misra, Vyas, Gutta & Mercangöz, “ADMITBench: A Safety-Governed Reference Framework for Evaluating the Admissibility of Industrial LLM Advisories,” 2026. https://arxiv.org/abs/2608.03866
- Anthropic, “Previewing the Model Hardware Standard,” Aug. 27, 2026. https://www.anthropic.com/news/model-hardware-standard-research-preview
- IBM Docs, “Creating custom AI tools in Maximo by using object structures.” https://www.ibm.com/docs/en/masv-and-l/cd?topic=tools-by-using-object-structures
- Oracle, “AI Agent: Maintenance Work Order Builder.” https://docs.oracle.com/en/cloud/saas/readiness/scm/25d/maint25d/25D-maintenance-wn-f40777.htm
- California Senate Bill 813, “Independent verification organizations” (2025-2026 session; enrolled 30 Aug. 2026). https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202520260SB813