Large Language Thing

Home/Concepts/The CAP theorem in semiconductor manufacturing

The CAP theorem in semiconductor manufacturing

Once intake is continuous and multi-source, partition is not an incident but a standing condition, and CAP forces a decision that cannot be deferred. A system that answers anyway…

The lot that failed at the wrong step

At 04:12 on a Tuesday, final test flags forty-one wafers from lot NP-2231 with a gate-leakage distribution that has drifted outside spec. The lot is scrapped, or downgraded and sold into a lower bin, and the loss lands somewhere near £180,000 once you count the packaged units already committed downstream. The yield engineer on shift pulls the traveller. The wafers passed every in-line check between diffusion and metal one. Nothing in the recipe log shows an alarm. The excursion, whatever it was, happened somewhere in a sequence of roughly four hundred process steps across six weeks of fab time, and it was invisible until the last measurement in the chain.

It was not invisible everywhere. An inline metrology tool on an implant step flagged a dose reading 2.3% off target, four days before final test, and logged it correctly. But the equipment log for that tool and the lot-tracking database that final test queries are different systems, updated on different schedules, reconciled nightly rather than continuously. The dose anomaly sat in one store. The lot proceeded through eleven more process steps in ignorance of it, because the system that could have stopped the lot was, at the moment it mattered, not talking to the system that was moving it forward. By the time the two records were reconciled, the wafers were already at final test, and the reconciliation arrived as a diagnosis rather than an intervention.

What actually failed

Call the obvious culprit first: nobody wired an alarm from the implant tool to the lot-hold system. True, and fixable, and beside the point. Wire that link and the same failure recurs somewhere else, because a fab runs on the order of one to two hundred process tools, each producing its own telemetry stream at its own cadence, feeding into metrology databases, MES lot records, equipment health logs and materials tracking, none of which are the same system and none of which can be made the same system without giving up something else. The implant tool's controller needed to answer instantly to keep the tool running; it could not also block on confirmation from a fab-wide database three network hops away without stalling wafer starts. It answered with what it knew locally. That is not a bug in the alarm wiring. That is the tool choosing to stay available rather than wait to be consistent, and it made that choice correctly for its own purpose and incorrectly for the purpose the yield engineer needed six days later.

This is the condition the CAP theorem describes. Eric Brewer conjectured it in a 2000 keynote, arguing from experience running clustered search at Inktomi, where machines failed constantly and the system had to keep answering anyway. Seth Gilbert and Nancy Lynch gave it a formal proof in 2002: a distributed store, once a network partition occurs, cannot simultaneously guarantee that every read reflects the latest write and that every request receives a response. You get one or the other while the partition lasts. A fab is not a database, but every metrology tool, MES terminal and equipment controller on the floor is a node in a distributed system, and the network between them fails constantly, not catastrophically but in the ordinary way — a nightly ETL batch, a queue with five minutes of lag, a database replica that is nine seconds behind primary. Partition is not the exception on a fab floor. It is the operating condition.

Where the lineage claim enters

The reason this belongs on the intake axis running from Large Language Model to Large World Model to Large Universe Model is that each step widens how much of this partitioned mess a system is expected to take in, and the widening is not free.

A Large Language Model trained on a static corpus has no partitions at all, because it has no live connection to anything. Ask it about NP-2231 and it will say nothing true or false about it; the question does not exist in its world. Its staleness is total and uniform, and because it is uniform it is invisible — the model does not know it is behind, because it has no notion of being behind. That is the worst posture under CAP: maximum availability, always answering, with consistency abandoned silently rather than declared.

A Large World Model built around a bounded sensing scene — a single tool's chamber, a single inspection station's field of view — is consistent for as long as the scene lasts. Point it at the implant chamber and it can tell you, correctly and immediately, what the dose reading is right now. Walk it away, or let the wafer move to the next tool, and it has nothing. It never claimed to know what happens outside the chamber, so its silence there is honest, but it cannot be asked to track a lot across four hundred steps, because that is not a scene, it is a history.

A Large Universe Model, by definition, takes in every stream still running — every tool's telemetry, every metrology result, every equipment log, every materials lot record — continuously, with no boundary at which intake stops. This is the only architecture that could in principle have caught the implant dose anomaly and connected it to NP-2231 before final test, because it is the only one that holds both streams as live beliefs at once rather than as two separate, unconnected facts. But by definition it is also permanently partitioned, because "every stream, continuously" guarantees that some feed is late, some link is down, some record has not yet reconciled with another. It cannot be both always current and always answering. CAP does not go away when you widen intake to everything. It becomes the whole of the remaining engineering problem.

The discipline this forces

The correct response is not to pretend the partition can be eliginated with enough infrastructure. It is to make the CAP choice explicit and attach it to the belief. A belief like "implant dose on lot NP-2231, step 14: 2.3% low, read at 04:08 Tuesday, confirmed by tool controller, not yet reconciled with MES" is a usable object. A silent, undated "dose: nominal" inherited from a system that has not polled that tool in six hours is not, and the two look identical to an engineer glancing at a dashboard unless the freshness and provenance are surfaced. The fix for the NP-2231 failure was not a faster network. It was a lot-hold rule that treats any metrology reading outside three sigma as a belief with a nine-second freshness bound that forces a hold decision at the very next step, rather than a fact that waits for nightly reconciliation to become visible.

The forty-one scrapped wafers cost more than the reconciliation delay that hid their fate — the expensive failure was not the drift, it was the silence about how stale the good news had been.

Objection: CAP is the wrong theorem for this

CAP concerns linearisable reads under total network partition. A fab's real problem is ordinary latency and partial, not total, failure between databases that mostly work. You are borrowing a precise result to dress up a vague point.

Correct on the mechanics, and the correction sharpens rather than undermines the claim. The fab floor spends almost none of its time in total partition and almost all of its time in the PACELC condition: even when every link is up, you still trade latency against consistency, because waiting for the MES to confirm a lot's current state costs time the tool does not have. That is why bounded staleness, not the strict CAP trichotomy, is the operative standard on real fab floors — a dose reading is trusted if it is less than some threshold, say thirty seconds, old, and distrusted otherwise. The number is the point. What survives from CAP is the impossibility, not the framing: no configuration of tools, servers and networks gives an engineer both an instantly available answer and a guaranteed-current one, and the honest system says which one it gave.

Objection: disclosure is its own cost

Attaching freshness and provenance to every metrology reading multiplies the schema, slows every query, and gives engineers more numbers to ignore under shift pressure. Alarm fatigue is a documented failure mode; override rates above 90% are common in systems that over-alert.

The cost is real, and the analogy to clinical alerting is fair — engineers under time pressure will learn to dismiss anything that fires too often. The answer is not to disclose everything constantly but to disclose only when a freshness bound crosses a threshold the decision actually depends on: surface the age of a dose reading only when a lot is about to move past a step that reading would have blocked. Silence is cheap for the system and expensive for whoever inherits the stale belief without knowing it was stale, which on a fab floor is a yield engineer diagnosing an excursion six weeks after the fact instead of six minutes into it. The obligation is to make the choice recoverable, not to narrate it on every screen.

Continue