30 fourteen-second explainers

What does an MES actually do that the ERP cannot? It knows where every lot is, right now, and what is allowed to happen to it next. The basics: • ERP plans in months, weeks and days. Orders, materials, cost, delivery. It has never heard of a lot. • MES runs in shifts, hours and minutes. Which lot, which step, which recipe, which tool. • The tool reacts in milliseconds. The MES tells it what to run and records what it did. One lot, three answers (illustrative): ERP: order 8812, 500 wafers, due in six weeks. MES: lot 4471, step 212 of ~900, recipe rev 7, on ETCH-03, queued since 14:02. Tool: chamber pressure, sampled many times a second. Ask "where is my order right now?" and only the middle one can answer. The number: 93% of manufacturers run an MES. Only 23% have it fully integrated with ERP and the plant systems (Rockwell Automation survey of 1,560 decision-makers, July 2026). To be fair, those time horizons are the ISA-95 framing as vendors summarise it, and the survey covers all industries, not fabs. What I keep coming back to is that "just do it in ERP" fails for a boring reason: the two systems run on different clocks. Merge them and one clock stops. Where does your plant's "where is it right now?" question actually get answered: the MES, a spreadsheet, or a person walking the floor?

When a lot goes on hold, what actually happens to it? Nothing, and that is the point. The MES refuses to let it take its next step until a named person signs one of four exits: release, rework, scrap or split. The basics: • A hold is a refusal, not a pause. No tool, no operator, no move until it is cleared. • Holds are placed automatically or by hand: an SPC point out of control, a failed inspection, an engineer's doubt. • Disposition is the exit. Release it, rework it, scrap it, or split the bad wafers off. Signed, with a reason, on the record. Worked example (illustrative): Step 212, the SPC chart flags lot 4471's line width out of control. The MES holds the lot in seconds. Review: 3 of 25 wafers are outside the limit, 22 are fine. Disposition: SPLIT. Three wafers go to rework, 22 are released. Signed by the process owner, reason recorded. The number: one 3 nm wafer is priced at roughly $18-20k (analyst figures via Tom's Hardware and TechPowerUp), so a 25-wafer lot is about $450-500k. That is what a wrong disposition costs. The hold itself costs hours. To be fair, wafer prices are estimates that scale with the node, and the reported hold-decision times of days to a week come from a test house, not a fab. What I keep coming back to is that hold response time is cycle time a fab chooses to spend, and almost nobody trends it. Does your MES report how long lots sit on hold waiting for a signature, or only that they were held?

If a predictive maintenance model watches every sensor on a tool, why does the fab still go down unexpectedly? Because tool downtime and fab downtime are not the same thing, and a third of the second one starts below the floor. Semiconductor capital equipment loses at least 8% of its time to unscheduled downtime and about another 7% to scheduled maintenance. That is what a tool-sensor model is trained on, and it is a reasonable thing to model. But roughly 30% of fab downtime is attributed to utility systems. Power quality. Vacuum. Chilled water. Gas delivery. Abatement. Those live in the sub-fab, report to facilities rather than to the MES, and frequently are not even on the same historian. The tool is fine. What the tool needed was not. A single tool failure is costed in the range of 100,000 to 500,000 dollars per hour of lost output, and predictive programmes report up to 30% less downtime where the signal is actually visible to them. To be fair, these are industry-reported ranges rather than audited fab figures, and downtime attribution depends entirely on where a given fab draws the line between tool and facility. What I keep coming back to is the second-order damage. Downtime that began at a pump gets logged against the process tool, so the equipment record slowly fills up with failures the equipment never had - and the next model gets trained on exactly that. Has anyone actually pulled facilities data into an equipment health model, and did the false-alarm rate go down or up?

Your tools have been connected to the host for fifteen years. So why is there no data to train a model on? Because being connected and being collected are two different things, on two different channels. SECS/GEM is the control and event channel. Lot started. Step complete. Alarm set. Alarm cleared. It collects when an event fires, typically somewhere in the 1-10 Hz range. That is exactly the right design for running a fab, and exactly the wrong design for characterising a chamber. SEMI added EDA - Interface A - as a parallel high-volume channel, built for the trace data that fault detection, wafer-level APC and equipment health actually need. GEM did not go away. The two run side by side and answer different questions. One published EDA interface specification requires at least 5,000 parameters at a 0.1 second interval. That is 50,000 parameters per second aggregate, with five clients pulling at once. A GEM-only tool cannot feed a trace-based model at any price. To be fair, that figure is one published specification example rather than a universal SEMI requirement, and what any given tool exposes depends on the supplier, the freeze version and what was actually purchased. What I keep coming back to is how easily this gets misdiagnosed. A fab can be fully connected, fully automated, and still have nothing a model can learn from - and that gets written up as a modelling problem when it is a data-readiness problem with a purchase order attached. Has anyone actually costed the EDA retrofit on an older tool set, and did the business case survive it?

Is a lot just a box of 25 wafers? No — and that distinction turns out to be load-bearing rather than pedantic. There are three units in play, and they answer three different questions. The FOUP is the physical carrier: what actually moves. Under SEMI E47.1 a 300mm FOUP holds 25 wafers at 10mm pitch. That is what the AMHS schedules and the loadport docks. The LOT is the MES unit of record: what gets tracked. Route position, holds, disposition, priority, genealogy. When a lot goes on hold, no physical object changed — a record did. The WAFER is the unit of yield: what gets measured. Bin maps, defect counts, parametric results. Yield does not happen to a lot. It happens to a die, on a wafer. And these three come apart constantly. Lots split for engineering splits and merge again. A carrier can hold a partial lot, or wafers from more than one. Sampling means a handful of wafers carry measurements the rest never had. To be fair: 25 is the standard FOUP capacity, not a law about lot size. Lot sizing is a fab policy decision. What I keep coming back to is that traceability built on "the lot" as an atomic thing starts quietly lying to you the moment a lot splits. Genealogy has to survive the split, or it is a filing convention. For anyone who has migrated a fab's traceability model: did split and merge survive intact, or did you find out later that it had not?

"Is the tool up or down?" It is the most common question on a fab floor, and SEMI E10 says it is the wrong shape. E10 defines six mutually exclusive states covering every minute of an observation period: Non-Scheduled, Unscheduled Down, Scheduled Down, Engineering, Standby, and Productive. Only the last one is making product. "Up or down" collapses all six into two. The two that get conflated most are the two that matter most for a decision. Scheduled Down is a maintenance window you chose. Unscheduled Down is E10's definition of a failed equipment system. Same red light on most dashboards, completely different conversations. The state I find most interesting is Standby: a tool that is fully able to run and has nothing to run. No lot, no operator, no qualified recipe, or the material has not arrived. Not broken, not producing. To be fair: E10 defines the six states and how to measure them. It never defines how big each one should be, and there is no standard target split — anyone quoting you one is quoting a fab, not a standard. What I keep coming back to is that most utilisation arguments are denominator arguments. One person means Productive over Total Time, another means Productive over Uptime, and the numbers cannot reconcile. When your fab quotes utilisation, does everyone in the room agree which states are in the denominator?

When someone asks how far back your traceability goes, is that actually the right question? The number that decides your containment is not how far back it goes. It is how fine it goes. Genealogy is not a report you pull when something goes wrong. It is a graph built continuously as the lot moves - which tool, which chamber, which recipe revision, at what second. Containment can only ever be as narrow as that graph is fine. If the history names the tool but not the chamber, then when a defect surfaces at a customer, every lot through that tool in the window is suspect. On a six-chamber cluster that is roughly six times the scope - same defect, same window, six times the material to account for. The retention clocks are longer than most people outside quality realise. GM's supplier requirements have production part records kept 15 calendar years after the last vehicle is built. Some design records run production plus 50, with review. IATF 16949 sets a floor, and customer-specific terms routinely go well past it. To be fair, the 6x figure is illustrative arithmetic for a six-chamber tool, not a measured statistic - and keeping the bytes is the easy half. The hard half is reading them back. Fifteen years is two MES migrations, a naming convention that changed, and a tool that got decommissioned. What I keep coming back to is that retention is a storage question and reconstructability is a schema question - and almost nobody budgets for the second. You cannot improve a genealogy record retroactively. Resolution is set at write time, often before the product now in trouble existed. Has anyone actually been through a containment where the record turned out finer than expected and it genuinely saved you?

If a lot is on the schedule, why isn't it the next one into the tool? Because a schedule is a plan for the shift, and a dispatch is the pick made the second a tool goes idle. Different decisions, and the second one can overrule the first. The basics: • Scheduling looks ahead: hours to a shift. Which lots should reach which tools, given what is coming. • Dispatching looks at now. A tool just freed up. Of the lots in front of it, which one goes in? • The dispatch rule makes the pick: FIFO, critical ratio, due date. The rule moves cycle time more than the plan does. Worked example (illustrative): 06:00, the shift plan says ETCH-03 runs lot A, then B, then C. 14:02, ETCH-03 goes idle early. B is stuck two bays back. C is at the loadport with 40 minutes of queue-time left. The dispatcher takes C now instead of waiting for B. The plan was right this morning. The pick is right now. The number: in Yoon & Kim's 2013 simulation study, a smarter dispatch rule cut cycle-time variance by 45-59% against plain FIFO. Against an already-good due-date rule, the gain was only 4-8%. To be fair, that is a simulated fab, not a measured one, and every fab's rule set is different. What I keep coming back to is that the money is in the second number: the rule at the idle tool matters far more than the planning screen above it. Which rule does your fab actually run at the idle tool, and does anyone know who last changed it?

If every wafer is inside the spec, why would SPC put a lot on hold? Because the spec is the customer's line and the control limit is the process's. In spec means this wafer is fine. In control means the process behind it is still behaving. The basics: • Spec limits come from the customer: what the product must meet. Automotive buyers write Cpk 1.33-1.67 into the contract. • Control limits come from the data: the process mean plus or minus 3 sigma, where a stable process lands 99.73% of the time. • Out of control inside spec is the alarm that matters. The wafer passed. The process changed. Worked example (illustrative arithmetic): Customer spec on a line width: 20.0 ± 1.5 nm, so 18.5 to 21.5 passes. The process runs at sigma 0.3, so its control limits are 19.1 to 20.9. A wafer reads 21.1: in spec, out of control. SPC holds the lot and the tool is checked today. Wave it through because "it passed", and the next lot lands at 21.6. Out of spec. Scrap. The number: a process that only just fits its spec (Cpk 1.0) ships about 2,700 out-of-spec parts per million. At Cpk 1.33 that drops to 63. At 1.67, to 0.57. To be fair, those ppm figures assume a centred, normal process, and adding Western Electric run rules cuts the false-alarm run length from about 370 points to about 90. What I keep coming back to is that "it passed" is a statement about one wafer, and "it moved" is a statement about the next thousand. When your SPC chart flags a point that is still inside spec, who actually decides whether the lot moves?

Your defect count went up this week. Is the process worse, or is the recipe just more sensitive? The count on its own genuinely cannot tell you - because a defect found is not yet a defect. Optical inspection is tuned to miss nothing, which necessarily means flagging a great deal that is not there. Surface roughness and film-thickness variation both produce interference effects that read as defects. On complex or highly reflective patterns, reported overkill runs above 20%, and false-alarm rates of 40 to 70% before review are reported. Those flags are candidates, not findings. High-resolution SEM review is reported to separate real defects from nuisance at around 95% accuracy, and ML-based classification is what removes the nuisance population at volume - with reported post-classification false rates of 5 to 10%. To be fair, those bands come from vendor and single-study reports rather than an independent benchmark, and every one of them moves with the layer, the recipe and the inspection setup. Models also degrade on data drift across production batches, which is its own problem. What I keep coming back to is the trap underneath the trend line. Because the count moves with recipe sensitivity, trending raw detections means you are partly trending your own inspection settings. A tightened recipe and a degrading process look identical on that chart. Has anyone actually rebaselined a defect trend after an inspection recipe change - or does the old chart just quietly keep running?

If a wafer defect model reports 99% accuracy, how good is it actually? Possibly fourteen points better than saying nothing at all. WM-811K is the public wafer map benchmark. It holds 811,457 maps from about 46,000 production lots - and only 172,950 of them carry a label at all. Roughly 85% of those labelled maps belong to the single no-defect class. So a model that answers "no defect" to every wafer it is ever shown scores about 85% before it has learned anything. Published results of 96.6%, 98.4% and 99.2% are real, but they are measured against that floor, not against zero. And the classes that matter operationally are the rare ones. A scratch. An edge ring. A localised cluster. Headline accuracy is almost completely insensitive to getting those wrong - a model can lose most of the scratches and still report 97%. To be fair, WM-811K is one manufacturer's dataset and its label mix is not every fab's, and the published numbers use different splits, augmentation and class subsets, so they are not really comparable with each other either. What I keep coming back to is how much work the word "accuracy" is doing in a slide. Ask what the model beats, not what it scores. Per-class F1 and balanced accuracy tell a much less flattering story, which is probably why they are quoted less often. Has anyone actually had a defect model pass acceptance on headline accuracy and then miss the excursion that mattered?

When yield drops and the analysis names one tool, how sure should you be? Less sure than the ranking makes you feel. A correlated tool is not a guilty tool. Every wafer passes through roughly 800 to 1,200 process steps, and a fab generates terabytes of sensor data a day. Split a low-yield population by tool at every step and something will rank first. It has to. That is arithmetic, not evidence. Worse, routing is not random. Tools co-occur because of how lots are dispatched, so a chamber can turn up in every bad lot simply because it shares a queue with the one that actually did the damage. Three things a correlation cannot supply: a physical mechanism, timing that brackets the excursion, and a route the good lots did not take. The screening itself is genuinely useful - Random Forest or XGBoost pulling the top twenty variables out of tens of thousands, with vendor accounts reporting analysis dropping from three to five days down to hours. To be fair, that time reduction is a vendor account rather than an independent benchmark, and step counts vary widely by node and product. What I keep coming back to is the cost of skipping the confirmation step. You requalify an innocent tool, you lose its capacity for a week, and the real excursion carries on running the whole time. The model narrows where to look. It does not tell you what broke, and it was never going to. Has anyone actually had a commonality hit survive a proper split-lot confirmation - or did it usually fall over?

What is the hardest question in recipe management? Not "what is the recipe." It is "which version ran on this lot?" — asked eighteen months later. Here is the scale that surprised me. A fab running 100 products across 300 process steps manages 30,000+ active recipes. A single etch recipe on its own can carry 50 to 200 parameters. Multiply that out and recipe management stops sounding like document control and starts sounding like configuration management for a system where a wrong value is measured in scrapped lots. The concept holding it together is the Process-of-Record — the golden recipe. Of every revision that has ever existed for a step, exactly one is approved and active, and that is the one the MES downloads to the tool when the right material shows up. Every other revision is history you are obliged to keep. To be fair: both counts are vendor figures for a fab of that shape, and they scale hard with product mix. There is also a widely repeated claim that recipe errors cause 30% of yield excursions — it is vendor-sourced and I could not find an independent basis for it, so I would not lean on it. What I keep coming back to is that writing the recipe was never the hard part. Process engineers are good at that. Reconstructing which version ran, on a lot that split, on a tool requalified twice in between, is where recipe management either earns its budget or quietly reveals it never had one. How far back can your fab actually reconstruct the exact parameter set for a specific lot at a specific step?

What is the most expensive thing on a fab line that never touches a wafer? The photomask. And it is usually managed like stock. Here is the shape of it. A complete mask set for a leading-edge design at 5nm or 3nm runs to 60–100 individual masks and costs somewhere between $5M and $15M. A single EUV mask blank — the raw substrate, before anyone writes a pattern on it — is over $350,000. Every layer then needs its own writing, inspection, repair and qualification cycle before it goes near production. Now put that next to the product. A 25-wafer lot at 3nm is roughly $500,000 of wafers. So one mask set is worth something like ten to thirty lots — and unlike a lot, you cannot simply start another one tomorrow. That ratio is my own arithmetic on two published figures, not a number anyone publishes, but the order of magnitude is the point. To be fair: those are leading-edge numbers. At mature nodes a mask set is dramatically cheaper and the whole calculus changes. EUV also brings shorter reticle lifetimes, so replacement becomes recurring rather than one-off. What I keep coming back to is why it gets treated as logistics: the mask never appears in the yield conversation. It is not consumed, it does not show up in a bin map. So what gets tracked is where it is, when what needs tracking is its condition and its qualification state. Where does your fab hold the authority to release a reticle back into production after an inspection finding?

If a fault-detection system gets more sensitive, does it catch more? Reading the published work, it mostly catches more of nothing. Rule-based FDC fires when a single sensor crosses a single limit. That is why it fires so often, and why so few of those trips are excursions. A chamber can drift and stay in spec. A sensor can be noisy. A recipe can have a step that is legitimately spiky. Each one crosses a line without anything being wrong. ML-based FDC models the whole multivariate trace instead — the shape of the run, not one point on one channel. Reported false-alarm reductions run 60–70%, and one recent study reports a rate under 0.1% at an F1 of 0.94. To be fair: those are vendor and single-study numbers, not an independent benchmark, and they move enormously with the tool, the recipe, and how you define an excursion in the first place. What I keep coming back to is that everyone reports detection rate, and the number that decides whether the system survives its first month is the false-alarm rate. An alarm nobody opens is not a detection. It is a queue — and once a team learns the queue is mostly noise, the real excursion sitting in it gets treated exactly like the rest. Has anyone here replaced a rule-based limit set with a model and actually won the operators' trust back? I would like to know how long that took.

When a tool goes idle, does the lot at the front of the queue run next? Almost never. The dispatcher does not read the queue - it rebuilds it. Slack against the due date. Remaining process time. Whether this lot completes a batch. Whether the reticle it needs is already loaded. Whether the step downstream is about to starve. Five inputs, recomputed in the second the tool frees up. FIFO ignores all five. What makes this matter is where the time goes. At an x-factor of 3 to 4, where many fabs genuinely run, 60 to 75% of cycle time is queue rather than process. The tool is not the scarce thing. The decision about who gets it next is. To be fair, the fix is not simply to stop running FIFO. Due-date rules like Critical Ratio beat FIFO on tardiness, but only inside a band. Set the target flow factor too tight at high load and CR degrades worse than FIFO does - cycle time and its variance both blow out. And a rule tuned purely for due dates will happily hold a lot straight through its queue-time window and scrap it to protect a date. These are simulation results, and at low utilisation there is no queue to sort at all. What I keep coming back to is that dispatching and Q-time control pull against each other permanently, and somebody has to arbitrate. That is not a solved problem you buy. It is a standing judgment call - and it is often left sitting exactly where it was last tuned, for a product mix that no longer exists. Has anyone actually gone back and re-tuned a dispatch rule after the mix changed? I would like to hear how you built the case for it, and what it cost you to prove it.

Ask what actually destroys a lot in a wafer fab and most answers involve a broken tool. What if it is a clock? Between certain process steps there is a maximum time a wafer is allowed to wait, and missing it is far more expensive than a breakdown. Clean a wafer and the surface starts reoxidising almost immediately. So the next step has to begin inside a window - and that window is set by a process engineer protecting yield, not by a planner protecting schedule. What makes it brutal is what happens on a miss. The lot is not simply late. It goes back to the FIRST step of the sequence, or it is scrapped outright. That rework then burns capacity on the entry tool, which means every other lot queuing for that tool just got slower. One missed clock, and the whole fab pays. And the lot is most exposed exactly when it is most valuable, with two months of processing already sunk into it. One documented example: critical gate-oxide runs had to begin within 30 minutes of the preceding clean and HF dip. To be fair, windows vary enormously by process, layer and fab. Thirty minutes is one real published case, not a universal rule - treat it as scale, not as spec. What I keep coming back to is that this is the part of MES no dashboard makes look exciting, and that almost nobody outside the fab has heard of. It is also where the money quietly leaves. When a Q-time window is about to expire on a valuable lot, what actually happens - does the system hold the tool automatically, or does someone get a phone call and start negotiating with the next area?

As AI starts making calls on the shop floor, what actually changes about MES? It stops being the thing that decides, and becomes the thing that records who was allowed to. A model output is advisory until something grants it authority. The published guidance splits that authority into three tiers. Advise: a human approves before any system action executes. Approve: the agent acts inside defined parameters and logs every decision for review. Execute: autonomous action within thresholds somebody set in advance. Each tier needs its own limit, audit log and escalation path - picked before deployment, not after the first disputed call. This lands on MES because MES already holds the pieces: the state model, the hold and disposition path, genealogy, the electronic signature. Gartner projects at least 15% of day-to-day work decisions made autonomously by 2028, up from none in 2024. Separately, it expects over 40% of agentic AI projects to be cancelled by the end of 2027 - attributed to cost, unclear business value and inadequate risk controls. To be fair, both of those are projections rather than measurements, and the cancellation figure is about governance and economics rather than the technology failing. What I keep coming back to is that those two numbers point the same way. The deployments that survive will be the ones that can answer who decided, under what limit, and on what evidence. That is an MES question, and it always was. Has anyone actually written decision rights into an MES workflow for an AI recommendation - or is it still a person quietly deciding whether to trust it?

If virtual metrology gives every wafer a measurement, can you stop measuring so many wafers? That is exactly the trap. Virtual metrology is inference, and its anchor is the sampling you were about to cut. Metrology is a tool, a queue and a cycle-time cost, so fabs measure a sample - scheduled audit sampling typically sits somewhere in the 1-5% range. Virtual metrology closes the gap by predicting the measurement from the process trace the tool already produces. Every wafer carries an inferred value. Cross-step models, which use upstream context rather than one step in isolation, report around 37% lower RMSE than single-step models, and hybrid physics-plus-ML is becoming the default build rather than a research curiosity. But every VM prediction is calibrated against real metrology. The sampling is not overhead the model removes. It is the reference the model depends on. Cut sampling because VM is working, and you have removed the only signal that would tell you it has stopped working. To be fair, the 37% figure is a single reported comparison rather than a fab-wide result, and RMSE measured against sampled metrology is not the same thing as accuracy against truth. What I keep coming back to is how quiet that failure is. A drifting VM model does not go blank or throw an error. It keeps producing a confident number for every wafer, and it produces it faster than anyone can check it. Has anyone actually reduced metrology sampling on the strength of a VM model - and how did you decide where the floor was?

Should a language model be allowed to draft a process flow? Draft, yes. Approve, never - because fluent and feasible are different properties, and only one of them is being checked. Reading the published work, the failure mode is consistent. These models reason over fab operations with real fluency. They will draft a flow and suggest an integration sequence that reads exactly like something an engineer wrote. Then the specifics fall over. Steps the installed toolset cannot execute. Sequences that violate thermal budget or contamination constraints. Parameters sitting outside the qualified process window. Nothing in the generation checks any of that. Plausibility and feasibility are simply not the same computation. The fix in the literature is to couple the model to a process-rule and process-window checker that filters its output inside the loop, not in a review meeting afterwards. The model supplies the search heuristic; the constraint supplies hard feasibility. On general planning benchmarks, success under hard constraints rises from 27.7% to 49.2% once feasibility is prioritised. To be fair, those two rates come from general LLM planning benchmarks rather than fab process flows - no public benchmark yet measures how often an unconstrained model produces an infeasible semiconductor flow. Read them as the shape of the problem, not as a number for your fab. And 49.2% is the honest part of that story. It is better. It is nowhere near release quality. Has anyone actually put a hard process-window check between a generative tool and anything that reaches an operator?

If you can predict the failure, have you solved maintenance? Not yet. Predicting it is the easy half. A prediction has to land inside a window. Too early and you throw away good remaining life on a part that was fine — a maintenance saving converted into a maintenance cost. Too late and it is not predictive maintenance at all, it is an unscheduled down that may have taken a lot with it. The width of that window is set by things the model cannot see: whether the spare is on site, whether the crew is free, and whether there is a slot where taking that tool down does not simply move the queue somewhere worse. The published ranges are worth holding onto. McKinsey puts predictive maintenance at up to 50% less equipment downtime and 10–40% lower maintenance cost. For semiconductors specifically, when it is applied to a bottleneck, roughly 70–80% of the improvement converts into overall fab effectiveness. To be fair: the McKinsey ranges are cross-industry, and the case studies quoting 70%+ downtime reductions are vendor-published. Directional, all of them. What I keep coming back to is that last figure being conditional. On a bottleneck, most of the gain reaches the fab. Off the bottleneck, a perfect prediction on a tool that was never the constraint buys a tidier maintenance calendar and very little else. Programmes get scoped by which tools have good sensor data, when they should be scoped by which tools are constraints. For anyone who has run PdM in a fab: which way did you scope it, and did you get to redo it?

If a recipe never changes, why does the process drift? Because the recipe is the only thing holding still. The equipment moves underneath it. Chambers season run after run. Consumables wear. Electrodes erode. Ambient conditions shift. Nobody changed a parameter, and yet the tool you qualified has slowly become a different tool. Run-to-run control is the answer, and it is almost embarrassingly simple in concept: measure the run that just finished, adjust the run that has not started. Usually through an EWMA filter, so it responds to a trend rather than chasing the last noisy measurement. The published results are worth knowing because they are specific rather than promotional. An APC system on poly-gate critical dimension took photolithography rework from 12% to 2%. A run-to-run controller on Si trench etch depth moved Cp/Cpk from 1.10/0.83 to 1.39/1.34. An EWMA controller on metal sputter deposition improved process capability by about 10%. To be fair: three separate deployments, each one process on one toolset, published by the people who did them. Examples, not an industry average. What I keep coming back to is that control does not remove variation — it stops variation accumulating. An uncontrolled process does not wander randomly around target. It walks, and every run inherits the last run's error. For anyone running R2R: what actually broke it for you? From what I have read, metrology delay seems to matter more than the controller.

How much of an AI dispatching result actually survives contact with a real fab? Reading through the published work, the honest answer looks like: not much. On the public benchmarks — Minifab, SMT2020 — reinforcement learning earns double-digit improvements in tardiness. Run the same class of method against a real industry fab dataset and it lands at up to 4% on tardiness, and up to 1% on throughput. The more I read about it, the less I think that gap is about the algorithm. A real fab is re-entrant. Hundreds of tools, qualification constraints, linked queue-time windows, hot lots reordering everything behind them. The benchmark models a fraction of that, so the policy that won it learned a much smaller world. To be fair: that is one 2025 study, one dataset, one set of objectives. A 2025 review of RL dispatching also finds the literature thin on validation and deployment guidance for real facilities. What I keep coming back to is that 4% on a real fab is not a failure. It might be a very good year. The failure is budgeting for the benchmark number and then calling a genuine 4% disappointing. Has anyone here taken an ML dispatcher past simulation and into a live dispatch path? I would like to know what the number looked like on the floor.

If a model can predict something in the fab accurately, should it also be the thing that decides it? Accuracy is the wrong test. The question is what happens when the model is wrong. Some fab decisions are cheap to undo. Dispatch ranking, maintenance ordering, a virtual metrology estimate between two real measurements - get one wrong and the next cycle corrects you. That is where a model earns its keep. Others are the record itself. A safety interlock has to reach a safe state on a single foreseeable fault - SEMI S2 asks it to be fault-tolerant, not usually right. Genealogy is what an audit and a recall containment get reconstructed from years later. Recipe release has to be reproducible by someone who was not in the room. And a model's output is a probability conditioned on its training data. Retrain it and you can no longer re-derive the answer it gave last March. Fine for a suggestion. Not fine for a system of record. The numbers: between 5% and 33% of AI initiatives reach real production value - 5% is MIT NANDA counting measurable P&L impact, about 33% is McKinsey counting anything past the pilot. Gartner expects over 40% of agentic AI projects cancelled by end-2027. To be fair, those are three different measures of three different things and none is fab-specific. SEMI S2 governs equipment safety, not MES software. The argument is from what these functions require, not from a standard saying no ML here - because none does. What I keep coming back to is that most failed industrial AI projects did not fail on model quality. They failed because a model got pointed at a decision that needed an audit trail. Has anyone actually got a model into a disposition or release path and kept it auditable - and how did you handle the retrain problem?

Why do MES replacements go wrong when the new software works fine? Because the software was never the project. The fab's memory is: routes, recipe versions, hold rules and years of lot history, all of which have to move while the fab keeps running. The basics: • The install is not the project. What moves is everything the old system knew. • The failure modes are old and known: change management, data migration, an inexperienced team, no sponsor, no training. • There is no downtime to hide in. A fab runs 24/7, so the cutover fits a two-week shutdown or runs beside the live system. A real example: LFoundry in Avezzano, a 40,000 wafer-a-month fab, replaced the MES it inherited from its Micron days. What had to survive the move, per the vendor's case study: millions of transactions a day, terabytes of data, 99.999% uptime, and 7 years of lot history kept online for automotive customers. The number: there is no published MES-specific failure rate. The closest proxy is ERP, where Panorama's 2026 report puts 68% of projects short of their objectives, with poor data migration behind 38% of the failures. To be fair, ERP is not MES, and the LFoundry write-up gives neither a timeline nor a cost. What I keep coming back to is that nobody has ever been surprised by the software. Everybody is surprised by what had to move with it. If you have been through an MES migration, what was the thing nobody had written down until cutover week?

If material is arriving late, does adding vehicles to the AMHS fix it? Past a certain point it does the opposite. A faster vehicle is not a faster delivery. An overhead hoist system is a shared track network, not a pool of independent couriers. Vehicle count strongly drives average delivery time - right up until the track saturates. After that, each additional vehicle adds contention rather than capacity, and delivery time turns around and climbs. Dense track networks in large fabs bottleneck at junctions, and static routing has no way of seeing the jam it is feeding lots into. What moves the number is structure and routing. Double closed-loops with shortcuts are adopted in 300mm fabs precisely because they cut contention structurally. Dynamic link-weight control reports 11.34% lower delivery time than a reinforcement-learning benchmark, and local FOUP buffers are credited with 15-20% more move-rate capacity. To be fair, the 11.34% is one algorithm against one benchmark in a published study rather than a fab result, and the buffer figure is a design claim. Both depend completely on layout, loading and vehicle count - an AMHS near saturation behaves nothing like one that is not. What I keep coming back to is that congestion is a property of the network. You cannot buy your way out of it one vehicle at a time, and the attempt is capital, permanent, and makes the underlying problem worse. Has anyone actually seen delivery time get worse after vehicles were added - and how long did it take to work out why?

Why do so many manufacturing AI projects look brilliant in the demo and then quietly disappear? Because a pilot proves the model works. Production proves the plumbing does. A pilot runs on a slice chosen because it was clean: one line, one product, data somebody hand-checked the week before, and one engineer who knows the model personally. Production has none of that. Every product, every shift, tools that get requalified, sensors that get replaced, and nobody whose actual job is to notice the model has gone stale. The model was never the expensive half. Ingestion, monitoring and retraining are - and none of them exist yet on the day the demo lands. The numbers I keep reading: 48% of manufacturers are piloting AI, 10% have it integrated into operations. Pilot-to-production failure is reported around 88%, and Gartner expects 60% of AI projects to be abandoned through 2026 because the data underneath them was never made AI-ready. To be fair, those are analyst and survey aggregations rather than audited counts, and "fully integrated" means whatever the respondent decided it means. What I keep coming back to is that this reads as an engineering gap, not an enthusiasm gap. The pilot budget buys a model. Almost nobody budgets for the pipeline that has to feed it at three in the morning on a Sunday. Has anyone actually carried a manufacturing AI pilot all the way into daily operations - and what broke first when you did?

When a lot scraps, what did it actually cost? Not the wafers. That is the floor, not the loss. A 300mm wafer at 3nm runs around $20,000 in current foundry pricing. At 28nm it is around $3,000. A lot is 25 wafers. So the raw material in that carrier is somewhere between roughly $75,000 and $500,000 depending on node. But value accrues into a lot step by step. Every clean, deposition, litho pass and metrology check adds cost you have already spent and cannot recover. A lot that dies at the third step costs you almost nothing but the wafers. A lot that dies just before final test has absorbed nearly the entire flow — hundreds of steps of tool time, consumables, reticle exposures, queue time — and the wafer price is a rounding error against it. Which is why "we scrapped a lot" is a sentence with no information in it. The step it died at is the number. To be fair: those wafer prices are August-2026 foundry figures and contract pricing varies a lot with volume. How steeply value accrues across a specific flow is fab- and product-specific. What I keep coming back to is the part that never makes the cost conversation: cycle time. You can buy replacement wafers tomorrow. You cannot buy back the twelve weeks that lot had already spent in the line. Does your scrap reporting carry the step it died at as a first-class field, or does it get reconstructed later from genealogy?

If the OEE number on the wall is climbing, are more wafers leaving the building? Not necessarily - and that gap is the whole problem with treating OEE as a score. OEE is not a measurement. It is a product: availability times performance times quality, three numbers collapsed into one - and the one tells you less than the three did. Push any single factor and the headline moves. The 85% target traces back to Seiichi Nakajima's TPM work in the 1970s. It decomposes as availability at or above 90%, performance at or above 95% and quality at or above 99.9% - which multiplies to about 85.4%. Those were high-volume, low-mix plants. Real plants today are commonly reported in the 55 to 75% band. To be fair, that 55-75% band comes from OEE vendors' own customer data rather than an independent audit, so treat it as directional only. Worth knowing too: SEMI E79, the standard that actually defines how OEE is computed for semiconductor equipment, sets no target at all. It tells you how to measure. It never told you what good looks like. What I keep coming back to is that the target is not the problem. The level is. A Fraunhofer paper on moving from OEE to Overall Fab Effectiveness puts it plainly - no machine is isolated in a factory. Tool-level OEE does not add up to fab output. Raise it on a tool that was never the constraint and you have not bought throughput. You have bought WIP, and WIP is cycle time in disguise. The dial goes up. The fab does not. Has anyone actually retired an OEE target and put a flow metric on the screen instead? I would like to know what you replaced it with - and whether management let you keep it there past the first bad month.

Why does a fab running its tools harder than ever keep missing its cycle-time commitments? Because past a certain point, utilisation and speed stop being the same goal and become opposites. Plot cycle time against utilisation and you do not get a line. You get a curve that bends upward and then goes nearly vertical. Below the knee, pushing utilisation up costs almost nothing. Above it, one more point buys you days of cycle time. The mechanism is queueing. A tool busy 95% of the time has almost no slack to absorb variability - a hot lot, a chamber down, a recipe change - so work piles up in front of it. In a fab, that queue is product sitting still with weeks of value already sunk into it. The number I would put on a dashboard instead is x-factor: actual cycle time divided by raw process time. One documented line ran 35.5 days of cycle time against 8.6 days of processing - an x-factor of 4.11, so roughly three quarters of that lot's life was spent waiting. To be fair, the exact position of the knee is not universal. It moves with variability, tool count, product mix and how well a fab absorbs downtime. The curve shape is reliable. The 85% is a landmark, not a setpoint. What I keep coming back to is that this is a management problem before a technical one. The curve is well understood. An idle tool just looks like waste in a review, and cycle time creeping up does not show up until the quarter is over. Has anyone actually got a fab to run a bottleneck tool at deliberately lower utilisation to protect cycle time - and what convinced the people who own the capital?