C-Infinity: AI Is Accelerating Design Faster Than We Can Validate It
Startup Stories | Sai Netaluri
🏭 Breaking the Bottleneck is a weekly newsletter and interview series covering manufacturing technology and physical AI. Want to chat? Reach out at aditya@machinafactory.org or connect with me on LinkedIn.
This newsletter is brought to you with support from our featured partners: AMT, IMTS, Jiga, Upkeep, and Industry 4.0 Club.
AI Is Accelerating Design Faster Than We Can Validate It
"The deeper bottleneck is no longer generating candidate designs. It is verifying which designs can actually be built, assembled, changed, and scaled in the real world."
You spent years at PARC and Carbon doing deep research on accessibility constraints for multi-axis machining and lattice design before founding C-Infinity. What was the specific moment or failure mode you kept seeing in the field that convinced you the problem had to be solved from scratch, rather than fixed inside an existing platform?
For fifteen years, I watched the same failure mode repeat from the outside. At PARC and Carbon, I was often sitting at the boundary between advanced process capability and the engineering organizations trying to use it. I watched Fortune 500 manufacturers, aerospace primes, medical device companies, and consumer hardware teams hit the same wall: a design could be complete in CAD and still be nowhere close to production-ready.
The specific domains changed from multi-axis machining, lattice design, metal additive manufacturing, and assembly, but the underlying bottleneck was the same. Function-oriented product data had to be transformed into manufacturing-ready process intelligence, and that transformation was still done almost entirely by expert humans. CAD models are authored by design engineers with the implicit assumption that the next consumer is another human: a manufacturing engineer, process planner, quality engineer, or supplier. That works when timelines are forgiving. It does not scale when companies are under pressure to accelerate time to market and respond quickly to change.
That is the missing computing layer we started C-Infinity to build. Existing platforms were not designed for it. CAD defines the product, PLM manages the product record, MES executes the production workflow, but the reasoning layer that turns product definition into a feasible manufacturing plan has largely been missing. If AI is going to meaningfully accelerate time to market, it cannot assume engineering data was created for automation. It has to work with human-oriented engineering data while reasoning over geometry, physics, motion, constraints, and manufacturing process logic.
We started with assembly because nearly every advanced product is assembled, and assembly planning exposes the core challenge clearly: translating product structure into process structure. It is a combinatorial, geometry-rich, physics-constrained problem embedded in a complex enterprise workflow. Solving it requires a purpose-built foundation.
AutoAssembler treats the EBOM and MBOM as dual representations of the same configuration space rather than two separate handoffs. In practice, where does that model break down first is it change management across variants, geometry validation, or organizational resistance to collapsing two workflows into one?
The honest answer is variants under continuous change, but it is worth being precise about what “dual representation” actually covers.
The EBOM and MBOM share a part structure, and at that layer they can be treated as projections of a common configuration space. AutoAssembler uses that fact to reason from the EBOM to the assembly sequence. But a full MBOM is more than its part structure. It also carries process content: tools, fixtures, consumables, work centers, sequence, and process logic that have no direct analog in the EBOM.
So the projection holds for parts. It does not hold for the MBOM as a whole.
The model starts to strain first under variant proliferation. A single product family can generate thousands of MBOM permutations driven by configurability (regions, customer options, supplier substitutions, etc). Each variant inherits much of the assembly logic of its siblings but diverges in specific places. The hard part is tracking which planning decisions are shared across the family and which are variant-specific.
The second pressure is continuous change. Every ECO forces a recomputation: what changed in the EBOM, which parts of the existing MBOM and assembly plan remain valid, what has to be re-planned, and what can be reused. When a change touches a part that participates in multiple variants, the two pressures compound. You are re-validating the projection across a family, not a single product.
Geometry validation is a real failure mode, but it is usually more well-defined, e.g. this fastener cannot be reached, this sub-assembly cannot be sequenced as drawn. Those problems become much harder when variants and ECOs are also in motion, because the system has to know which configuration and which version of the plan it is validating.
Organizational resistance is real, but in our experience it tends to recede when the model holds up under variants and change. When it does not, no amount of organizational alignment fixes the underlying problem.
So the model breaks down first where the projection is most stressed: high-mix products under continuous engineering change. That is why EBOM-to-MBOM translation stops being a data-management problem and becomes a manufacturing-reasoning problem.
When you’re selling into an OEM with an entrenched PLM stack, who do you actually close first: the manufacturing engineer, the manager, or the VP of Engineering running the program? What is the initial product wedge?
The wedge is the ECO (Engineering Change Order) process.
That is where the pain is immediate, measurable, and already tied to the customer’s existing PLM workflow. OEMs process thousands of engineering changes, and every change creates downstream manufacturing questions: what changed, which process steps are still valid, what has to be re-planned, what work instructions need to be updated, and what risks have been introduced?
The manufacturing engineer is usually the primary user because they feel that pain directly. They are the ones working through the backlog: interpreting design changes, assessing assembly impact, reusing what they can from the existing plan, and manually updating instructions.
AutoAssembler helps them do that work faster and more systematically. We identify what changed, determine which planning logic can be reused, generate the missing portions of the assembly plan, and produce updated work instructions.
That makes ECO a strong initial wedge because it is not an abstract AI use case. It is a concrete operational bottleneck with direct impact on manufacturing readiness, engineering throughput, and program execution.
Over time, the goal is to shift this intelligence left. The same manufacturing reasoning that helps process planners evaluate ECOs should also become available to design engineers before changes are pushed downstream. That allows them to measure the manufacturing impact of engineering changes earlier, when the cost of iteration is lower, and the design is still flexible.
The economic buyer is usually higher up: a VP of Engineering, VP of Manufacturing, or digital transformation leader. They care about throughput, change velocity, program delays, and the cost of engineering rework.
How much of AutoAssembler’s architecture today is model-based versus statistical, and where do you expect that balance to shift as the product matures? To ensure seamless adoption, what’s your philosophy on integration depth versus breadth, and which platform are you targeting next?
AutoAssembler uses a neuro-symbolic architecture: model-based and deterministic at the core, with machine learning applied where it creates leverage.
Manufacturing planning is not a pure prediction problem. A system cannot simply infer a process plan statistically and treat it as correct. It has to reason explicitly over geometry, motion, contacts, constraints, accessibility, sequencing, and feasibility. That requires a deterministic planning foundation.
Machine learning becomes powerful around that foundation. It can learn customer-specific preferences, recurring planning patterns, reuse decisions, and organization-specific process logic. Over time, the system becomes more informed by each customer’s environment while preserving deterministic reasoning where correctness matters.
That architecture also shapes our deployment model. We deploy inside the customer’s VPC and do not cross-train across customers. Each customer’s system is tuned to its own products, processes, and know-how — and as the system learns over time, that institutional knowledge compounds inside their environment rather than leaking into a shared model. The customer’s manufacturing know-how stays with them, and the system gets more valuable to them with every deployment, ECO, and planning decision.
On integrations, we are API-first. We support all major CAD platforms today, and we design our endpoints to connect with critical workflow triggers: ECOs, design releases, variant updates, and manufacturing-readiness checks.
That focuses our integration strategy. We prioritize workflow depth over connector count. We integrate where decisions happen and where automation can remove friction from the workflow. The goal is for AutoAssembler to operate as an event-driven manufacturing reasoning layer across the customer’s enterprise stack.
In practice, many customers operate mixed CAD and PLM environments, which makes interoperability essential. Our tightest integrations today are within the PTC ecosystem. We’re deliberate about not pre-announcing the next platform; we let customers pull, and commitments drive that sequencing rather than picking targets in advance. The goal is to meet customers where they already work while giving them a reasoning layer that connects product definition, manufacturing planning, and production readiness.
Most people in the CAD/PLM world frame the opportunity as “AI will accelerate design.” Your thesis seems to be the opposite, AI is already accelerating design faster than humans can validate it, and the real bottleneck is now verification. Who in the industry do you think is most wrong about where the value actually gets created?
The design-acceleration thesis is not wrong. It is incomplete.
As design generation and physics simulation get cheaper, validation across the stack becomes the scarce resource. AI will help engineers generate more concepts, explore larger design spaces, and run simulations faster — that part is real. But the harder question is no longer whether AI can generate more candidate designs. It is which of those designs can actually be manufactured, assembled, changed, inspected, sourced, and scaled in the real world.
Manufacturing has always had this asymmetry: process capabilities often advance faster than our ability to design for them. The manufacturing stack can do more than the surrounding engineering and planning workflows can reliably support. AI-assisted design accelerates one side of that asymmetry without addressing the other.
So the larger opportunity is not pushing more designs downstream into manufacturing. It is pushing manufacturing intelligence upstream into design, so engineers can make targeted decisions that minimize feedback loops before production. The systems that create the most value will not simply generate more options. They will help engineers generate options that already understand manufacturing feasibility, assembly logic, change impact, and production readiness.
The next bottleneck is not imagining more designs. It is proving which ones can become real products.
To contact Sai, reach out to him on LinkedIn here. He’s always open to chatting and sharing valuable insights.
