You pull up a paper, find an ALD GPC value for Al₂O₃ at 200 °C, and type it into your notebook next to your own ellipsometry result. The two numbers sit in the same column, same unit — Å/cycle. A week later you open the file again. Which one came from your wafer?
How engineers actually look up ALD GPC
The routine is familiar. You need a reference GPC for a new precursor-temperature window, so you search. You open papers, skim their tables, grab the value closest to your conditions, and paste it into a spreadsheet alongside your own measurements. The spreadsheet does not ask where each number came from. It asks for a value and a unit.
Over time the file grows. Some rows hold ellipsometry readings taken on your tool last Tuesday. Others hold numbers you copied from a figure, tracing the axis by eye. A few might be back-of-envelope estimates you typed in during a meeting. Nothing in the formatting tells them apart. They are all just numbers in cells.
The label that is almost never there
When a GPC value appears in a table, it rarely carries a tag saying "measured on wafer" or "model output." The unit is the same either way. The decimal places look the same. If someone entered a physics-based prediction into the table months ago, the table will not remind you of that today.
This is not hypothetical. It is how numbers move in practice. A value that entered a document as a model output tends, after enough rounds of copying, to be read as a measurement. Not because anyone intended to mislead — because no one wrote down what it was.
Our own screen works the same way
We should be upfront about this. Semi Process Lab's /predict panel shows three results side by side — Expected thickness, GPC, and Uniformity. In one example those values read 26.9 nm, 0.90 Å/cycle, and 99.1%.
Every one of those numbers is a model output. There is no path for wafer measurement data to enter that panel. The prediction pipeline produces the thickness map, the GPC, and the uniformity figure — all of it. If you treat those values as measured, you are reading them wrong. Nothing on the screen will stop you.
When you upload your own measurement data, the system does learn from it — but what it learns is the residual: the gap between the physics-based prediction and your actual measurement. That residual bundles together model error, process conditions that were never logged, and measurement scatter, all in one number. The interface does not separate them for you.
Write the source, not just the number
The fix is not technical. It is a habit.
Every time you record a GPC value, write its source next to it. A few words are enough: "ellipsometry, tool B, Sept run" or "model output, 200 °C baseline." When you pull a value from any prediction tool — ours included — mark it as a model output. When you copy from a paper, note whether the original authors measured the value or computed it.
Comparing model values against other model values tells you whether a model is internally consistent. It does not tell you the model is correct. That distinction matters the moment you use a GPC to set a real process target.
A value with a stated source can be questioned, re-checked, and replaced. A value without one will eventually be trusted by default — not because it earned that trust, but because no one remembers to doubt it.
