Silicon Wafer EngineeringReadiness & Transformation Roadmap

AI readiness infrastructure for silicon wafer engineering: the estate an AI decision actually runs on

AI readiness infrastructure is the estate a fab AI decision runs on: the interfaces that lift trace data off a process tool at the rate its control loop needs, the compute placed to meet that loop's deadline, the qualified write path back into APC and MES, and the evidence layer that makes the round trip auditable.

Silicon Wafer Engineering · Readiness & Transformation Roadmap

Atomic Loops EngineeringIndustrial AI practiceReviewed by Atomic Loops Solutions ArchitecturePublished 20 August 202661 min read

Key takeaways

AI readiness in a wafer fab is an infrastructure question before it is a model question. The binding constraints are whether trace data can leave a tool at the rate its loop needs, and whether a decision can get back in through a path that qualification and change control will accept.
The deadline sets the architecture, not the org chart. A run-to-run correction that must land before the next lot cannot be served from a distant region; a yield-learning model that runs weekly has no business consuming cleanroom-adjacent compute. Place each loop's compute against its clock.
Interfaces have published ceilings and they are lower than most plans assume. Semiconductor Engineering reports SECS/GEM delivering roughly 10–20 Hz today against 1 Hz twenty-five years ago, GEM300 topping out near 3 Hz for critical sensors, and real-time plasma arc detection needing 30 kHz — outside current EDA standards and only reachable through OEM log files.
The read side and the write side live under different change regimes. Changing an EDA data collection plan does not require an engineering change notice; changing a recipe parameter through the GEM channel does. An AI loop that ignores that asymmetry gets built and then cannot be switched on.
Future-readiness is almost entirely present-readiness. Every announced AI-factory programme — digital twins, agentic scheduling, GPU estates — still rests on the same four layers: get the data off the tool at rate, place the compute against the deadline, write back through a qualified path, and be able to prove what happened.

Abbreviations used on this page

APC: Advanced process control
R2R: Run-to-run control — a correction applied between runs
FDC: Fault detection and classification
VM: Virtual metrology — a predicted measurement in place of a measured one
EDA: Equipment Data Acquisition, the SEMI “Interface A” standards suite
GEM: Generic Equipment Model (SEMI E30, carried over SECS-II)
MES: Manufacturing execution system
EAP: Equipment automation programme — the fab-side driver that talks to one tool
RMS: Recipe management system
AMHS: Automated material handling system
FMCS: Facility monitoring and control system — the subfab's own estate
CD: Critical dimension — the measured feature width

What AI readiness infrastructure means in a wafer fab

A definition, the four layers it decomposes into, and the round trip an AI decision has to complete before it counts.

AI readiness infrastructure in a wafer fab is the estate a decision physically runs on: the equipment interfaces that publish trace and event data at a stated rate, the transport and context layer that makes that data joinable to a lot and a recipe revision, the compute placed close enough to meet the deadline of the loop being served, the qualified path that writes a result back into APC, RMS or MES, and the network, identity and evidence planes that make the whole round trip defensible to a customer or an auditor. It is not a platform product and it is not a data lake; it is a measured path with a clock on it.

The reason to define it as a round trip rather than a stack is that fabs almost never fail on the outbound half. Collection is a solved, well-standardised problem with a mature vendor ecosystem behind the SEMI standards suite (opens in a new tab). What fails is the return leg — getting a decision back into a control loop through an interface that qualification and change control will accept, fast enough to still be relevant. A sponsored ASMC 2026 tutorial summary published by Semiconductor Engineering (opens in a new tab) puts the same argument bluntly: AI success in semiconductors is structural rather than algorithmic, and more than 70% of initiatives fail to scale beyond pilot. In a fab the structure in question is mostly the return leg.

It is worth separating three things that get blurred whenever “AI-ready fab” appears in a slide deck. What is real today: standards-based collection at tens of hertz, virtual metrology feeding run-to-run, FDC classification holding a wafer, dispatch heuristics against the AMHS. What published research actually claims: that these methods work when the data path meets the loop's timing and context requirements — see the delay-stability analysis of run-to-run controllers and the recent virtual-metrology literature cited later on this page. What remains an announced intention: fab-wide digital twins, agentic scheduling and multi-site autonomy, all of which are credible programmes with dates attached and none of which is a delivered outcome yet. The useful conclusion is unromantic — future-readiness is mostly present-readiness, because every one of those programmes runs on the same four layers a fab either has or does not.

The round trip: from chamber to recipe and back

The path an AI decision has to complete. The outbound half — sensors, tool controller, interfaces, context join — is where most fabs have invested. The return half, into an in-run interlock or a next-lot APC target, is where readiness is actually decided. Most fabs stop in the middle lane.

Data & feeds
Where value leaks
AI / model
System-of-record action
Human in the loop

The process, in words

Outbound, the data leaves the tool by two very different routes. The standardised route runs GEM events and EDA/Interface A data collection plans into the fab plane with equipment metadata attached. The unstandardised route is a parsed tap on the OEM's own log files, which is where the highest-rate parameters live and where every OEM software release is a risk to your pipeline.
In the fab plane, the decisive step is the context join: binding each trace sample to lot, wafer, slot, chamber, recipe revision and process step at collection time. Subfab and facility data — gas, vacuum, DI water, power — usually arrives from a separate estate over OPC UA and is the join most often skipped, which is why utility-driven anomalies so often present as unexplained tool behaviour.
The serving tier is placed against a deadline, not against an org chart. In-run decisions — an FDC classification that holds the next wafer — need compute close to the tool and a deterministic path. Next-lot decisions — an APC or run-to-run target — can be served from a fab-side cluster. Training runs off-site on history, bounded by intellectual-property and export-control rules, and returns a versioned artefact rather than a live dependency.
The return leg is what separates a readiness programme from a monitoring programme. A fab with no qualified write path terminates at an offline report, and everything upstream of it is instrumentation without consequence. A fab with one terminates at an interlock or a target write, then at the recipe of record — versioned, qual-gated and retained, which is what makes the decision defensible months later.

Step-by-step insights

In-situ sensors — the physics sets the rate, not the architecture: Every parameter on a process tool has a characteristic time constant, and the collection rate that makes it useful follows from that rather than from a platform standard. Semiconductor Engineering has quoted James Moyne of the University of Michigan, co-chair of the IRDS factory-integration work, on exactly this trade: catching electrostatic-chuck issues that spark and produce wafer defects needs collection on the order of 2 kHz, while chamber pressure being monitored for a settling point is adequately served at 1 Hz. He is explicit that the common broad-brush approach — 100 Hz on everything — is the wrong answer, because it buys network and storage cost without buying the two or three signals a loop actually depends on. The first real design decision in a fab AI estate is therefore a per-parameter rate table owned by process engineering, not by IT.
The OEM log tap — necessary, unstandardised, and permanently fragile: The parameters with the shortest time constants frequently never appear on a standard interface at all. Boyd Finlay of Tignis, quoted in the same reporting, puts it plainly: log files are never standardised, and yet advanced fabs parse them regularly for higher-speed data and for parameters that GEM300 and Interface A do not publish — laser power intensity at 300 Hz being one example. Treat the log tap as a first-class, owned component with its own tests and its own OEM-release regression suite, because it is the piece of your estate most likely to break silently when a tool is patched. And record, in the change log, which loops depend on it.
The context join — the cheapest step to skip and the most expensive to retrofit: A trace sample without lot, wafer, slot, chamber, recipe revision and step is telemetry; with them it is evidence. Joining afterwards, from timestamps and lot histories, works until clocks disagree, a tool is re-hosted, or a lot is re-worked — and then it fails in a way that is nearly impossible to detect, because the join still produces rows. The SEMI community has recognised the problem sufficiently to publish data-quality standards specifically for it, and the IRDS factory-integration chapter treats big-data veracity, including timestamp accuracy and merging data collected at different rates, as a first-order concern. Join at collection, carry the metadata, and treat a missing context field as a collection failure rather than a nuisance.
Subfab and FMCS — the estate nobody owns end to end: Gas delivery, vacuum, chilled water, DI water and power all sit on the facility side, typically in an FMCS with its own historian, its own protocols and its own maintenance organisation. Fleet anomalies traced back to utility events are a recurring pattern, and practitioners have publicly argued that subfab data should be published through the process tool so that the join to tool identity happens once rather than in every downstream analysis. Until it is, treat the subfab join as a named work item with an owner. Skipping it means a whole class of real, explicable excursions will present to your models as unexplained tool drift.
Placement — the decision that quietly sets every latency budget: Where the serving tier runs determines the fixed floor of your loop's latency, and it is usually decided once, early, by whoever had capacity. In-run decisions cannot tolerate a wide-area hop; next-lot decisions can. Training almost never needs to be near the tool. The practical discipline is to write the budget down per loop — collection, transport, feature computation, inference, write — and to require any placement change to re-measure it before it ships. Fabs that treat placement as a cost-optimisation line rather than a control-loop parameter discover the consequence as a slow rise in missed correction windows that gets attributed to process noise for two quarters.
The return leg — two channels, two change regimes: The asymmetry that catches most programmes is that the read side and the write side are governed differently. Practitioners quoted by Semiconductor Engineering note that an engineering change order is not needed to change a data collection implementation on Interface A, but is needed on the GEM interface — the standards committees separated them deliberately so that equipment command and control would stay stable while engineering data needs changed freely. That is excellent design, and it means an AI loop is a project with two different approval paths inside it. Sequence the write-path approval first: it is the long pole, and a beautiful data path with no accepted return leg is a monitoring system with ambitions.

The five rungs of a fab AI estate

For each rung: what the estate actually looks like, the diagnostic signals a reviewer can check in an afternoon, the anti-pattern that traps fabs there, and what leaving costs in team terms.

The ladder below measures an estate, not an organisation. Each rung is defined by what the infrastructure can physically do — reach data at rate, meet a deadline, write back under change control, prove what happened — so it can be checked against systems rather than against opinions. The hallmarks are observable conditions, the diagnostic signals are checks you can run against your own fab this week, and the anti-pattern is the specific mistake most often made trying to leave that rung.

Select a rung

Every rung's full detail is in the page source — the selector only changes which panel is visible, so nothing here depends on JavaScript to exist.

Stage 1

Tool-tethered

21% of operators sit here

Trace and event data are reachable only at the tool or through a manual export, so every AI attempt starts by building its own pipe.

Rung 1 is not an absence of data — a wafer fab is one of the most instrumented environments in industry. It is an absence of reach. The sensors are sampling, the tool controller is logging, and the information is trapped on the far side of an interface that was configured years ago to run material rather than to explain it. Ask for the last hour of chamber pressure at 10 Hz and the honest answer is that somebody has to go and get it.

The tell is procedural rather than technical. At rung 1 the phrase “can we get that data?” routes to a person, not to a system. The equipment automation team fields extract requests alongside its real job of keeping tools online, so requests queue behind material, and the queue is longest exactly when an excursion makes the data most valuable. Every project therefore begins with two to six weeks of data acquisition that produces nothing reusable, because the extract is shaped to one question and dies with it.

This rung is cheap to leave and expensive to occupy. The cost is not the failed models; it is that nothing amortises. The tenth investigation pays the same acquisition tax as the first, and the fab accumulates a growing archive of one-off CSV files whose provenance — which chamber, which recipe revision, which clock — nobody can reconstruct six months later.

In practice

The excursion nobody could replay

A 200mm fab saw CD drift on one lithography track over three weeks. The process engineer had SPC charts at lot granularity and the tool's own console at second granularity, but no way to line them up: the console buffer had rolled, the MES held only summary values, and the resist-dispense parameters that would have explained it were never collected off the tool at all. The excursion was closed with a preventive maintenance action and a hypothesis. It recurred in the next quarter.

What it looks like

Detailed trace data is viewed on the tool's own console, or exported by a technician on request
The EAP collects enough GEM events to run material, and nothing more
Each analysis project negotiates its own extract with the automation team
Nobody can state the collection rate of a given parameter without asking the OEM

Diagnostic signals you can check this week

Ask for one hour of a named parameter at 10 Hz from a named chamber, and time how long it takes to arrive
Ask who can list, per tool, which parameters are being collected and at what rate — if the answer is the OEM, you are here
Check whether any trace file in your archive carries lot, wafer, slot and recipe revision in its own metadata
Count how many separate extract requests the automation team handled last quarter and how many produced a reusable feed

Anti-pattern · Buying the lake before opening the tap

The instinctive move is a fab-wide data platform programme — an eighteen-month lakehouse with a governance council — on the theory that storage is the constraint. It is not. The constraint is the equipment interface, and no amount of downstream storage changes what a tool is willing to publish. Fabs that build the lake first end up with an expensive, well-governed store of exactly the low-rate summary data they already had. Open one tool class properly, learn what the payload really looks like, then size the store around observed volume rather than a vendor's estimate.

What holds you here

The equipment interface, not the storage layer, is the constraint — data cannot be analysed at a rate it was never published at.

Highest-leverage next move

Stand up a real collection path on one tool class: EDA data collection plans with context metadata, plus a parsed log tap for the parameters the standard cannot reach.

Cost of leaving

Effort: 3–6 months
Team: One equipment automation engineer, one process engineer, part-time
Risk: Low — collection changes on the EDA side do not touch material movement
To next stage: 3–6 months

If this is you, the next step is

A 3-week engagement: pick the fleet, specify the collection plan, prove the payload.

Open one tool class properly

Stage 2

Historised

38% of operators sit here

Data is collected fab-wide into a historian or lake, but the estate is read-only and offline: latency is measured in hours and nothing writes back.

Rung 2 is where most fabs are, and it looks like success from the outside. The feeds exist, the volumes are impressive, the yield engineers have a query surface, and the executive summary can honestly say the fab is data-driven. What it cannot say is that any AI output changed a process, because the estate is architecturally one-directional: data flows outward into storage and analysis, and nothing flows back.

The structural reason is that reading and writing were procured as different problems. Collection was solved by the automation and IT groups as a monitoring project, with success measured in coverage and uptime. Writing into a control loop is a process-engineering and qualification problem, with success measured in Cpk and customer notification, and nobody sequenced the two together. So the fab arrives at rung 2 with excellent plumbing pointed in the wrong direction.

Time at rung 2 is not neutral. Batch latency teaches the organisation that AI answers arrive after the decision, which is true given the architecture and becomes a belief about AI in general. Process engineers stop asking. The next proposal is judged against that memory, and a fab that has sat at rung 2 for four years is usually harder to move than one at rung 1, because the disappointment is institutional rather than technical.

In practice

The overnight model and the morning meeting

A 300mm logic fab built a chamber-health model against two years of historised FDC trace. It scored every chamber nightly and published a ranked list at 06:00. The list was good — it repeatedly flagged chambers that later failed qualification. It also arrived after the night shift had already run four lots through the worst-ranked chamber, because the ranking was computed on data that stopped at midnight and the loop it should have informed runs continuously.

What it looks like

A central historian or data lake ingests trace, event and metrology data across the fab
Analysis runs on scheduled batch jobs, typically overnight
Models are evaluated on history and reported to engineers as charts or files
No AI output reaches APC, RMS or MES through a supported interface

Diagnostic signals you can check this week

Measure the age of the newest record your analysis actually reads, not the newest record your historian holds
Ask which of your AI outputs has a supported interface into APC, RMS or MES — the honest count is usually zero
Check whether trace is joined to lot, wafer, slot and recipe revision at collection time or reconstructed later by a join key
Look at how retention was set: by evidence requirement and loop need, or by storage budget

Anti-pattern · Improving the model to earn the write path

When nothing acts on the output, the reflex is to make the output better — more features, more history, a stronger architecture — on the theory that a convincing enough model will be let into the loop. It will not. The write path is gated by qualification evidence and change control, not by accuracy, and those gates open for a documented revert and a bounded blast radius. Spend the next quarter proving you can write an advisory value into the APC controller and take it back out again in one step, then return to accuracy when you can price a percentage point in CD sigma.

What holds you here

The estate is one-directional. Collection was built as monitoring, and no qualified interface exists to put a decision back into a control loop.

Highest-leverage next move

Pick the single loop with the shortest deadline you can actually meet, place its compute to meet it, and build one qualified, revertible write into APC or MES.

Cost of leaving

Effort: 6–12 months
Team: One integration engineer, one process engineer, a named APC owner
Risk: Medium — the first write into a control system needs a qualification plan and a drilled revert
To next stage: 6–12 months

If this is you, the next step is

The rung 2 → 3 transition is our most common fab engagement. Typically 90 days.

Design the first write path

Stage 3

In-loop

26% of operators sit here

One decision is served inside its control loop's deadline, on compute placed to meet it, through a write path that qualification has accepted and that reverts in one step.

Rung 3 is the first rung where the infrastructure is doing work rather than describing it. One decision — usually a virtual-metrology estimate feeding run-to-run, or an FDC classification that holds a wafer — travels from sensor to action inside a deadline the fab can state and measure. That single closed loop changes the character of every conversation afterwards, because the fab now has an empirical number for what its estate can deliver rather than an architecture diagram.

The discipline that gets a fab here is closer to real-time systems engineering than to data science. What is the budget from sample to decision, and how is it apportioned between collection, transport, feature computation, inference and write? What is the p99, not the mean? What happens on a network partition, and does the controller fall back to its last valid target or to nothing? These questions have well-established answers in industrial control, and importing them is faster than rediscovering them from a machine-learning starting point.

The constraint that emerges is duplication. The first loop is built end to end by one team, with its own collection plan, its own serving host, its own monitoring and its own revert procedure. The second loop, on a different tool class, repeats all of it because nothing was extracted as shared. Capacity is consumed by operating what exists at roughly the third or fourth loop, and velocity falls exactly when the fab has proved the idea works.

In practice

The etch loop that beat the metrology queue

A fab serving automotive parts closed the CD control loop on one etch fleet by predicting post-etch CD from in-situ trace and writing the prediction as an advisory target into the APC controller. Metrology turnaround had been running around two shifts, well outside the controller's useful correction horizon; the predicted value arrived in under two minutes. The process engineer still approved every target change for the first quarter, and the previous measured-CD source stayed one switch away.

What it looks like

At least one loop has a measured, monitored end-to-end latency budget
Serving runs inside the manufacturing network zone rather than on a corporate cloud tenancy
Model output is written to an APC target, a skip-lot decision or an interlock through a supported interface
Revert to last-known-good has been exercised deliberately, not just documented

Diagnostic signals you can check this week

Ask for the p99 sample-to-decision latency of your one live loop; if only a mean exists, the budget is not really managed
Check where the serving host physically sits and which network zone it is in
Ask when the revert to last-known-good was last exercised, and on which shift
Compare the collection plan, monitoring and deployment of loop one and loop two — if they share nothing, the plateau is next

Anti-pattern · Declaring the platform done because one loop runs

A working loop is enormously persuasive, and the temptation is to generalise its architecture into a fab standard immediately. The problem is that one loop teaches you the requirements of one tool class: an etch chamber's trace profile, deadline and revert semantics are not a lithography scanner's or a CMP polisher's. Standardise the contracts — how a collection plan is versioned, how a write is reverted, how latency is reported — and leave the payloads tool-specific until you have three loops to generalise from.

What holds you here

Every loop is built and operated as its own vertical, so the third one costs what the first one did and the team becomes the constraint.

Highest-leverage next move

Extract the shared plane — data contracts per tool class, placement and latency SLOs, a deployment pipeline hooked into fab change control — so the fourth loop is configuration.

Cost of leaving

Effort: 9–18 months
Team: Platform engineer, integration engineer, APC owner, an on-call rota
Risk: Medium — extracting shared contracts competes with demand for the next loop
To next stage: 9–18 months

If this is you, the next step is

We map what in your working loop is genuinely reusable and what is tool-specific.

Review your first loop before you copy it

Stage 4

Fab platform

12% of operators sit here

A shared serving, monitoring and change-control plane carries many loops: one data contract per tool class, per-loop latency budgets, and a security baseline that is standard rather than negotiated per project.

At rung 4 the marginal cost of a new loop collapses, because the expensive parts have been made common. A new decision needs a deadline, a data contract, a placement and a revert; everything else — transport, context join, monitoring, deployment, evidence capture, network admission — it inherits. Fabs at this rung stop talking about AI projects and start talking about which loops are on the roadmap, which is a different and much healthier conversation.

The distinguishing discipline is that change control is inside the platform rather than around it. When a model artefact is promoted, the pipeline emits the record the qualification process needs: which data contract version, which recipe revision, which chambers, which qual lot, which approver. Fabs that bolt evidence on afterwards discover at the first customer audit that the record cannot be reconstructed, and the loop gets switched off pending an investigation that takes a quarter.

The remaining constraint is portability. A platform that works beautifully in one fab is often unrecognisable in the sister site, because tool vintages differ, the network was built by a different team, and the second fab's OEM software was architected in a different decade. Semiconductor Engineering has quoted practitioners noting that some advanced 300mm tool software was first architected in 1997, and that log files — the very place the highest-rate parameters live — have never been standardised. That heterogeneity is what rung 5 is about.

In practice

The roadmap conversation, on a shared plane

A multi-site foundry reached the point where adding a chamber-matching loop on a new deposition fleet took four weeks, of which three were spent agreeing the data contract and the revert semantics with process engineering and one was engineering. The qualification record was generated by the deployment pipeline rather than assembled by hand. That ratio — specification-heavy, build-light, evidence automatic — is the signature of rung 4.

What it looks like

One data contract per tool class, versioned and bound to recipe revisions
Placement and latency budgets are declared per loop and alarmed as service objectives
Deployment runs through a pipeline that produces qualification evidence as a by-product
Segmentation, machine identity and equipment cybersecurity baselines apply by default to every new loop

Diagnostic signals you can check this week

Time from deadline agreed to loop serving, for the last three loops; if it is not falling, the plane is not shared
Whether one monitoring surface covers latency, data availability and model behaviour for every loop
Whether a new loop inherits its network zone and identity, or negotiates them with security
Whether the qualification record for the most recent promotion was generated or assembled

Anti-pattern · Treating placement as a cost line

Once the platform exists, someone will observe that fab-side serving hosts are expensive to run inside a constrained power and space envelope and propose consolidating them into a corporate region. On a spreadsheet it is obviously right. In the loop it silently adds tens to hundreds of milliseconds and a dependency on a link that was never engineered for determinism, and the first symptom is not an outage but a slow rise in missed correction windows that gets attributed to process noise. Placement changes must re-measure the budget before they ship, and the budget belongs in the change record.

What holds you here

The platform is fab-specific. Tool vintages, network topology and OEM software differences mean the second site cannot adopt it without a rebuild.

Highest-leverage next move

Make the estate portable: infrastructure as code, model and contract artefacts versioned with the process of record, and copy-exactly extended to cover the AI stack.

Cost of leaving

Effort: 18+ months
Team: Platform team, process-engineering product owner, qualification and security partners
Risk: Higher — evidence, segmentation and customer notification become the binding constraints
To next stage: 18+ months

If this is you, the next step is

We take one live loop and try to reproduce it on a second tool class from your contracts alone.

Stress-test your platform contracts

Stage 5

Copy-exact

3% of operators sit here

The AI estate travels with the process: declared as code, versioned alongside recipes, and carrying an evidence plane that satisfies customer, qualification and cybersecurity audit without a project.

Rung 5 is narrower than it sounds, and deliberately so. It is not an autonomous fab. It is an estate whose configuration is a versioned artefact rather than an accumulation of local decisions, so a loop qualified at one site can be instantiated at another with a known-identical data path and a comparable latency budget — and so a node transition or a tool refresh does not silently invalidate every model trained on the old configuration.

The hard part here is not engineering. It is the discipline of treating infrastructure state as process state. When a chamber's collection plan changes, that is a change to the input distribution of every model that consumes it, and it belongs in the same change record as a recipe edit. Fabs that keep the two systems separate discover a class of failure that is very difficult to diagnose: model performance degrading in step with an automation change that nobody thought to correlate, because the two live in different tools with different approvers.

This rung is the one most likely to regress, because entropy is cheap and copy-exactness is expensive. A site under pressure makes a local exception, the exception is not written back into the declared configuration, and eighteen months later two fabs that believe they run the same loop do not. The countermeasure is unglamorous: drift detection on the configuration itself, not only on the data.

In practice

The node transition that did not reset the estate

A memory manufacturer moving a product family onto a new node found that its virtual-metrology loops were re-qualified in weeks rather than re-built over quarters, because the collection plans, feature contracts and placement were declared as code and re-instantiated against the new tool set. The models themselves had to be retrained — the physics moved — but the estate they run on did not have to be rediscovered.

What it looks like

Collection plans, placement, contracts and models are declared as code and deployed identically across sites
A model artefact is part of the process of record, versioned with the recipe revision it was qualified against
Copy-exactly discipline extends to the data and serving stack, not only to hardware and recipes
Audit questions about a past automated adjustment are answered by query, not by investigation

Diagnostic signals you can check this week

Whether a collection-plan change appears in the same change record as a recipe change
Whether two sites running the same loop can prove their data paths are identical, rather than assert it
Whether configuration drift between sites is detected automatically or found during an incident
Whether a past automated adjustment can be reconstructed — data, contract version, model version, approver — by query

Anti-pattern · Letting local exceptions live outside the declaration

Every site has a good reason for its exception: an older tool vintage, a different network segment, a supplier that never shipped the EDA freeze version the standard assumes. The mistake is not making the exception, it is keeping it out of the declared configuration because writing it down feels like admitting a compromise. Undeclared exceptions are how two fabs stop being comparable without either noticing. Declare the exception, version it, and put an expiry date on it.

What holds you here

Entropy. Local exceptions accumulate outside the declared configuration until two sites that believe they run the same loop demonstrably do not.

Highest-leverage next move

Put drift detection on the configuration itself — collection plans, placement, contract versions — with the same seriousness you apply to data drift.

Cost of leaving

Effort: Continuous
Team: Platform team plus a standing configuration and qualification forum
Risk: Concentrated — low frequency, high consequence, audit and customer-notification in nature

If this is you, the next step is

We compare the declared configuration with what is actually running, at both sites.

Audit one loop across two sites

Where fabs actually sit on this ladder

The distribution across the five rungs, and why the rung 2 → 3 step is the largest single loss.

Most fabs sit at rung 2 — historised. The collection problem has been solved widely and well, so a large majority of fabs have fab-scale trace, event and metrology data in a historian or lake, and a much smaller minority have any of it travelling back into a control loop inside that loop's deadline. The distribution below is illustrative rather than measured, and it is anchored to the external research named beneath it; treat it as the shape of the market rather than as a census.

Illustrative distribution of wafer fabs across the five rungs

Rung 2 is both the mode and the plateau. The drop from rung 2 to rung 3 — from a read-only estate to one qualified loop that meets its deadline — is the largest single transition loss on the ladder, and it is a write-path problem rather than a modelling one.

Share of fabs

21% — 1 · Tool-tethered
38% — 2 · Historised (the plateau)
26% — 3 · In-loop
12% — 4 · Fab platform
3% — 5 · Copy-exact

Source: Illustrative distribution, synthesised from Semiconductor Engineering reporting on fab data infrastructure and the pilot-stall figure in its ASMC 2026 tutorial summary

The same summary gives a useful sense of scale for what a modern site is generating: a single gigafab producing on the order of 15,000 sensor readings and 95 gigabytes of equipment data every minute, and advanced-node fabs pushing upwards of 2,500 megabits per second. Those are vendor-supplied figures in a sponsored post rather than independent measurements, so treat them as an order of magnitude. Independent reporting by Semiconductor Engineering on fab data streams (opens in a new tab) reaches the same order — fab data generated on the order of petabytes per day across a large site — and is more useful on the point that matters, which is that volume is not the constraint. Reachability at the right rate, with the right context, is.

The plateau at rung 2 is not a semiconductor-specific failure of nerve. It is what happens when collection and control are procured as separate problems by separate groups with separate success criteria. It is worth reading the distribution alongside the equipment-connectivity history (opens in a new tab) and the ongoing manufacturing coverage (opens in a new tab) that tracks it: the interfaces were designed to keep command and control stable while engineering data needs evolved, which is exactly why a fab can be excellent at one and absent at the other.

The clock table: which decision runs where, and why

The centrepiece of this page. Every fab AI decision has a deadline; the deadline dictates the interface, the placement and the readiness gate. Read your row before you design anything.

A fab AI decision runs wherever its deadline allows it to run, and nowhere else. That single constraint decides more architecture than any technology choice: the deadline determines the maximum tolerable transport, which determines placement; the physics of the signal determines the required rate, which determines the interface; and the system that must accept the result determines the change regime the whole loop lives under. The table below is the clock table — the decisions a wafer fab actually wires, ordered from the tightest deadline to the loosest, with the infrastructure each one implies.

Decision	Deadline	Data it needs (rate · interface)	Where compute must sit	Writes to	Readiness gate
Plasma arc and chamber-event detection	Sub-second, inside the run	10–30 kHz in-situ · outside EDA; OEM instrument or log tap	Tool-side appliance in the subfab or on the tool network	FDC interlock	High-rate capture agreed and supported with the OEM
FDC excursion on a running wafer	Seconds, before the next wafer	10–20 Hz trace · EDA / Interface A	Fab-side cluster inside the manufacturing zone	FDC system → EAP hold	Deterministic path with a measured p99, not a mean
Virtual metrology in place of a measurement	Minutes, before the metrology queue decision	Full run trace with context · EDA + MES	Fab-side cluster	APC target + skip-lot logic in MES	Prediction error bounded and monitored against real metrology
Run-to-run target correction	Minutes to hours, before the next lot on that chamber	Post-process metrology + trace features · MES + APC	Fab-side cluster	APC / R2R controller → RMS	Feedback delay inside the controller's stability margin
Dispatch and AMHS scheduling	Every few minutes, continuously	WIP state + E10 equipment states · MES + AMHS controller	Fab-side cluster	Dispatcher / AMHS controller	Complete, current state feed across the whole bay
Predictive maintenance and chamber health	Hours to days	Trace summaries + subfab utilities + maintenance history · EDA + FMCS + CMMS	Fab-side, or off-site if the feed is exportable	Maintenance work order	Subfab data joined to tool and chamber identity
Defect classification and inspection triage	Minutes to hours	Inspection and review images · inspection tool interfaces	Fab-side, GPU-backed	Yield system + engineer disposition	Labelled image corpus with a maintained class definition
Yield learning, DOE and root cause	Days to weeks	Full history: trace, metrology, inspection, test · warehouse	Off-site or cloud, acceptable and often preferable	Engineering record / yield system	Export path cleared for IP, customer data and export control

The clock table for a wafer fab. Rates are the practical ceilings reported by Semiconductor Engineering and by practitioners quoted there; placements follow from the deadline. “Readiness gate” is the thing that must be closed before the row can run at all — not the thing that makes it good.

Two rules fall out of the table and they are worth stating separately. First, the deadline sets the placement. Second, the physics sets the rate, and the rate sets which interface can serve you at all. The second rule is the one that surprises people, because it is not negotiable by architecture: a plasma-arc detector that needs 30 kHz cannot be fed by a channel that tops out at tens of hertz, no matter how the rest of the system is designed. That is a hardware and OEM-agreement problem, and it belongs in the tool purchase conversation rather than in the AI programme.

The run-to-run row deserves particular attention because it is where readiness most often fails invisibly. Run-to-run control is a feedback system, and feedback systems have stability margins that depend on delay. The stability analysis of exponentially-weighted moving-average run-to-run controllers published on arXiv (opens in a new tab) makes the underlying point formally: measurement delay is not merely inconvenient, it changes the stability of the loop. In an operating fab that shows up as a controller tuned conservatively to survive a two-shift metrology turnaround, which is a rational response to a delay and also a permanent tax on capability. This is precisely why virtual metrology is an infrastructure investment rather than a modelling one — the recent graph-attention virtual metrology literature (opens in a new tab) opens by naming measurement latency, cost and sampling constraints as the limits it exists to relieve.

Diagnosing the real constraint on a loop

Plot the deadline of the decision you want to make against how reachable its data actually is at the rate it needs. Three of the four answers are not “build a better model”, and one of them is actively dangerous.

Learning-ready

Rich data, relaxed deadline
The safest place to start and the easiest to fund
Do: yield learning, DOE, chamber-health modelling

Loop-ready

Rate and context meet a tight deadline
Where virtual metrology and in-run FDC belong
Do: place the compute, then build the qualified write

Reporting

Summaries against a slow clock
Honest, useful, and not yet AI readiness
Do: open one tool class at rate before scaling analysis

Blind control

A tight loop fed by data you cannot see at rate
The dangerous quadrant — corrections made on stale inputs
Do: stop, fix reachability, then re-approach the loop

Data reachability at the required rate — top: Streamed at source rate, with context, bottom: Historian extracts and summaries only

Decision deadline — left: Days — yield learning, right: Seconds — in-loop control

Read the row before you scope the model
Almost every stalled fab AI project we see was scoped from the model outwards. Scoping from the clock table inwards changes the first question from “what can we predict?” to “what can we deliver, to whom, in time?” — and that question has a checkable answer.
A row you cannot gate is not a candidate
The readiness-gate column is deliberately blunt. If the OEM will not support high-rate capture, the arc-detection row is closed until the next tool purchase. If your prediction error is not monitored against real metrology, the virtual-metrology row cannot open regardless of backtest performance.
Rows share infrastructure, not deadlines
The FDC row and the virtual-metrology row can share collection plans, a context join and a serving tier. They cannot share a latency budget, because one is bounded by the wafer and the other by the lot. Budgets are per loop; infrastructure is shared.
The bottom row is where cloud belongs
Yield learning, DOE and root-cause work run on days-to-weeks clocks and benefit from elastic compute. That is a good use of off-site capacity, subject to intellectual-property and export-control clearance. It is also the row least likely to justify infrastructure change in the fab itself.

The interface ceiling: what each channel can and cannot carry

Every interface in a fab has a published purpose, a practical rate and a change regime. Designing above the ceiling is the most common single cause of an AI loop that never switches on.

Each channel out of a process tool was designed for a different job, and the differences are load-bearing. SECS/GEM exists to command and control equipment and to report the events that run material; EDA — the SEMI “Interface A” suite — exists to let engineers collect monitoring data at higher rates and change what they collect without touching command and control; OEM log files exist for the OEM's own diagnostics and are not standardised at all. PEER Group's SECS/GEM reference (opens in a new tab) is a good plain-language starting point for the first, and the Semiconductor Engineering reporting on data volumes (opens in a new tab) is the best public account of where the ceilings actually sit today.

Channel	What it exists for	Practical rate	Can it write?	Change regime	What it cannot do
SECS/GEM (E5, E30, E37)	Equipment command, control and event reporting to the MES	~10–20 Hz today; 1 Hz twenty-five years ago	Yes — recipe selection, parameters, control	Engineering change notice required	Carry high-rate diagnostic trace without risking control stability
GEM300 (E40, E87, E90, E94, E116, E157)	300mm automation: jobs, carriers, substrate tracking, state models	Reported to top out near 3 Hz for critical sensors	Yes — job and carrier control	Engineering change notice required	Serve condition-based maintenance signals it was never designed for
EDA / Interface A (E120, E125, E132, E134, E164)	Engineering data collection with equipment metadata and self-description	Higher-rate monitoring; buffering improves in the next freeze version	No — read-oriented by design	No engineering change notice for collection changes	Reach kHz-class signals such as plasma arc detection
OEM log files	The tool maker's own diagnostics	Whatever the OEM logs — e.g. 300 Hz laser power intensity	No	Uncontrolled; changes with OEM software releases	Be relied on across tool vintages without a regression suite
OPC UA from FMCS and subfab	Facility and utility systems: gas, vacuum, DI water, power	Seconds to sub-second, system-dependent	Rarely, and rarely appropriate	Facilities change control, a separate organisation	Arrive pre-joined to tool and chamber identity
MES / historian APIs	Lot history, metrology results, equipment states, WIP	Batch to near-real-time, depending on the product	Yes — dispositions, skip-lot, holds	MES change control plus validation	Provide the sub-second context an in-run decision needs

Interfaces in a wafer fab estate, with the practical rate and change regime each implies. Rates are as reported by Semiconductor Engineering and by the practitioners quoted there; treat them as the working ceiling on a modern fab rather than as a specification limit.

GEM300 is very limiting when it comes to critical tool sensor data, as it tops out at 3 hertz. This is fine for monitoring some tool sensors. However, a lot of the critical sensors require Nyquist measurement methods, which need a higher resolution of sensor data to avoid signal chopping.
Boyd Finlay, director of solutions at Tignis, quoted by Semiconductor Engineering

Two consequences follow that are easy to miss when the interface question is delegated. The first is the change asymmetry already noted: because the standards committees deliberately separated command and control from engineering data, changing what EDA collects does not require an engineering change notice while changing a recipe parameter through GEM does. An AI loop therefore straddles two approval processes, and the slow one is on the return leg. The second is that the ceiling moves — the next EDA freeze version introduces buffering rather than packet-at-a-time delivery, which changes the practical throughput of the channel without changing its role. Design the estate so that a freeze-version upgrade is a configuration change, not a rebuild.

Rate alone is not sufficiency. The SEMI community has published data-quality standards precisely because a fast feed with unreliable context is worse than a slower one with good context: bad rows do not announce themselves, they simply degrade every model that consumes them. The IRDS (opens in a new tab) factory-integration work treats big-data veracity — timestamp accuracy, merging feeds collected at different rates, differing levels of context richness — as a first-order roadmap concern rather than an implementation detail. In practice this means a collection plan is only finished when someone can state, per parameter, its rate, its unit, its clock source, its owner and the loops that depend on it.

Inventory before you architect
Produce, per tool class, a list of which interfaces are actually implemented, at which freeze version, and what the OEM will support. Fabs are routinely surprised: engineers work from assumptions about capability that were true two tool generations ago.
Name the parameters that are only in log files
These are your fragile dependencies. Every loop that relies on one should be listed, and every OEM software update should trigger a regression test on the parse. The alternative is discovering it during an excursion.
Treat metrology and inspection as their own channels
Inspection and metrology platforms from vendors such as KLA (opens in a new tab) have their own data models and their own volumes, especially for image data. Feature-level results and full images belong on different paths with different retention rules.
Include the process tool makers in the design
Etch and deposition platforms from Lam Research (opens in a new tab), lithography systems from ASML (opens in a new tab) and pilot-line research programmes at imec (opens in a new tab) all publish materially different data models. A collection plan written without the OEM in the room usually needs rewriting after the first qualification review.

What infrastructure commitments look like in public

Three publicly reported programmes, read against the ladder. None is an Atomic Loops engagement — each links to the operator's own published material, and where an operator has announced an intention rather than a result, this page says so.

The clearest public evidence for the infrastructure thesis is in what large manufacturers chose to build and to announce. In each case below the differentiating decision was about estate rather than algorithm: where analysis capability physically lives, what it is connected to, and whether it is a site capability or a corporate one. Read them for the shape of the commitment rather than for transferable numbers — every figure here is the operator's own published claim and we have not audited any of them.

Three programmes read against the ladder

Outcomes as published by the operators themselves. Card images are generated industry scenes from our existing library, not photographs of these operators' facilities, and no endorsement is implied. Verify every figure against the linked source before reusing it.

Illustrative fab scene: a wafer-fab bay with overhead automated material handling and a bank of production monitoring displays

GlobalFoundriesGlobal foundry · fabs in the US, Europe and Asia34

Challenge: Scaling analytics capability across fabs in three regions with different tool vintages, where a per-site build would never amortise and per-site results would never be comparable.
Approach: GF publishes a digital-manufacturing programme built around shared capability rather than per-site projects: a proprietary factory control tower described as a virtual fabric monitoring production processes and performance metrics across all of its global manufacturing with 24/7 support from manufacturing hubs, plus a global AI centre of excellence in Singapore whose engineers, analysts and data scientists work with every site to pilot and scale solutions.
Reported outcome: GF reports deploying over 60 smart manufacturing solutions since 2020 using AI, machine learning, IoT and advanced analytics, and states that wafer pattern recognition speeds troubleshooting by up to 10x. In September 2025 the World Economic Forum designated GF's 300mm Singapore fab part of its Global Lighthouse Network.; What it shows about the curveThe rung 4 signature is that capability is a shared plane rather than a per-site asset. A control tower spanning every site, and a centre of excellence that instantiates solutions into each of them, is what makes the marginal cost of the next site's loop fall.

GlobalFoundries — Digital manufacturing (opens in a new tab)

Illustrative fab scene: an engineer reviewing wafer inspection imagery on a multi-screen workstation beside process equipment

MicronMemory manufacturer · global fab network34

Challenge: A process of roughly 1,500 steps taking months per wafer, in which detection depended on human vigilance — Micron notes that people scanning the 30 to 40 photographs captured of each wafer during imaging can miss defects through eye fatigue, and that an undetected cause may affect thousands of wafers before test reveals it.
Approach: Micron describes building sensory AI — computer vision, acoustic listening and thermal imaging — into front-end manufacturing, and scaling it as an enterprise capability across yield analytics, digital-twin planning, IoT and image analytics rather than as isolated tools, powered by what it calls a cloud AI/ML platform intended to scale solutions across its global network.
Reported outcome: Koen de Backer, Micron corporate vice president of Smart Manufacturing and Artificial Intelligence, is quoted in Micron's own case study saying the company can now launch products twice as fast while saving one million work hours annually.; What it shows about the curveThe infrastructure decision here is the platform-versus-tool one. Sensory AI at 1,500 steps is only viable if collection, serving and lifecycle are common; built per step, it would never have been maintained past the first tool generation.

Micron — Smart manufacturing at Micron: AI at enterprise scale (opens in a new tab)

Illustrative fab scene: a cleanroom corridor of process tools with a large operations display showing a virtual model of the line

Samsung ElectronicsIntegrated device manufacturer · memory, logic, foundry and packaging44

Challenge: Extending a single intelligent-manufacturing estate across memory, logic, foundry and advanced packaging operations that historically ran their own systems, and doing it in a way that new sites inherit rather than rebuild.
Approach: Samsung announced an AI Factory programme with NVIDIA built on a stated deployment of more than 50,000 GPUs and on digital twins constructed with NVIDIA Omniverse libraries, and separately announced a strategy to move all manufacturing operations to AI-driven factories by 2030 using digital-twin simulation and purpose-built agents for quality, production and logistics. It reports a 20x gain in computational lithography performance for optical proximity correction using GPU-accelerated libraries.
Reported outcome: Both announcements are commitments with dates attached rather than reported operating results, and this page treats them as such. The verifiable content is the shape of the infrastructure bet: a large, centrally provisioned compute estate, a digital-twin layer connected to MES, and an explicit intention to extend the same estate to new sites including Taylor, Texas.; What it shows about the curveRead announcements as infrastructure commitments, not outcomes. The gap between a declared GPU estate and an installed capability that meets a control loop's deadline is exactly the territory this ladder measures — and it is where a readiness review earns its keep.

Samsung Electronics — AI Megafactory announcement (opens in a new tab)

Two things are worth noticing across all three. First, none of these programmes is described by its operator as a modelling achievement; all three are described as estate decisions — a control tower, a platform, a compute and digital-twin layer. Second, the recognition that follows tends to attach to the estate as well: the World Economic Forum's Global Lighthouse Network (opens in a new tab) assesses deployment and scaling across a site rather than individual use cases, which is why GF's Lighthouse announcement (opens in a new tab) leads on scaling more than sixty solutions rather than on any one of them. Micron's companion write-up on how it uses AI to enhance yield and quality (opens in a new tab) and Samsung's AI-driven factories strategy (opens in a new tab) read the same way, as do GF's ongoing announcements (opens in a new tab).

The reference architecture, layer by layer

What actually has to exist for each rung, which layer you can defer, and the one component that unlocks the write-path approval.

A rung-3 estate needs six layers, and the order in which they are built decides whether the programme compounds or stalls. The architecture below is deliberately vendor-neutral: every layer is defined by what it must guarantee rather than by what product provides it, and each is annotated with the rung that first requires it. A fab attempting rung 3 without the placement and write layers is building a rung-2 historian with extra steps.

Layers of a fab AI estate, annotated by the rung that first requires them

Read top to bottom as the data travels. The layers most often skipped are the second — transport and time — and the fifth's revert component, and both omissions surface later as unexplained model degradation rather than as visible failures.

Tool and subfab edge
Stage 1+
- EAP / GEM driverCommand, control and event reporting per tool
- EDA data collection plansPer-parameter rates with equipment metadata
- OEM log tapFor the parameters no standard publishes
- FMCS / OPC UA feedSubfab gas, vacuum, water and power
→
Transport and time
Stage 2+
- Deterministic collection pathBudgeted and measured, not best-effort
- Time synchronisationOne clock source; timestamp accuracy is a data-quality property
- Buffering and back-pressureSo a slow consumer degrades rather than drops
- Context tagging at sourceLot, wafer, slot, chamber, recipe revision, step
→
Storage and retention
Stage 2+
- Hot trace storeDays, at full rate, for loop debugging
- Warm feature storeMonths, computed features with versioned definitions
- Cold archiveYears, driven by the evidence requirement
- Retention policy per parameter classSet by evidence and loop need, not by storage budget
→
Compute placement
Stage 3+
- Tool-side applianceFor in-run deadlines measured in seconds
- Fab-side clusterFor next-lot loops and inspection triage
- Off-site trainingHistory-scale work, IP- and export-bounded
- Per-loop latency budgetDeclared, measured at p99, alarmed
→
Write and change control
Stage 3+
- APC / R2R target writeThe next target on that chamber
- MES disposition and skip-lotWhere the decision is about material, not process
- Revert to last-known-goodOne switch, drilled, with a named owner
- Qualification gateQual lot, versioned artefacts, customer notification where required
→
Security, identity and evidence
Stage 4+
- Zones and conduitsThe serving tier is not on the flat tool network
- Equipment cybersecurity baselineAligned to SEMI E187/E188 and IEC 62443 practice
- Machine identity and brokered accessEvery write is attributable to a service, not a shared account
- Decision and lineage recordData version, model version, policy, approver — retained and queryable

Pipeline described

Tool and subfab edge (stage 1+) — EAP / GEM driver: Command, control and event reporting per tool; EDA data collection plans: Per-parameter rates with equipment metadata; OEM log tap: For the parameters no standard publishes; FMCS / OPC UA feed: Subfab gas, vacuum, water and power
Transport and time (stage 2+) — Deterministic collection path: Budgeted and measured, not best-effort; Time synchronisation: One clock source; timestamp accuracy is a data-quality property; Buffering and back-pressure: So a slow consumer degrades rather than drops; Context tagging at source: Lot, wafer, slot, chamber, recipe revision, step
Storage and retention (stage 2+) — Hot trace store: Days, at full rate, for loop debugging; Warm feature store: Months, computed features with versioned definitions; Cold archive: Years, driven by the evidence requirement; Retention policy per parameter class: Set by evidence and loop need, not by storage budget
Compute placement (stage 3+) — Tool-side appliance: For in-run deadlines measured in seconds; Fab-side cluster: For next-lot loops and inspection triage; Off-site training: History-scale work, IP- and export-bounded; Per-loop latency budget: Declared, measured at p99, alarmed
Write and change control (stage 3+) — APC / R2R target write: The next target on that chamber; MES disposition and skip-lot: Where the decision is about material, not process; Revert to last-known-good: One switch, drilled, with a named owner; Qualification gate: Qual lot, versioned artefacts, customer notification where required
Security, identity and evidence (stage 4+) — Zones and conduits: The serving tier is not on the flat tool network; Equipment cybersecurity baseline: Aligned to SEMI E187/E188 and IEC 62443 practice; Machine identity and brokered access: Every write is attributable to a service, not a shared account; Decision and lineage record: Data version, model version, policy, approver — retained and queryable

Step-by-step insights

Tool and subfab edge — build the inventory before the plan: The single most useful artefact at this layer is not code, it is a per-tool-class inventory: which interfaces are implemented, at which freeze version, what the OEM supports, and what the practical rate is on your network rather than in the specification. Fabs consistently discover that assumptions here are one or two tool generations out of date, and that two nominally identical tools from the same OEM expose different parameter sets because they shipped under different software releases. Every downstream design decision inherits the errors in this inventory, so it is worth two weeks of somebody's undivided attention.
Transport and time — the layer that is invisible until it is wrong: Time synchronisation and context tagging are the least glamorous items in this architecture and the two that most reliably determine whether a model is trainable. If the trace clock and the metrology clock disagree by seconds, features computed across the boundary are quietly wrong in a way that no validation split will catch, because the error is systematic rather than random. Back-pressure matters for a related reason: a collection path that silently drops under load produces gaps that look like process events. Make both properties measurable, alarm on them, and treat a context-tagging failure as a collection outage rather than a data-cleaning task.
Storage and retention — the evidence requirement sets the floor: Retention in a fab is not a cost-optimisation question, it is a qualification question. If a customer in an automotive or medical supply chain can ask you to explain a wafer processed eighteen months ago, then the data, model version and approval that produced any automated adjustment on that wafer must still exist. Set retention per parameter class against that requirement first, then optimise the remainder. Fabs that set retention from the storage bill discover the gap during an audit, at which point the answer is an investigation rather than a query.
Compute placement — write the budget down, then defend it: The placement layer exists to make an implicit decision explicit. For each loop, state the budget: collection, transport, feature computation, inference, write, with a p99 for each and a total that fits inside the deadline from the clock table. Then require any change — a consolidation, a migration, a network re-segmentation — to re-measure the total before it ships. The failure mode this prevents is the slow one: a placement change that adds a hundred milliseconds and produces no incident, only a gradual rise in missed correction windows that gets attributed to the process for two quarters.
Write and change control — the revert is the political key: The component most often deferred is revert to last-known-good, and it is the one that unlocks everything else. It reads as engineering pessimism and it is actually the argument that gets the write-path approval through the change board, because process engineering will accept a new input source it can remove in one action on a bad shift. A write proposal without a drilled revert sits in a queue for two quarters; one with a revert that has been exercised on a quiet shift and documented tends to move. Build the revert first, demonstrate it, then ask for the write.
Security, identity and evidence — a serving tier is a new computer on your network: An AI serving tier with a route to production equipment is exactly the kind of asset the SEMI cybersecurity standards were written for. E187 sets baseline requirements for fab equipment computing devices across operating-system support, network security, endpoint protection and security monitoring; E188 addresses malware-free integration when equipment and service devices arrive on site. Neither standard is about AI, and both apply to it. Treat segmentation, machine identity and the decision record as standard inclusions in every loop rather than as a security review at the end — retrofitting identity to a loop that already writes into APC is materially harder than designing it in.

The security layer deserves a specific note because it is where an AI programme most often collides with an existing fab discipline. The SEMI cybersecurity standards — E187, E188 and E191, summarised by PEER Group (opens in a new tab) — exist because a factory is most at risk in two places: when an infected tool is delivered and integrated, and when a tool goes unmaintained and becomes vulnerable over time. PDF Solutions' summary of E187 (opens in a new tab) sets out its four domains — operating-system support, network security, endpoint protection and security monitoring — all four of which an AI serving tier touches. For the wider network architecture the ISA/IEC 62443 series (opens in a new tab) remains the reference for zones and conduits, and the NIST AI Risk Management Framework (opens in a new tab) is a workable structure for the model-governance half that fab standards do not cover.

A 90-day plan: closing the metrology delay on one etch fleet

The rung 2 → 3 transition made concrete on one wafer-fab problem — predicted post-etch CD reaching the run-to-run controller before the next lot, instead of two shifts later. Contains no model development.

Moving one rung takes about 90 days when it is scoped to a single loop on a single fleet, and several years when it is scoped to a fab. To make that concrete, the plan below runs the transition on a specific and very common problem: post-etch CD measured on a sampled basis with a metrology turnaround of roughly two shifts, feeding a run-to-run controller whose correction horizon is far shorter than that. The controller is therefore tuned conservatively to stay stable against the delay, and the fab pays for it in CD sigma and rework. The quarter below contains no model development at all — most rung-2 fabs already have a virtual-metrology model that performs on history. What they do not have is a path that delivers it in time and a write that qualification accepts.

Rung 2 → rung 3 on one etch fleet, in one quarter

One fleet, one product family, one named owner in process engineering. If a phase needs longer than its window, narrow the scope — fewer chambers, one product — rather than extending the plan.

Days 1–20
Measure the clock you actually run on
Pick one etch fleet and one product family. Measure, do not estimate: metrology turnaround distribution, sample-to-decision latency for the existing loop, and the controller's current feedback delay and stability margin. Record the CD sigma, rework rate and metrology-hold time you will be judged against. Name the process engineer who owns CD on that fleet as the loop owner.
A measured latency budget and a baseline nobody disputes
Days 21–45
Open the data path at rate, with context
Specify EDA data collection plans on the fleet's chambers for the parameters the model needs, at rates chosen per parameter rather than blanket. Tag lot, wafer, slot, chamber, recipe revision and step at collection. Add the parsed log tap for anything the standard cannot reach, and list which loop depends on it. Join the relevant subfab flow and pressure signals from the FMCS to chamber identity.
Trace at rate, with context, for one fleet
Days 46–70
Place the compute and prove the revert
Stand the serving tier up inside the manufacturing network zone, not on a corporate tenancy, and measure the end-to-end p99 against the budget from phase one. Write the predicted CD into the APC controller as an advisory target with process-engineer approval on every change. Then exercise the revert to the measured-CD source deliberately, on a quiet shift, and write down how long it took and who did it.
A qualified, revertible write path with a measured budget
Days 71–90
Qualify, attribute and record
Run the qualification lot. Hold out comparable chambers on the unchanged loop so the difference is attributable rather than asserted. Report CD sigma, rework rate and metrology-hold time against the holdout — not model accuracy. Produce the evidence record: data contract version, model version, chambers, qual lot, approver. That record is what makes loop two cheap.
A CD sigma delta and a reusable evidence record

The order matters

Rate before model
A mediocre prediction delivered inside the correction window changes more targets than an excellent one delivered after it. Fix reachability and placement first; revisit model quality when you can price an accuracy point in CD sigma rather than in validation error.
Revert before write
Build and demonstrate the one-switch revert to the previous source before you ask for the write-path approval. It is the argument that gets the change through, and it is the difference between a proposal that ships in a quarter and one that queues for two.
One fleet before one fab
Extract shared contracts when the second and third fleets are already asking for the same collection plans and the same revert semantics. Generalising from a single fleet encodes one tool class's peculiarities as fab architecture, and unpicking that costs more than the duplication would have.
Evidence as a by-product, not a phase
The qualification record should fall out of the deployment pipeline rather than being assembled at the end. Fabs that assemble it discover at the first audit that a field is missing, and the loop is switched off pending an investigation that takes longer than the build did.

Two notes on generalising this plan. Etch is a good first choice because the in-situ signals are rich, the metrology delay is usually the binding constraint, and the correction is a target rather than a material disposition — so the blast radius of an error is bounded and reversible. Lithography is harder to start with because overlay and CD control are already tightly engineered and the approval surface is larger; inspection is harder because the payload is images and the labelling problem is its own programme, which is why work on training defect detectors on synthetic data (opens in a new tab) is an active research direction. If you want to see how far in-situ time-series can be pushed once the path exists, the recent work on wafer-level etch spatial profiling from in-situ signals (opens in a new tab) is a good indication of what becomes possible when the data actually arrives — and a reminder that none of it is reachable from a nightly historian extract.

Proving the infrastructure, not the model

Where each readiness measurement actually comes from — the read, the source system, the cadence — plus the seven-item check that separates a rung-3 estate from a well-run historian.

An infrastructure claim you cannot name a source system for is an opinion. Every measurement below reduces to timestamps, counts and configuration records that your collection layer, serving layer, MES and change system already hold — the work is joining them, not creating them. The table is the build sheet: the read, where it comes from, how often to take it, and the rung at which it first measures something real.

Measurement	How to read it	Source	Cadence	Honest from
Parameter reachability	Parameters collected at their specified rate ÷ parameters a loop declares it needs	Collection plans + serving config	Per change	Rung 1
Context completeness	Trace rows with full lot/wafer/slot/chamber/recipe tags ÷ all trace rows	Collection layer	Continuous	Rung 2
Feed freshness	Now − timestamp of the newest record the loop actually reads	Serving layer	Continuous	Rung 2
Sample-to-decision latency (p99)	Decision-available timestamp − source-sample timestamp	Serving log + collection log	Per decision	Rung 3
Budget compliance	Decisions inside the declared budget ÷ all decisions in that loop	Serving log	Continuous	Rung 3
Write acceptance	Advisory values accepted by the engineer ÷ values presented	APC / MES approval log	Weekly	Rung 3
Revert time	Elapsed seconds from decision-to-revert to previous source live	Drill record	Quarterly drill	Rung 3
Time to next loop	Deadline agreed → loop serving, elapsed days	Delivery tracker	Per loop	Rung 4
Evidence reconstruction time	Elapsed time to answer “what produced this adjustment?” for a random past write	Decision and lineage record	Quarterly exercise	Rung 4
Configuration drift between sites	Declared configuration items differing between two sites running the same loop	Configuration store	Continuous	Rung 5

Instrumentation build sheet for a fab AI estate. “Honest from” is the rung at which the measurement starts describing something that exists; below that rung it will produce a number, but the number will not mean anything.

Three of these deserve to be run as deliberate exercises rather than as passive metrics. The revert drill, the evidence reconstruction and the configuration comparison all measure something that only exists under pressure, and all three reliably surprise the teams that run them for the first time. A revert that is documented but never exercised takes three times as long as anyone expects; an evidence reconstruction that is assumed to be a query turns out to require three systems and a person who left.

Rung 3 readiness check

If you cannot tick all seven, your estate is at rung 2 regardless of how well any model performs on history. Tick as you go — this list works without JavaScript.

Every parameter feeding an AI decision has a stated collection rate and a reason for itOwned by process engineering, reviewed when the recipe changes.
The end-to-end latency of your most time-critical loop is measured, not estimatedAt p99, continuously, against a written budget.
Trace carries its context join at collection timeLot, wafer, slot, chamber, recipe revision and step — not reconstructed later.
The write path into APC, RMS or MES is qualified and reverts in one stepAnd the revert has been exercised on a real shift, not just documented.
Model artefacts are versioned against the recipe revision they were qualified on
The serving tier sits in a documented network zone with brokered accessNot on the flat tool network, and not on a shared account.
One past automated adjustment can be reconstructed end to end from retained records

0 of 7 ticked

Nothing ticked yet — that is a rung-1 or rung-2 estate, and it is a normal place to start

Most fabs can genuinely tick one or two of these, not zero. If none apply, do not start with tooling: pick one fleet and run the 90-day etch plan above. Every item on this list falls out of doing that once, on one tool class, properly.

Scope the 90 days with us

Failure modes that send an estate backwards

Infrastructure maturity is not monotonic. Five regressions account for almost all of it, and every one is silent by design.

Estates regress, usually without anybody noticing, because the conditions that sustained a rung quietly stopped holding while the system carried on producing output. That is what makes infrastructure regression more dangerous than model regression: a degraded model produces visibly worse predictions, while a degraded estate produces confident predictions on inputs that are no longer what they claim to be. Five patterns account for most of it.

Likelihood: highImpact: high

The collection plan drifts out of the recipe

A recipe revision changes step timing or adds a step, and the data collection plan that was written against the previous revision keeps collecting on the old boundaries. Features computed per step are now computed over the wrong windows. Nothing errors; the model simply gets quietly worse in a way that correlates with a change nobody thought to look at.

PreventionBind the collection plan version to the recipe revision in the same change record, and fail the promotion if the pair is inconsistent.

Likelihood: highImpact: medium

A tool is refreshed and the loop silently loses its highest-rate parameter

An OEM software update, a chamber replacement or a hardware revision changes what the tool publishes. Because the loop's other inputs still arrive, the pipeline does not fail — it imputes, or the feature quietly becomes constant. This bites hardest on parameters that came from the log tap, which has no contract behind it.

PreventionMonitor availability per parameter per chamber and alarm on absence, not only on value; regression-test the log parse on every OEM release.

Likelihood: mediumImpact: high

The serving tier is consolidated off the manufacturing network

A rational-looking infrastructure consolidation moves serving to a corporate region. Latency rises by tens to hundreds of milliseconds and the path stops being deterministic. There is no outage — just a rising share of decisions that miss their correction window, which reads as process noise for two quarters.

PreventionMake the latency budget a change-gate: any placement change re-measures p99 against the declared budget before it ships.

Likelihood: mediumImpact: high

Retention is trimmed and the audit window goes with it

Storage cost review cuts trace retention from months to weeks. Six months later a customer asks about a wafer, and the data that would have explained the automated adjustment no longer exists. The loop is suspended pending investigation, which is a two-rung regression triggered by a spreadsheet.

PreventionSet retention per parameter class from the evidence requirement first and optimise the remainder; make the evidence owner an approver on retention changes.

Likelihood: highImpact: high

Equipment patching stalls because tools cannot be taken down

The serving tier and the tool-side collectors fall behind on operating-system and dependency patching because every window is a production window. Over a year the AI estate becomes the least-maintained computing on the manufacturing network, which is precisely the risk the SEMI cybersecurity standards were written to address.

PreventionAgree a lifecycle and patching plan with the OEM at purchase, aligned to E187 practice, and treat serving-tier maintenance windows as part of the tool's PM schedule rather than as IT work.

Four of the five share a structural property worth naming: they are failures of a contract that was never written down. The collection plan had no declared relationship to the recipe; the log parse had no contract with the OEM; the placement had no declared budget; the retention had no declared evidence requirement. Writing those four contracts down is a week of work and it is the cheapest insurance available against a regression that will otherwise be diagnosed as process noise. For the vocabulary of what a fab AI decision is, and how a matched tool fleet behaves once the estate exists, the companion page on autonomous tool fleets in silicon wafer engineering picks up where this one stops.

Glossary

Hover a term for its definition — or expand the map full screen. The full definitions are written out below.

SECS/GEM: The SEMI standards suite (E5, E30, E37) through which a fab commands and controls equipment and receives the events that run material. It is the write channel for recipe and control changes, and changes to it require an engineering change notice.
EDA / Interface A: The SEMI Equipment Data Acquisition suite (E120, E125, E132, E134, E164) built for engineering data collection with equipment self-description and metadata. Deliberately separated from SECS/GEM so that collection can change freely without destabilising command and control.
Data collection plan: The configuration that tells a tool which parameters to publish, at what rate, and against which triggers. In a mature estate it is a versioned artefact bound to the recipe revision it was written against, not a setting somebody adjusted once.
EAP: The equipment automation programme — the fab-side driver that speaks to one tool over SECS/GEM, handles its state model and carries material instructions. It is the component that ultimately holds a wafer when an interlock fires.
Latency budget: The written apportionment of a loop's deadline across collection, transport, feature computation, inference and write, each with a p99 target. Its absence is the reason placement decisions get made on cost rather than on capability.
Placement: Where a loop's serving compute physically runs — tool-side, fab-side or off-site. Placement sets the fixed floor of a loop's latency and is usually decided once, early, by whoever had capacity.
Context join: Binding each trace sample to lot, wafer, slot, chamber, recipe revision and process step at collection time. Reconstructing it later from timestamps works until clocks disagree or a lot is reworked, and then fails silently because the join still returns rows.
Virtual metrology: A predicted measurement produced from process trace in place of a physical one. In infrastructure terms it is a latency instrument: its value comes from arriving inside the control loop's correction window, which physical metrology often cannot.
Run-to-run control: Feedback control that adjusts the target for the next run from the results of previous runs. Because it is a feedback system, its stability depends on the delay in the measurement path — which is why metrology turnaround is an infrastructure parameter, not an inconvenience.
Last-known-good: The previous valid source or target that a loop reverts to when the model is disabled, together with the single action that performs the revert. Its absence is the most common reason a write path is refused by process engineering.
Zone and conduit: The segmentation model from the ISA/IEC 62443 series: assets grouped into zones by risk, with all traffic between them passing through defined conduits. An AI serving tier with a route to production equipment belongs inside this model, not beside it.
Evidence record: The linked, retained set of facts behind one automated adjustment: data contract version, model version, policy or threshold version, chambers affected, qualification lot and approver. At rung 4 it is generated by the pipeline; below that it is assembled by hand, if at all.

Frequently asked questions

The questions fab engineering and automation teams ask most often when they start treating AI readiness as an infrastructure problem.

What is AI readiness infrastructure in a wafer fab?

It is the estate an AI decision physically runs on: the equipment interfaces that publish trace and event data at a stated rate, the transport and context layer that makes that data joinable to a lot and recipe revision, the compute placed to meet the loop's deadline, the qualified path that writes results back into APC, RMS or MES, and the network, identity and evidence planes that make the round trip defensible. It is a measured path with a clock on it, not a platform product. Collection alone is monitoring, not readiness.

Do we need a fab-wide data platform before we start?

No, and building one first is the most reliable way to spend a year without closing a single loop. The constraint at the bottom of the ladder is the equipment interface, not the storage layer, and no amount of downstream capacity changes what a tool is willing to publish. Open one tool class properly — collection plans at chosen rates, context tagged at source, a log tap where the standard cannot reach — then size the platform around the payload you have actually observed rather than around a vendor estimate.

How fast can I actually get data off a process tool?

It depends on the channel and it is lower than most plans assume. Semiconductor Engineering reports SECS/GEM delivering roughly 10 to 20 hertz today, up from 1 hertz twenty-five years ago, with practitioners noting GEM300 topping out near 3 hertz for critical tool sensors. EDA/Interface A was designed for higher-rate engineering collection. Anything in the kilohertz class — real-time plasma arc detection is cited at 30 kHz — sits outside current standards and is reachable only through OEM instrumentation and log files.

Where should the compute for a fab AI model sit?

Wherever the loop's deadline allows, and nowhere further. In-run decisions that must act before the next wafer need tool-side or bay-side compute on a deterministic path. Next-lot decisions such as run-to-run corrections and virtual metrology are comfortably served from a fab-side cluster inside the manufacturing network zone. Training on history, yield learning and root-cause analysis run on days-to-weeks clocks and are good candidates for off-site or cloud capacity, subject to intellectual-property and export-control clearance.

Why is the write path harder than the data path?

Because they live under different governance. The SEMI committees deliberately separated command and control from engineering data collection, so changing what EDA collects does not need an engineering change notice while changing a recipe parameter through the GEM channel does. The return leg therefore runs through qualification, change control and sometimes customer notification. That asymmetry is why a fab can have excellent collection and no AI in any control loop, and why write-path approval should be sequenced first, not last.

How does metrology delay affect run-to-run control?

It changes the stability of the loop, not just its convenience. Run-to-run control is feedback, and feedback systems have stability margins that depend on delay — the published stability analysis of EWMA run-to-run controllers makes the point formally. In an operating fab it shows up as a controller detuned to survive a long metrology turnaround, which is a rational response and a permanent tax on capability. That is the specific gap virtual metrology exists to close, and why it is an infrastructure investment rather than a modelling one.

What does the 90-day rung 2 to rung 3 transition actually involve?

One fleet, one product family and one named process-engineering owner. Twenty days measuring the real clock — metrology turnaround, sample-to-decision latency, controller stability margin — and baselining CD sigma and rework. Twenty-five opening the data path at chosen rates with context tagged at source. Twenty-five placing the serving tier inside the manufacturing zone and drilling the revert. Twenty qualifying against a holdout and producing the evidence record. No model development: at rung 2 the model usually already performs on history.

How does SEMI E187 apply to an AI serving tier?

E187 sets baseline cybersecurity requirements for fab equipment computing devices across four domains — operating-system support, network security, endpoint protection and security monitoring — and E188 addresses malware-free integration when equipment and service devices arrive on site. An AI serving tier with a route to production equipment is exactly that kind of asset. Neither standard mentions AI and both apply to it. Design segmentation, machine identity and monitoring in from the start: retrofitting identity to a loop already writing into APC is materially harder.

Can we run fab AI in the cloud?

Partly, and the clock table tells you which parts. Training on history, yield learning, DOE and root-cause work all run on days-to-weeks deadlines and benefit from elastic capacity, subject to intellectual-property, customer-data and export-control clearance. In-run and next-lot control loops cannot be served across a wide-area hop without breaking their latency budgets. The usual mature answer is hybrid by deadline rather than by policy: train off-site, serve in-fab, and require any placement change to re-measure the budget before it ships.

How much data should we retain, and for how long?

Set retention from the evidence requirement first, then optimise what is left. If a customer in an automotive or medical supply chain can ask you to explain a wafer processed eighteen months ago, then the data, model version and approval behind any automated adjustment on that wafer must still exist. Practically that means retention set per parameter class rather than fab-wide: full-rate trace hot for days, computed features warm for months, and the evidence record archived for the qualification window your customers actually impose.

What is the difference between AI readiness and a digital twin programme?

A digital twin is a consumer of the estate this page describes, not a substitute for it. Twins are only as current and as trustworthy as the feeds and the context join beneath them, and a twin fed by nightly historian extracts will faithfully model yesterday. Read announced twin and agentic-manufacturing programmes as infrastructure commitments with dates attached rather than as delivered capability, then ask the same four questions of them: what rate, what placement, what write path, what evidence.

Our fab runs 200mm tools from the 1990s. Is any of this reachable?

Yes, with a different shape. Older tools frequently support SECS/GEM but not the EDA suite, so the practical path is a combination of GEM event collection, an instrumented log tap and, where the physics demands it, added external sensing on a bay-side collector. Practitioners have publicly noted that some advanced 300mm tool software was first architected in 1997, so vintage constraints are not unique to legacy fabs. The clock table still governs: choose rows whose deadlines your achievable rates can actually serve.

About the author

Atomic Loops Engineering

Industrial AI practice

Atomic Loops builds production AI systems for semiconductor, manufacturing and energy operators — equipment-data pipelines, virtual metrology, drift and matching models, run-to-run control and inspection — integrated into the MES, APC and recipe layer rather than delivered as dashboards.

· Equipment-integration work against SECS/GEM and EDA/Interface A interfaces
· Latency-budgeted serving placed against real control-loop deadlines
· Integration-first delivery: qualified write paths, revert to last-known-good, retained evidence
· 28 cited sources on this page

Sources

Readiness and transformation roadmap for silicon wafer engineeringThe sibling topics in this cell — phasing, benchmarks, funding and the readiness audit instrument itself.AI-driven disruptions and innovations in silicon wafer engineeringWhat a matched, self-tuning tool fleet does once the estate underneath it actually exists.Silicon wafer engineering practiceProduction AI systems Atomic Loops has built for semiconductor manufacturers — trace pipelines, virtual metrology and control integration.

Find out what your estate can actually carry — then close one gap

We walk one tool class from sensor to recipe with your automation, process and security leads, measure the latency budget instead of estimating it, and leave you with a marked-up architecture and a costed 90-day plan for the layer that caps you. You keep both whether or not we build it.

Book an infrastructure review See our semiconductor work

Published 20 August 2026 · Last updated 20 August 2026

Key takeaways

Abbreviations used on this page

Score your fab's AI estate

What AI readiness infrastructure means in a wafer fab

The five rungs of a fab AI estate

Tool-tethered

Historised

In-loop

Fab platform

Copy-exact

Where fabs actually sit on this ladder

The clock table: which decision runs where, and why

The interface ceiling: what each channel can and cannot carry

What infrastructure commitments look like in public

The reference architecture, layer by layer

Tool and subfab edge

Transport and time

Storage and retention

Compute placement

Write and change control

Security, identity and evidence

A 90-day plan: closing the metrology delay on one etch fleet

The order matters

Proving the infrastructure, not the model

Failure modes that send an estate backwards

The collection plan drifts out of the recipe

A tool is refreshed and the loop silently loses its highest-rate parameter

The serving tier is consolidated off the manufacturing network

Retention is trimmed and the audit window goes with it

Equipment patching stalls because tools cannot be taken down

Glossary

Frequently asked questions

What is AI readiness infrastructure in a wafer fab?

Do we need a fab-wide data platform before we start?

How fast can I actually get data off a process tool?

Where should the compute for a fab AI model sit?

Why is the write path harder than the data path?

How does metrology delay affect run-to-run control?

What does the 90-day rung 2 to rung 3 transition actually involve?

How does SEMI E187 apply to an AI serving tier?

Can we run fab AI in the cloud?

How much data should we retain, and for how long?

What is the difference between AI readiness and a digital twin programme?

Our fab runs 200mm tools from the 1990s. Is any of this reachable?

About the author

Sources

Related reading

Find out what your estate can actually carry — then close one gap