iosys - AI Architecture for Manufacturing SMEs: Four Tiers

An AI project in manufacturing rarely fails because of the model. It fails because of what sits underneath it. This article describes the four tiers we build for manufacturing SMEs, and why the AI comes last.

Key points

Three of the four tiers involve no AI.
The model reads computed facts and nothing else.
A read mirror offloads the ERP and freezes states.
Master data is the entry condition, not a side box.
The fact layer carries most of the value.
A correction becomes a rule in the fact layer.
The feedback loop runs in two directions.
The order of construction decides the payoff.

Where hallucinations are prevented

Fear of invented answers is the objection we hear most often. It is justified, and it usually gets addressed in the wrong place. A language model invents wherever it has to guess.

WHAT THE LANGUAGE MODEL GETS TO SEENot the raw dataorder_line, 46 columnsmachine_event, raw valuespart_master, schema treejoins unverifiedBut computed factsSetup time line 3: up 18 percentMissing part 44-A hits two ordersDue date 12 Aug is at riskWhatever can be described firmly is decided before the model reads.

So it is given nothing to guess at. It sees no tables, no raw values, no schema tree. In front of it lies a short list of statements computed beforehand, which it turns into an answer. Everything that can be described firmly has been decided by that point.

The shape follows from that. Four tiers, built in this order, and the AI is the third.

FOUR TIERS, BUILT IN THIS ORDERSource and mirrorERP and shop floor, read-only copyERP, data lake, master dataFact layerqueries and rules, deterministicKPI engine, business rules, root causeExplain and rankreads the fact layer and nothing elseLLM reasoning, recommendation, actionWorkplaceERP screen, Teams, one listdashboards, alerts, action plans↩ Feedback: workplace to fact layerA contradiction from the floor becomes a rule in tier 2, not an example for tier 3.

Tier 1: source and mirror

In product architectures this is called: ERP, data lake, master data and reference data.

The data comes from the ERP and from shop-floor capture. Between them belongs a copy that is only ever read. Such a read mirror sounds like an accessory and does four jobs at once.

It takes query load off the ERP, so KPI calculation and order entry stop competing for the same server. It freezes states, because a KPI that shifts while it is being read cannot be audited. It preserves history that the ERP overwrites in place. And it is where machine data can sit next to order data.

WHAT THE READ MIRROR ACTUALLY BUYSLoad off the ERPKPI calculation and order entry no longer share a server.States frozenA key figure no longer shifts while it is being read.History preservedThe ERP overwrites in place. The mirror keeps the trail.One place for bothMachine data sits next to order data, with no detour through the ERP.A replica and a handful of views. Days rather than quarters, no semantic model.

That is the core of a data lake without its project size. No semantic model, no governance program, no roadmap. A read-only copy and a handful of views, in days rather than quarters. The mirror only turns dangerous once it acquires a project name.

The Swiss trade journal Aktuelle Technik names such a data foundation as a prerequisite for scaling agent-based architectures (sources). That matches our experience. For an SME, only the size is in dispute.

Master data tends to get treated as a side box in the process. It is the entry condition. Without a clean part and supplier master, the next tier reliably computes the wrong thing.

Tier 2: the fact layer

In product architectures this is called: KPI engine, business rules engine, root cause engine.

These three building blocks serve the same underlying purpose. They turn data into statements: key figures, breached thresholds, likely causes. Technically, that is queries and rules, deterministic and readable.

This is where most of the value sits, and no AI works here. Anyone with a dependable root cause analysis has already solved the expensive part. The tier has to stay auditable, or the entire argument against hallucinations collapses. Determinism is the requirement here, not a side effect.

What such a layer looks like on machine data is described in Ask Your Machines.

Tier 3: explain and rank

In product architectures this is called: LLM reasoning agent, recommendation agent, action agent.

The language model receives exactly one job. It reads the output of the fact layer and says which three findings out of forty matter today, and why. It may not speak about anything tier two did not compute.

That such access needs a grounding of its own is also the subject of institutional research. In its ViPGeniE project, Fraunhofer IPA names a context layer as a requirement for questions about production data to become answerable.

This split between model and fixed tools is described in detail in AI Agents in Order Intake, there for extraction from purchase orders. Whether an AI agent ultimately acts on its own is a question of authorization. Where that line runs is defined in advance.

Tier 4: the workplace

In product architectures this is called: dashboards, alerts, recommendations, action plans.

The last step decides whether the previous three reach anyone's working day. Another dashboard means another login. Output belongs where people already work: in the ERP screen, in Teams, in a single list.

At a Swiss CNC contract manufacturer, order entry fell from 20 hours a week to 2 (case study). The gain came from the result landing in the ERP without a detour. What getting started on such projects looks like is set out in How to Get AI Going in Manufacturing.

The feedback loop runs backwards

Usually, a data store collects outcomes that a model later learns from. That presumes data volumes that a company with forty users never reaches.

The loop can be reversed. When somebody contradicts a recommendation, that contradiction becomes a rule in the fact layer. Every correction therefore moves work out of the model, and the system grows less AI-heavy over time.

We have run this on our own inbox since February 2026. The rules live in a readable file, every change is dated, and a rule can carry an expiry note. A single correction is enough, and no training set is needed.

THE LOOP RUNS IN TWO DIRECTIONSCorrection on reading accuracy becomes an example tier 3, the modeltalk.factorIQ and order intake learn this way, per sender.Correction on a decision becomes a rule tier 2, the fact layerEvery correction takes one decision away from the model.

Why the order matters

First the mirror and the master data, then the fact layer, then the output. The language model comes last, on a factual basis that can be checked independently.

After the first two tiers you already have a useful, auditable system. The remaining risk then sits in the data and the rules. Starting from the other end builds the surface of a system that knows nothing yet. Which AI categories pay off after that is covered in Which AI Tools Pay Off for Manufacturing SMEs?.

Conclusion

Three of the four tiers are classic data work, and they carry most of the value. The AI sits in a narrow spot, with one clear job and no access to raw data. That is exactly what produces a system a production manager can verify.

We build such workflows on top of your existing ERP, without a system change, and on-premises in Switzerland or the EU on request. Arrange a no-obligation conversation if you would like to sort out your own tiers.

More on this: AI agents for manufacturing and automated order processing.

Sources

Fraunhofer IPA, ViPGeniE: AI for machine data, project report on chat access to production data - computer-automation.de
Aktuelle Technik, Wie Agent-First-Architekturen Fertigungslinien flexibler machen, on the data foundation as a scaling prerequisite - aktuelle-technik.ch
iosys blog, Ask Your Machines: Natural Language Access for Your Factory Data - read the article
iosys blog, Which AI Tools Pay Off for Manufacturing SMEs? - read the article
iosys blog, AI Agents in Order Intake: What Works Today - read the article
iosys case example, From 20 to 2 Hours: AI-Assisted Order Entry - read the case study