Every process on your line runs on numbers somebody once wrote down: response lags from the vendor spec, thermal constants measured during install, drift behavior remembered from the last excursion. Some of those numbers are wrong. Somewhere in your organization, an engineer already suspects which ones, and cannot prove it.
This series is about materials enablement, the application of AI to the journey from "works once" to "works every time." Part 1 argued that the characterization queue sets the speed limit of a development program until material state becomes a live, continuous signal. This part is about the pillar that signal feeds first: understanding. Most teams do not actually understand how their process behaves. They know how it is supposed to behave, which is different, and the difference costs months.
The cost is silent, which is what makes it expensive. Experiments get designed against the assumed dynamics, so when the assumptions are off, the experiments answer the wrong question. Nothing fails loudly. The program simply converges slower than it should, and nobody can say why.
Today's Ceiling: Dynamics Taken on Faith
Start with the numbers themselves. At one lab we work with, a critical control loop turned out to respond more than fifty percent slower than the value every recipe had been designed against. The consequence was an overdriven process that had spent years oscillating around its setpoints instead of settling onto them. A senior engineer suspected it for the better part of a year. Suspicion was as far as anyone could get, because checking would have meant a dedicated experimental campaign that no development schedule could absorb.
What understanding does exist rarely lives anywhere durable. It accumulates in the heads of senior engineers, run by run, over years, and it walks out the door with them. Every departure is a small library fire.
The record that could rebuild that understanding technically exists. Tool logs, in-situ sensors, metrology, the MES: every stream is captured somewhere. But each one is analyzed alone, and the relationships that explain process behavior run across them, invisible to any single-stream view. The archives themselves sit in formats only a software team can open, and the software team has a backlog. So the people with the questions cannot reach the data, and the people who can reach the data do not know the questions.
That leaves the designed experiment as the one sanctioned path to causality: rigorous, respected, and priced in wafers. A proper DOE isolates one factor at a time and bills weeks of tool time for the answer. The price does more than slow answers down; it rations the questions.
The Solution: Recovering True Dynamics from Runs You Already Have
Atomscale's models recover how a process actually behaves from the runs a team has already completed. Response lags, time constants, drift modes: extracted from historical data, with no new experiments on the calendar. That recovery depends on keeping the record whole. Atomscale carries the full signal end to end at native resolution, so nothing dead-ends in an intermediate format and no compression step averages away the fine structure that dynamics live in. Cross-data-stream pattern detection does the same for relationships, surfacing correlations across tool logs, sensors, and metrology that no univariate analysis can see.
Just as important is where the capability sits. Atomscale puts these models in the hands of the material scientists themselves, so a question that once required a software project, or a wafer budget, becomes a query. And the live estimate of material state from Part 1 feeds the same models, giving them far more to explain than raw tool signals alone.
The Unlock: A Process You Can Interrogate
The process becomes a model you can question. A hypothesis that once justified a DOE, or died for lack of one, gets tested in days against runs already paid for. That is how our customer’s year-old suspicion about their control loop was settled: from the archive, in days, without a single new wafer. The lag was real, the recipes were rebuilt around the measured value, and the oscillation stopped.
Understanding also starts to compound. Knowledge captured in a model survives reorganizations and retirements; the library stops burning. For a leadership team this is the deeper return: process understanding turns into an asset that appreciates with every run instead of evaporating with attrition.
The next possibility is transferability. Dynamics learned on one tool can seed the model for the next tool, the next recipe, the next site, so understanding stops restarting from zero at every transfer. Programs begin to inherit from each other, and each one starts its learning curve partway up.