AI on the Factory Floor

Commission AI by its distance from physical consequence – not by its model category

Altivate | Published 7 June 2026 | Updated 26 July 2026

1. Manufacturing AI has several jobs, not one adoption curve

Manufacturing AI spans predictive maintenance, quality inspection, demand forecasting, production scheduling, safety monitoring, document assistance and digital twins. That is a useful portfolio map, but not one adoption curve. The categories differ in a more important way: the consequence of the output and the authority delegated to it.

• A document assistant helps an engineer find a maintenance procedure.
• A vision model marks a product image for review.
• A predictive model recommends an inspection window.
• A scheduling optimiser changes the order in which work runs.
• A closed-loop system changes a process parameter.

The first can be wrong without touching production. The last can create scrap, downtime, a quality escape or a safety event before a person reads a dashboard. Treating both as one “AI use case portfolio” obscures the commissioning question.

The practical decision is not whether the model is generative, predictive or agentic. Classify on two axes:

1. Consequence severity: what state can change, how quickly can the effect become physical and how severe could the result be?
2. Delegated authority: may the system observe, recommend, approve or act; is the action reversible; and does an independent interlock remain?

The commissioning question is:

Context: Altivate’s work across manufacturing, supply-chain management and AI technologies.

2. The control ladder

Use five levels. Move one use case at a time.

This is not a maturity model. “Observe” may be the correct permanent level for a safety investigation assistant. “Closed loop” may be appropriate for a narrow, well-understood control problem after engineering validation. Value does not require every use case to climb.

The ladder also prevents a language trick. A system can be read-only at the application layer and still affect production. A recommendation on a control-room screen changes operator behaviour. A query against operational technology can consume resources or expose a fragile interface. NIST’s smart-manufacturing cybersecurity work notes that direct, near-real-time access to OT can itself put process performance and safety at risk.

Read-only therefore means “does not issue a write command.” It does not mean “has no consequence.”

3. Observe: useful, fast and still an integration

Observation is the best starting level for many plants:

• retrieve the relevant operating procedure;
• classify a quality image for human review;
• detect an unusual pattern in sensor history;
• summarise an alarm sequence;
• identify records that need engineering investigation;
• explain why a planning exception was raised.

The architecture should keep the AI path outside the control path. Prefer a historian, replicated store or governed analytics layer over direct polling of a controller. Rate-limit queries. Make data age visible. Preserve the raw source alongside the interpretation.

Three failures are easy to miss.

Stale data presented as current. A plausible explanation of yesterday’s state can be worse than an explicit “data unavailable.” Every result should carry source timestamp and ingestion status.

Context removed during feature engineering. A vibration signal without operating mode, load, maintenance state or sensor-health context can create a confident but invalid comparison.

A detection treated as a diagnosis. Anomaly detection says the pattern differs from its reference. It does not establish cause. Keep “detected,” “classified” and “diagnosed” as separate states in the user interface and event record.

Observation can scale before action because its errors are easier to contain and because it creates the labelled cases needed to evaluate later levels.

4. Recommend: print the operating envelope

A recommendation should say more than “inspect asset 14.”

It should expose:

• the evidence window;
• the operating mode and relevant context;
• the range over which the model was evaluated;
• uncertainty or confidence in a form the operator understands;
• the cost of acting and not acting;
• the person or role expected to decide;
• the time after which the recommendation expires.

The operating envelope is the set of conditions in which the model has evidence of acceptable performance. A model evaluated on one product family, speed range and sensor configuration should not quietly generalise to another line. When the current state falls outside the envelope, route to engineering review rather than converting uncertainty into a lower-confidence recommendation.

This is also where independent baselines matter. Compare the model with the current preventive maintenance interval, inspection sampling plan or scheduling rule. A pilot should not be approved because the recommended cases look reasonable; it should improve a defined outcome without creating an unacceptable failure mode.

Useful measures are operational:

• false negatives that could release a defect;
• false positives that consume inspection or maintenance capacity;
• time from signal to reviewed decision;
• avoided unplanned work, calculated from confirmed cases;
• recommendations ignored and the reason;
• performance by line, product, shift and operating state.

Do not compress these into one accuracy number. A quality escape and an unnecessary inspection do not have equal cost.

5. Act: put the model behind an independent boundary

When AI output can change production state, the execution architecture should assume the model can be wrong.

The model may propose a schedule change, parameter adjustment or work order. An independent component should validate:

• target identity and current state;
• allowed action and parameter range;
• freshness of the evidence;
• model and policy version;
• required human approval;
• production, safety and quality interlocks;
• duplicate or conflicting commands;
• rollback or safe-state path.

The control belongs in code, configuration or the established industrial safety system – not in a prompt. A prompt can ask the model to stay between two values. It cannot enforce the limit after a malformed response, tool translation error or compromised instruction.

For actions that cannot be reversed, design compensation rather than pretending rollback exists. A scrapped batch cannot be unproduced. The recovery plan may be to quarantine material, stop a line, add inspection or revert to the validated manual procedure. Name that plan before go-live.

An automatic stop should trigger when:

• inputs are missing, delayed or outside the evaluated envelope;
• the model or tool version differs from the approved version;
• error or override rate crosses a threshold;
• the interlock service is unavailable;
• downstream state cannot be confirmed;
• cybersecurity monitoring detects unexpected access or traffic;
• operators invoke a manual stop.

Failing over to “let the model continue with best effort” is not high availability.

6. Digital twins need evidence of fidelity

Digital twins are often introduced as the bridge between observation and action: test a decision in the twin, then apply it to the plant.

NIST’s Digital Twins for Advanced Manufacturing programme makes the missing condition explicit: trustworthy twins need verification, validation and uncertainty quantification.

• Verification asks whether the model was implemented as intended.
• Validation asks whether it represents the real process adequately for the decision being made.
• Uncertainty quantification asks how input and model uncertainty affect the output.

Connection is not validation. A synchronised dashboard can still be a poor representation of the process behaviour that matters.

NIST’s published cyberattack-detection experiment is instructive precisely because its boundary is narrow. Researchers used a digital twin, machine learning and human expertise in a laboratory setting, and a human expert interpreted the final finding. That does not license a general performance claim for production plants. It does show a credible pattern: use the twin to create and compare evidence while retaining domain judgement at the decision boundary.

Before a twin influences production, state:

• the decision it is valid to support;
• the physical variables and dynamics represented;
• the conditions it was validated against;
• the known mismatch and uncertainty;
• the revalidation trigger after process, equipment or control changes.

A twin valid for throughput analysis is not automatically valid for a safety decision.

7. Commission the system, not just the model

A production-readiness review should cover six connected layers.

Process

Name the operational objective, current baseline, owner, affected roles and maximum tolerable consequence. Decide whether the output is advisory or controlling.

Data

Record source, sampling, units, calibration, time synchronisation, missing-data behaviour, operating context, retention and access. Test sensor failure and stale ingestion explicitly.

Model

Freeze the approved model, features and thresholds. Evaluate by operating state, not only across the combined dataset. Keep the cases the system gets dangerously wrong.

Integration

Map every network and application boundary between enterprise IT, analytics and OT. Use narrow interfaces, least privilege and deterministic schemas. Do not give a model-facing runtime broad controller access.

Human operation

Design how an operator sees evidence, uncertainty, age and required action. Train for disagreement, override and outage. Measure automation bias as an operating risk: a human checkpoint is weak if the interface makes approval the easiest unexamined click.

Recovery

Demonstrate isolation, safe-state transition, manual procedure, event reconstruction and revalidation. Run the stop test during commissioning.

The model card is one input to this review. It is not the review.

8. A ninety-day release pattern

For one selected use case:

Days 1-30: observe in shadow. Integrate through a read path, establish data quality, replay historical events and compare output with actual decisions. Do not show recommendations to operators yet if that would change the baseline.

Days 31-60: recommend with review. Expose evidence, envelope and uncertainty. Record accept, reject and reason. Analyse false negatives separately from false positives. Do not let acceptance volume stand in for outcome.

Days 61-90: automate only the bounded residue. Identify the subset with stable performance, low consequence and enforceable rules. Put it behind an independent execution boundary. Keep exceptions at recommend or observe. Run stop, stale-data, tool-failure and recovery tests.

The result may be a small automated envelope and a large recommendation surface. That is a successful commissioning outcome if it puts authority where the evidence supports it.

9. The ladder does not replace engineering authority

The physical consequence and plant design determine the risk class; there is no universal rating for predictive maintenance, inspection or scheduling. NIST’s digital-twin cyberattack work was a laboratory experiment with human interpretation, not production performance evidence.

This framework does not replace functional-safety, quality, cybersecurity or regulatory engineering, and it never assumes that a cloud or enterprise-application connection may write to operational technology. Manufacturing guidance and NIST programme status were checked 26 July 2026 and must be rechecked before revision.

10. The executive agenda

1. Inventory proposed cases and assign each one a control-ladder level.
2. Trace the path from model output to physical consequence, including latency and human behaviour.
3. Name the independent interlock, operating envelope and safe state before write access.
4. Commission data, model, integration, operator response and recovery as one system.
5. Automate only the bounded residue that earns its authority during the first ninety days.

That exercise usually identifies several observation cases that can move now, a smaller recommendation set that needs better evaluation, and very few actions ready for automation. It also stops a document assistant and a process controller being governed as though they were the same system.

Altivate works across manufacturing, supply chain, enterprise data and AI in Saudi Arabia, the UAE, Jordan and India. The aim is not maximum autonomy. It is the maximum useful authority the evidence and independent controls can safely support.

Apply the ladder in manufacturing, or return to White Papers.

Sources and verification status

Checked 26 July 2026.

Public technical guidance – [read]

• NIST Manufacturing Extension Partnership, The Rise of Artificial Intelligence in U.S. Manufacturing – text-only edition
• use categories and barriers; created 13 May 2026. Third-party adoption percentages were not used.
• NIST, Digital Twins for Advanced Manufacturing – verification, validation, uncertainty quantification and standards work. Updated 20 July 2026.
• NIST, How Digital Twins Could Protect Manufacturers From Cyberattacks
• bounded laboratory experiment using a twin, machine learning and human expertise.
• NIST, Cybersecurity for Smart Manufacturing Systems – industrial integration and cybersecurity problem framing.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile – system-level risk and evaluation guidance.