The problem that became Reaxiomatic looked like a data management problem when I first ran into it. A process engineer at an aerospace sub-tier shop in Southern California was setting up a new titanium bracket for a defense program. The part had tolerances that the shop had successfully held before, on a different part number with similar geometry, using a similar material spec.
But the parameter records from that previous part were in a spreadsheet that belonged to the engineer who had set it up three years ago. That engineer had moved on. The spreadsheet was somewhere on a shared drive. Nobody could find it. The new engineer started fresh.
What I was watching was not a rare failure. It was routine. The same experiment, re-run, by different hands, because the record of the first experiment was not in a place where it could be used. The knowledge was created. It was not retrievable.
The Pattern Across Multiple Shops
After watching this repeat across multiple shops in the Southern California aerospace supply chain, Priya and I started asking the same questions at each one. How do you decide what parameters to run on a new part? How do you know if a similar part has been run before? When a configuration fails, how do you decide what to try next?
The answers were consistent in their structure, if not in their details. Process engineers rely on a combination of tooling vendor recommendations, personal experience, and informal institutional memory: knowing which colleagues ran which parts, which setups worked, which approaches to avoid. When those engineers leave, or when the volume of new part introductions outpaces what any individual can hold in their head, the institutional memory breaks.
The shops that had invested in more formal documentation often had parameter records in a quality management system, but the records were structured for compliance, not for search. They captured the approved final parameters after qualification was complete. They did not capture the failed configurations that preceded approval. The path from zero to approved was undocumented, even when the endpoint was recorded.
What the Data Actually Contains
Every failed parameter configuration in a qualifying run is a data point. It tells you something about the parameter space: these settings, with this material, on this machine, produced this outcome. When the next engineer tries to qualify a similar part, that prior failure is directly relevant. It tells them where not to go. More precisely, it tells a search algorithm where not to look, which is equivalent to telling it which direction has more uncertainty worth exploring.
Bayesian optimization is well-suited to this situation because it builds a model of the parameter space from whatever data it has, and uses that model to select the next trial from the regions with the highest expected improvement. Each data point, including failures, updates the model and sharpens the next recommendation. The more prior data available, the fewer trials needed to find a good configuration.
The precision machining parameter space is high-dimensional: spindle speed, feed rate, depth of cut, coolant flow and pressure, tool geometry selection, tool engagement strategy, fixture clamping sequence. Not all dimensions are equally important for all parts and materials, but the combinations that matter are not obvious from first principles, which is why experienced engineers spend years developing intuition about them. A search engine does not have intuition, but it can systematically explore a space that would take human trial-and-error many more iterations to cover.
Why We Built This Instead of Using Existing Tools
There are MES systems, QMS platforms, and SPC tools that touch adjacent problems. We looked at whether any of them could be configured to solve the parameter search problem directly.
The gap we found was structural. These systems are designed for process monitoring and compliance documentation. They record what happened in production, track conformance to specifications, and alert when measurements drift out of control. They are not designed for parameter exploration: for connecting a candidate parameter configuration to a prediction about what yield that configuration is likely to produce, given all prior observations.
That forward-looking prediction is the core capability that was missing. It requires a different data model than a quality record system: one that represents parameter configurations as inputs to be explored, not just as settings to be recorded, and one that accumulates evidence across all observations to improve its predictions over time. Building that model from scratch was the core of Priya's technical work in 2023 and 2024.
The Data Structure Problem We Did Not Expect
We expected the primary challenge to be algorithmic. It turned out to be structural. The data needed to feed a Bayesian search engine exists in most precision shops: CMM reports, setup sheets, SPC logs, traveler documents. What does not exist is a consistent record structure that connects parameter inputs to measured outcomes in a form that an optimization algorithm can ingest directly.
Building Reaxiomatic required designing that record structure and building the ingestion tooling to normalize data from the heterogeneous formats that shops actually use. This was a larger fraction of the total engineering work than we anticipated. It was also the work that turned out to have the most durable value: a shop that has been using Reaxiomatic for six months has a structured parameter history that is independently valuable for process documentation, training, and audit, beyond its value as input to the optimization loop.
What We Are Not
We are not a general-purpose manufacturing analytics platform. We are not a quality management system, and we are not trying to replace SPC or CMM workflows. We are a parameter search engine: a tool for finding better process settings faster, by building on the yield data that precision manufacturers already generate.
The people who get the most from Reaxiomatic are process engineers who are actively qualifying new parts or trying to improve Cpk on existing ones. They have parameter records that are incomplete or disconnected, and they are spending time on unstructured iteration that structured search could compress. That is the problem we exist to solve.
Two Years In
We started Reaxiomatic in San Diego in 2023 because we kept seeing the same problem in the Southern California aerospace supply chain: experienced process engineering knowledge getting lost between the engineer who created it and the next person who needed it. The mechanism of that loss was not human failure. It was a missing data structure that would have made the knowledge retrievable.
Building the search engine has taught us that the most valuable part of the product is not the search algorithm, although we work hard on it. It is the data discipline that using the system requires. When engineers record failed configurations as well as successful ones, when they link CMM records to setup parameters, when they track material lot as a covariate rather than as an afterthought, the accumulated record becomes a genuine asset. The search algorithm extracts value from that record. The record is what makes the extraction possible.
That is what we are building toward: a precision manufacturing operation where no parameter experiment is run twice by accident, because the record of the first one is structured, stored, and searchable.