AI readiness starts with reliable product data – Unite.AI

Manufacturers are investing heavily in artificial intelligence, digital thread initiatives, automation and business modernization to improve productivity and decision making. Much of the conversation focuses on AI models, infrastructure and integration. But many organizations overlook a critical prerequisite for these efforts: trust in the underlying product data and business rules that guide operational decisions.

The challenge is not simply connecting systems, but ensuring that the product definitions, configuration logic, and business rules that flow between them remain accurate. AI readiness starts with trust in your company’s product data. Digital transformation isn’t just about connecting systems; it’s about preserving the meaning and accuracy of the information that moves between them.

As companies modernize enterprise systems and connect product lifecycle management (PLM), enterprise resource planning (ERP), price quote (CPQ) configuration, and service platforms, inconsistencies in configuration logic can easily compromise the accuracy of downstream processes and the effectiveness of AI-based recommendations. Without reliable configuration logic, AI accelerates errors instead of improving decisions.

Because the product configuration is the hidden basis

Today’s manufacturers increasingly rely on an interconnected ecosystem spanning PLM, ERP, CPQ, manufacturing and services. Product configuration serves as the connective tissue that translates engineering intent into production, sales, pricing and service requirements.

Each system has a different vision of the product: PLM needs the technical and design information, manufacturing needs to know what can be built, CPQ needs sales and market rules. Configuration is what connects these perspectives. When the underlying logic changes or becomes inconsistent, the digital thread breaks regardless of the level of systems integration.

Legacy rules introduce invisible risk

Product configuration models often represent decades of accumulated knowledge, layered over time: regulatory requirements, manufacturing constraints, market-specific exceptions, and pricing logic. The people who originally built these models have often left the company, leaving organizations with rules that no one fully understands anymore.

Enterprise modernization projects, such as SAP S/4HANA migrations, typically emphasize applications, infrastructure, and custom code, treating configuration logic as secondary. The result is an overlooked risk: Systems can successfully migrate while configuration behavior changes in subtle ways that are difficult to detect through traditional testing.

S/4HANA migrations illustrate the problem well, because a new configuration engine can interpret long-standing rules differently despite identical syntax. Differences in how defaults are applied, in the order in which constraints are evaluated, and in how conflicts between rules are resolved can change the combinations a model accepts, without a single line of the rules themselves being rewritten.

This is not simply confusing; bad configuration logic becomes a business problem. There are two failure modes and both are expensive:

• One setup allows a company to sell something it can’t actually produce, resulting in rework, missed commitments, and damaged customer relationships.
• One setup mistakenly prevents a company from selling something it could produce, resulting in lost revenue and potentially losing competitive advantage.

The first failure mode eventually announces itself at the factory. The second is silent; nothing in the order log records a sale that the configurator never allowed.

Verification is becoming a strategic capability

Traditional migration validation relies heavily on manual testing and spot checks, which cannot realistically evaluate the huge number of possible product combinations. Configuration verification shifts the focus from whether the data was successfully transferred to whether the business intent remains intact.

I’ve seen production teams whose entire job is to confirm that a migrated model still produces the same valid configurations and still rejects the same invalid ones, simply because they have no other way of knowing. It’s detailed, expensive, and time-consuming work, and even then it’s just sampling the problem.

It is worth clarifying the scope involved. A model with 30 variables and five choices for each allows for about 10²¹ combinations, far more than the estimated number of grains of sand on the earth, and real industrial models are considerably larger. No amount of people clicking on a user interface can cover that space; arithmetic doesn’t allow it.

This is why formal methods matter. Instead of sampling combinations, a configuration model can be compiled into a canonical logical form: a compact mathematical representation of every valid combination allowed by its rules. Two models compiled in this way can be directly compared. Either they describe exactly the same set of valid products, or the comparison returns right where they diverge, with concrete examples of combinations that one accepts and the other rejects. The same representation turns runtime behavior into a search rather than a lookup, which is what allows a configurator to show only valid options and never lead a user into a dead end. Verification and correctness at execution turn out to be the same capability addressed from two directions.

Organizations increasingly need this type of formal discussion before placing AI or automation at the top of their product rules. The goal is not simply to reduce migration risk, but to preserve business continuity between engineering, manufacturing, sales and support, and gain the ability to test, debug and verify configuration models before release rather than after.

AI sits on top of a deterministic engine, not in its place

None of this requires AI to replace the configuration engine. The most enduring model is the opposite: AI sits between the user and a rigorous configuration engine, providing a more natural guided sales or recommendation experience while the underlying rules remain deterministic. The language model interprets what the customer asks for; the engine decides what is actually buildable. This division of labor keeps the part of the process that must be demonstrably correct out of the hands of a system that is, by definition, probabilistic.

Trustworthy data is what makes AI programs successful

AI can only generate recommendations as reliably as the product knowledge it receives. Unverified configuration data causes AI to propagate enterprise-scale errors, undermining sales guidelines, manufacturing decisions, and customer engagements.

Manufacturers should consider data verification as a prerequisite for implementing AI, just as software testing has become a prerequisite for application development. As digital transformation continues, competitive advantage will increasingly come not from implementing AI first, but from implementing AI on a foundation of trusted product intelligence.