Over the last decade, many manufacturers have connected their factories. They added sensors, data platforms, production tracking systems and dashboards beside the line. Many now run an artificial intelligence (AI) pilot or two on that data. Often the pilot works, and the way the factory runs day to day hardly changes.
The model predicts a bearing failure, flags drift in product quality, or suggests a better schedule. The result then goes to a person, who has to decide whether to act on it, check with two other teams and look up a limit in a spreadsheet. The pilot gets a good review and stays a pilot.
What is missing is a definition of the decision itself. People make the decision every day, but few factories have written down how it is made and who may authorize the response, in a form someone keeps current.
A Maintenance Decision Today
Take a common one: whether to take a line down for maintenance this week or run it to the next planned downtime. The machine condition sits in the monitoring system and the volumes sit in the production plan. The acceptable level of risk sits in a maintenance procedure written three years ago, the customer commitments sit in the planner's spreadsheet, and the approval route is a habit of who copies whom on email. Which of these is out of date is known only to a senior maintenance engineer with twenty years in the factory.
That works until the engineer retires, or until part of the work moves to software.
Why a Good Model Is Not Enough
A model can produce a sound recommendation and leave the factory where it started. Whether software may go further and act depends on the permissions and controls around it, and those are hard to set when nobody can say where the rules of the decision are kept. This is a common reason pilots stall after a good demonstration.
Factories Already Do This at the Machine Level
Manufacturers apply this discipline to their machines. A machine controller program has set parameters, limits and a controlled way to change them. A safety interlock (an automatic stop when a guard opens or a safe limit is crossed) is written down, tested and approved before it goes live. The operating decisions above the machines, about what to make, when to stop a line and how much risk to accept, usually get far less of that rigor.
What a Decision Definition Contains
A decision definition is agreed before any single decision is made. It covers:
• What the decision is trying to achieve.
• The information it uses, and what each value means.
• The requirements that apply, and which one wins when two conflict.
• The point where a person must use judgment, and who that person is.
• Who may approve the response, and the actions that are allowed.
• What happens when information is missing or a case falls outside the definition.
The record of each decision afterward is separate: what was seen, what was chosen and who approved it. That record is how the definition gets checked and improved.
A procedure in a shared folder does not change what software is allowed to do. The approved definition has to be connected to the systems where the decision is made, so the limits and the authority to act are checked before any action goes ahead. How a person or an AI tool reaches a recommendation inside those limits is up to them. "One place" means one maintained definition, linked to the systems that already hold the data.
The Maintenance Decision With a Definition
Here the definition states the goal: meet the shipment dates without accepting more than an agreed risk of failure before the next planned downtime. An engineer or an AI tool works from the condition data and the production plan to find the best option within that limit. The definition names who resolves a conflict between the risk limit and a shipment commitment, for example the production manager with the maintenance lead, and sends the case to a person when the condition data is missing or stale. The senior engineer's judgment is still used, at the point where the definition asks for it.
The definition also has to be maintained. A new demand forecast runs the same decision again with new numbers. A tighter customer quality requirement changes the limits, and that change needs review and approval before the next decision uses it. Systems that treat both the same way cannot tell an AI tool which of the two it may do.
Where to Start
Choose one decision that comes up often, is expensive to get wrong, and needs more than one team to agree on it. Then try to answer these questions:
1. Where are the rules for this decision kept, and who keeps them current?
2. The last time a requirement changed, what had to be updated, and how long did it take?
3. For a decision made last month, can you show what information was used and who approved it?
If the answers point to several spreadsheets, a procedure and one person's memory, that decision is a good first candidate. Define it, connect it to the systems that hold its information, and run it with people approving every response until the records show where the definition works and where it needs changes. Software can then take on more, first advising and later carrying out specific actions within limits the factory sets and can withdraw.
The smart factory programs of the last decade answered the question of what is happening in the factory. The next question is how the factory decides what to do about it and who may act. A factory that can answer that can put AI to work. One that cannot will keep running pilots on decisions nobody has defined.
