When Skyler and I started Reaxiomatic in 2023 in San Diego, we framed the problem as a machine learning problem. A precision manufacturer has historical yield records. Those records encode relationships between parameter inputs and process outputs. We wanted to extract those relationships and use them to guide future parameter selection.
This framing was approximately right but usefully incomplete. The machine learning component turned out to be the smaller part of the engineering work. The larger part was the data infrastructure question that we did not fully understand until we were six months in and talking to the third shop that showed us their actual data.
What We Thought Would Be Hard (and Mostly Was Not)
The Bayesian optimization literature is mature. Gaussian processes for surrogate modeling, upper confidence bound and expected improvement as acquisition functions, the basic loop of fit-propose-query-update: this is all well-developed. The algorithmic foundation took us a few months to implement and test on synthetic benchmarks.
We spent time on the choice of kernel for the Gaussian process regression. The standard radial basis function kernel makes assumptions about the smoothness of the underlying function that may not hold in a real machining process, where the response surface can have sharp transitions around tool engagement or chip formation conditions. We ended up using a product kernel with a noise term, which gave us better calibration on the validation data we eventually had access to, but the difference was less dramatic than we expected.
The active learning loop itself, where each query is selected to maximize information gain about the unknown optimum, is computationally cheap compared to what we had anticipated. For the parameter spaces typical in precision CNC, six to eight inputs with continuous and discrete dimensions, the acquisition function optimization runs in a few seconds on commodity hardware. This was not a bottleneck.
What We Did Not Expect to Be Hard (and Was)
The real difficulty was the data structure problem. Shops record parameter information in many ways: CNC programs in ISO G-code with parameters buried in the code or in setup sheets, CMM measurement files in various metrology software formats, hand-written traveler documents, MES exports that capture some but not all of the relevant setup conditions.
Before any of that data is useful to an optimization algorithm, it needs to be in a common structure: a table where each row represents a specific setup, and the columns represent the controlled parameters that describe that setup, plus the measured outcomes that describe what happened. Creating that table from actual shop data is not a software problem. It is a data modeling problem. Which parameters are truly independent variables? Which are outputs? Which are confounds that were not recorded but should have been?
The first time we sat down with a shop's data, we found that their yield measurements were recorded per-part, their parameter settings were recorded per-setup, and those two records did not share a consistent key. To link them, we had to infer which parts came from which setup based on timestamps and part numbering conventions that varied by operator. This took a week. It was not algorithmic work. It was detective work.
The Confound Problem
A confound is a variable that changes along with the variables you are studying, affecting the outcome, but that you did not record. In precision machining, the most common confounds are material lot variation, tool wear accumulated since the last tool change, and fixturing variability across operators.
If you fit a Gaussian process to data where cutting speed and material lot are both varying between observations, the model will attribute the combined effect to whichever variable it can see. The model's recommendations will be unreliable in any setup where cutting speed changes but material lot does not, or vice versa. The model is not wrong: it learned what the data told it. The data was incomplete.
Handling confounds requires either recording them as covariates in the data structure, running designed experiments that hold them constant, or using models that are explicit about their uncertainty when operating outside the training distribution. We spent considerable time on the third approach, because shops often cannot tell you their material lot numbers or their accumulated tool cycles at the time of each setup. The records simply do not exist.
Our current approach flags parameter recommendations with confidence bounds that explicitly expand when the input configuration is far from any recorded observation. This is not a solution to the confound problem. It is an honest representation of what the model does not know, which at least prevents engineers from treating an uncertain recommendation with unwarranted confidence.
What Changed Our Thinking About the Product
About a year in, we stopped thinking about the product as a recommendation engine and started thinking about it as a data structure enforcer. The value of using Reaxiomatic is not primarily the quality of the Bayesian recommendations, although those matter. The more durable value is that using the system requires shops to record their setup data in a consistent structure.
Shops that have been using the product for several months have a structured historical record that their pre-Reaxiomatic spreadsheets did not give them. That record is valuable for the optimization loop, but it is also valuable for troubleshooting, for training new process engineers, for customer audits, and for any future analysis they want to run on their own process. The recommendation algorithm is the motivating reason to build the record. The record has independent, compounding value.
This sounds obvious in retrospect. It was not obvious to us at the start, because we framed the problem from the algorithm side rather than from the data lifecycle side. Most engineers in our position would have made the same choice: the algorithm is interesting, the data plumbing is not. What two years of building taught us is that the data plumbing is where users spend most of their time, and it is where the most defensible product investment lives.
What We Would Do Differently
We would have spent the first four months talking to shops about their data recording practices rather than building the algorithm. We built an impressive Bayesian optimization engine and then spent four months reworking our ingestion layer because the data formats we encountered were nothing like our synthetic test cases.
We would also have been more aggressive about defining what the minimum useful data structure is. We tried to be flexible, accepting data in many formats and doing translation on ingestion. The flexibility is useful for onboarding, but it created ambiguity about what records shops actually need to maintain to get value from the system. Defining a clear minimum structure upfront, and building tooling to help shops get to that structure, would have accelerated the path to useful recommendations.
None of this is a complaint about the problem. The data structure problem is genuinely hard and genuinely important, and solving it is the part of the work that turned out to have the most leverage. We are glad we built the algorithm first, because we needed to understand what data structure the algorithm needed before we could design the ingestion layer around it. The sequencing was not ideal, but the learning was real.
Two years into this, the part of the system we are most confident in is the data model. The algorithms will keep improving. The fundamental insight that precision shop yield data contains recoverable information about the parameter space, and that a structured search can extract it faster than trial-and-error, holds up. What it required to hold up was a lot of careful work on the stuff that does not show up in the demo.