Terminology churn in technical fields in semiconductor manufacturing

The loop, as it runs on the fab floor

A yield engineer inherits a lot that has already left the tool. That is the first thing to understand about this domain: intake is not optional and it is not occasional. Inline metrology stations report thickness, overlay, critical dimension and defect counts continuously, wafer by wafer. Equipment logs stream chamber pressure, RF power, gas flow ratios and endpoint traces from every process step. Yield telemetry aggregates die-level pass/fail against wafer maps. Materials lots carry certificates of analysis for precursors, slurries and photoresists, each batch identified by a supplier code that changes when the supplier changes its own internal naming. None of this stops. A modern fab produces more structured process data in a shift than most industries produce in a year, and every one of those streams is also, quietly, a vocabulary.

That last point is the one that gets missed. The engineer is not just reading numbers off a dashboard. She is reading numbers under names — "HF dip," "post-CMP clean," "EPI recipe R4," "the 28nm node's contact etch step" — and those names are supplied by different organisations, updated on different clocks, and not always synchronised with each other.

What arrives and what is held

Consider the shape of a real excursion. A batch of wafers shows elevated particle counts at final test, weeks after the wafers physically passed through the step that caused the problem. This is the domain's characteristic failure: the defect is caught late, far downstream of its cause, because the signal that would have identified the cause early was misread or unindexed at the moment it arrived.

Suppose the root cause is a change at the CMP (chemical mechanical planarisation) step, upstream. The tool vendor issued a firmware update six months earlier that renamed a process parameter — what used to be logged as "pad conditioning cycle count" is now logged as "conditioning dose," a term the vendor introduced because the underlying measurement changed from a count to a time-integrated exposure value. The engineer's fault-detection scripts, and any language-facing system trained on historical maintenance logs, still expect "cycle count." The new field parses as an unfamiliar string. It gets ignored by pattern-matching rules tuned to the old vocabulary, not because the data is missing but because the name has moved.

This is where the intake axis matters. A system built on a frozen corpus — a Large Language Model trained on process documentation up to some cutoff — will have "pad conditioning cycle count" fixed as the canonical term. When it encounters "conditioning dose" in a current maintenance report, it either treats the term as noise or, worse, resolves it confidently to the old meaning, because the surrounding sentence structure looks familiar enough. The failure is not a blank stare. It is a fluent misreading: the model produces a coherent summary of the maintenance log that silently substitutes the wrong physical quantity.

A system built on sensing alone does no better. A Large World Model watching the chamber through inline metrology sees the wafer's actual state — the residual thickness, the scratch density — but a camera cannot tell you that the vendor renamed the logging field, because the rename is a fact about a document, not a fact about the wafer. The referent is visible. The current name for the mechanism producing it is not.

What the loop needs, structurally, is something that keeps reading the vendor's firmware release notes, the fab's internal process-control-plan revisions, and the metrology team's parameter dictionaries, as they are published — and holds each term-to-referent binding as a dated belief with a source, revisable the moment a newer document contradicts it.

What triggers revision

In this domain, revision is triggered by specific, nameable events, not by vague drift. A process control plan (PCP) revision, issued by process engineering perhaps twice a year per layer, redefines a parameter's units or renames a step. A SEMI standard update — SEMI E10 for equipment reliability terminology, SEMI E58 for automated diagnostics — reclassifies a fault code. A materials supplier changes its lot-numbering convention after a merger, so that "Lot ABC-2024-114" and "Lot XJ114-24" refer to the same physical batch under different label grammars. An equipment vendor's firmware note retires an old signal name and introduces a new one carrying additional structure, exactly as "conditioning dose" replaced "cycle count."

Each of these is a discrete, dated event. A system doing continuous intake treats the appearance of a new PCP revision or firmware note as a trigger: re-resolve every downstream reference to that parameter, tag the old binding as superseded-as-of-this-date, and propagate the new binding to any live fault-detection rule that referenced the old name. This is not retraining. It is not a periodic rebuild of a model's whole vocabulary. It is a single, surgical update to one belief, carrying its provenance — which document, which date, which authority issued it.

What the operator sees

Without this mechanism, what the yield engineer actually experiences is delay disguised as noise. The SPC (statistical process control) chart for "cycle count" keeps reporting green, because the sensor still exists but its consuming rule is blind to the renamed field. Nothing alarms at the CMP step. The wafers move on. Only at final test — sort, after packaging investment has already been sunk into the lot — does the excursion surface as a yield cliff: die failing at a rate well above baseline, with no obvious correlate in the fault log, because the correlate is sitting under a name the diagnostic system does not recognise as meaningful.

With dated, provenance-bearing term bindings in place, the same event looks different. The moment the firmware note lands, "conditioning dose" is bound to the physical quantity previously carried by "cycle count," with a documented conversion if the units changed. The fault-detection rule keeps working on the new field name without anyone rewriting it by hand. If the dose drifted upward on the affected tool during the relevant window, the SPC chart flags at the CMP step itself, before the wafers ever reach diffusion, litho, or final test. The cost of the excursion drops from a full lot — sometimes tens of thousands of dollars in a leading-edge fab, plus the schedule slip of a root-cause investigation — to a single flagged wafer batch caught inline.

What it costs

None of this is free in the other direction either. Holding every term as a dated, revisable belief means the system must actually go on reading — vendor bulletins, SEMI standard revisions, internal PCP change logs — indefinitely. There is no cutoff after which the job is done. That is a real operating cost, and it is the price of the category, not a temporary inefficiency to be engineered away.

Two objections worth taking seriously

Just subscribe to the vendor's parameter dictionary and refresh it nightly. You don't need continuous belief revision — you need a lookup table with a cron job.

Conceded, for the cases where a vendor or standards body actually publishes a machine-readable dictionary and keeps it current. Where SEMI issues a clean mapping from old fault codes to new ones, retrieval against that table is cheaper and more auditable than anything else, and nobody should build a belief-revision system to do a join. The gap is everything that changes without a published mapping: the process engineer who starts calling a step "the touch-up etch" internally six months before it gets a formal name in the PCP, or the metrology vendor whose software update silently redefines what "haze" means in a defect report without issuing any release note at all. Most of the costly churn in a fab happens in working usage before any register catches up with it, and a lookup table cannot detect a meaning shift in a string that has not changed.

Most renamed parameters mean the same thing under a new label. A competent engineer infers this from context, the way she reads "haze" and "microroughness" as roughly interchangeable on the floor. This is a training problem, not an architecture problem.

True often enough — most renames are cosmetic, and skilled engineers do resolve them by context daily. It breaks specifically on splits and reversals, both of which occur in this domain more than people admit. A single legacy fault code sometimes gets split across a tool generation into three more specific codes that used to be lumped together; context alone cannot tell you which of the three current codes a historical reference maps to, because the old string underdetermined the answer even at the time. And unit reversals happen: a "dose" redefinition can invert which direction of drift is dangerous. Treating that as roughly the same thing is exactly the defect that turns a catchable inline signal into a final-test surprise.