Solving the Engineering Problem that Makes AI Actually Useful: Building the Axle
Precision-engineering for the four tolerance challenges of enterprise AI
This piece is a continuation of The Wheel and the Algorithm by Sagar Paul. Below is a quick and awesome visual summary from the community space, adapted from the original piece by one of our readers, Marina Flat, Vice Chair at IEEE Blockchain Montreal, and AI Solutions consultant.
(*click images in gallery for full view)
Sourced from the community, refer to the full summary here.
If this piques your curiosity, below is the original essay.
The Wheel and the Algorithm | Part 1
What a chance encounter on an Amtrak train revealed about the nature of technological revolutions.
Part 2
The Engineering Problem Nobody Talks About
In my previous essay, I argued that AI adoption resembles the adoption of the wheel. Not in its conceptual difficulty, but in the gap between having the technology and deploying it usefully. The wheel sat around for centuries before the enabling infrastructure made it transformative.
But I glossed over something important: what made the wheel work in the first place.
The answer is the axle. And understanding why the axle was hard helps explain why connecting AI to enterprise operations is hard, and what to do about it.
Why the Axle became the Breakthrough
A 2024 computational mechanics study published in Royal Society Open Science examined the evolution of the wheel-and-axle system. The researchers concluded that it evolved over roughly 500 years, progressing from simple rollers to grooved rollers to wheelsets to independent rotating wheels. Their key finding was striking:
The complex number of factors that had to be overcome meant it could not have been developed in phases. It had to come all at once.
Think about what a functional axle requires. The hole in the wheel and the axle shaft must be nearly perfectly round and smooth. The tolerances must be tight enough to prevent wobble but loose enough to allow rotation. The axle must be strong enough to bear loads but thin enough to minimize friction. Lubrication must be consistent. Materials must withstand repeated stress.
None of these problems is visible when you watch a log roll across the ground. All of them become apparent when you try to build something that actually works.
The wheel was the visible innovation, the one everyone could understand. The axle was the precision engineering that made it useful. The wheel got the credit. The axle did the work.
The Same Problem, Different Materials
AI models are the wheel. They spin impressively. Everyone can see them work. Executives watch demos and understand, at least superficially, what is happening.
But connecting these models to enterprise data and workflows is the axle problem. It requires solving multiple precision challenges simultaneously, just as the ancient wheelwright had to solve roundness, tolerance, strength, and lubrication all at once.
The enterprise axle problem has four tolerance challenges.
Format Tolerance
Your enterprise data exists in dozens of forms, including relational databases, JSON APIs, Excel spreadsheets, PDF documents, legacy mainframe exports, and real-time event streams. AI models expect consistent, well-structured input. The gap between these realities is where most integration projects die.
Quality Tolerance
AI models are sensitive to data quality in ways that traditional tools don’t catch. A customer record missing a middle initial might be fine for a mailing list but catastrophic for an identity verification model. Quality requirements are use-case specific, not generic.
Temporal Tolerance
Enterprise data exists across multiple time horizons. Some updates in real time. Some refresh daily. Some is quarterly. Combining data from different time periods without understanding their temporal relationships creates subtle but serious errors.
Semantic Tolerance
The same word means different things in different systems. “Customer” in your CRM differs from “customer” in your billing system. “Revenue” in sales dashboards uses different definitions than “revenue” in financial statements.
Just as the ancient axle required solving roundness, strength, tolerance, and lubrication simultaneously, the enterprise AI connection requires solving format, quality, temporal, and semantic challenges together.
Solve three of four, and the wheel still doesn’t turn.
The Enabling Ecosystem
Of course, even a perfect axle doesn’t create value alone. The wheel-and-axle system became transformative only when the broader ecosystem developed. This included roads for efficient travel, draft animals for pulling loads, social structures for trade, and maintenance craftspeople in every settlement.
Historical sources discuss wheeled transport as an integrated system, not as separate components. Rome’s 400,000 kilometers of roads, the Han Dynasty’s Silk Road trade routes, and the Incas’ 40,000 kilometers of highways all represent civilizational achievements that required multiple enabling factors working together. No single element was sufficient.
(*click images in gallery for full view)
Sustainable Infrastructure
Roads are perhaps the most visible enabler. They represent the prepared environment that makes wheeled transport efficient. For AI, the analogous infrastructure includes data governance frameworks, API architectures, security controls, and monitoring systems. These are not exciting, just as roads are not exciting compared to chariots, but they determine whether the technology creates value.
Operational Power
Draft animals represent sustained operational power. For AI, this maps to compute infrastructure, model serving systems, and the engineering systems that keep everything running. You can have the best wheel and the smoothest road, but without something to pull the cart, nothing moves.
Directed and Informed Investments
Trade networks represent the economic context that justifies investment. For AI, this means clear use cases with measurable returns. Organizations that invest in infrastructure without a line of sight to value creation often abandon the effort before it pays off.
Human Intuition & Skill
Maintenance craftspeople represent ongoing operational capability. The wheelwright was essential in every settlement. Similarly, AI operations require continuous attention through monitoring for drift, updating for new data, and adjusting for changing requirements.
The axle makes the wheel useful. The ecosystem makes the whole system transformative.
Line of Sight
Societies that successfully adopted wheeled transport shared a critical feature: clear visibility from investment to outcome.
The Sumerian farmer could see that a cart tripled his grain transport. The Roman commander could see that supply wagons enabled sustained campaigns. The connection between infrastructure spending and practical benefit was visible and measurable.
When the connection is abstract, when you’re told that data infrastructure will eventually enable AI value without being shown the specific path, investment stalls. This is rational. Executives have seen too many multi-year transformation programs that delivered reports instead of results.
Enterprise AI investments often lack this line of sight. Budgets get approved for vague promises. Months pass. Consultants produce frameworks. Platforms get deployed. And the connection between spending and business value remains theoretical.
The Axle Problem Compounds This
Even organizations that have clear use cases find that integrating AI with their specific data and workflows takes longer than expected. The tolerances are harder to achieve than they appeared in the demo. By the time the system works, organizational patience has often expired.
Approach to “Precision Engineering”
What ancient wheelwrights were really inventing was not a component, but a way of engineering precision into a system that had to work under uneven loads, changing terrain, and repeated stress.
The axle succeeded because it embedded guarantees about fit, strength, and behaviour under motion.
The enterprise equivalent of the axle is not “data infrastructure” in the abstract. It is the data product. A discipline and an approach instead of hard-baked technology.
A data product is the smallest unit where line of sight is preserved.
It is designed backwards from an outcome, not forwards from a source.
It carries its context with it: what the data represents, how fresh it is, what quality threshold it meets, and what decisions it is safe to support.
This is what makes the axle manifest.
Without data products, the connection between effort and outcome remains indirect.
With data products, every integration decision is anchored to a specific use case and a measurable result.
Crucially, data products collapse what are usually treated as separate concerns.
Context does not live in documentation, provenance does not live in a governance portal, quality rules are not enforced after the fact but are embedded inline with analytics and AI workflows. Because they are all properties of the product itself.
This is the difference between assembling parts and engineering a system.
“Solve three of four, and the wheel still doesn’t turn.”
Most enterprise data engineering still operates in batches.
Sources are onboarded, pipelines are built, schemas are standardised, and reports are refreshed. When requirements change, the system stalls while changes propagate end-to-end.
Manufacturing learned long ago that this mode of operation does not scale in dynamic environments. The breakthrough came with Single-Minute Exchange of Die (SMED): a discipline for reducing changeover time so systems could adapt rapidly without stopping production.
Similarly, enterprise data ecosystems are uneven and constantly changing. Source systems evolve, definitions shift, and new AI use cases appear mid-stream.
Treating every change as a mini-transformation program guarantees delay.
Data products apply the same logic as SMED. They remove unnecessary coupling, make constraints visible, and localise change. Instead of re-engineering the entire system when requirements shift, only the affected product adapts.
The Axle: A Precision-engineered Connection Layer
Not another data platform or another point solution. But a precision-engineered connection layer that solves the tolerance problems simultaneously, because they have to be solved simultaneously.
Approach to Format Tolerance
Format tolerance is enforced through explicit product interfaces. Each data product exposes data in forms suited to its consumers (human or machine0, regardless of how that data is stored internally. Translation happens at the boundary, on demand, without forcing global standardisation that breaks under scale.
Approach to Quality Tolerance
Quality is defined relative to outcome, not as a universal hygiene rule. Each data product declares the quality guarantees it provides and the decisions it supports. A field that is optional in one context may be mandatory in another. Quality is enforced where it matters.
Approach to Temporal Tolerance
Freshness is treated as a first-class contract. Data products specify the time horizon they represent and the validity of combining them with others. When you query data from multiple sources, the system understands when each piece was current and whether combining them is valid for the analysis at hand.
Approach to Semantic Tolerance
Semantic alignment is maintained through contextual metadata. The system knows that “customer” means different things in different sources and translates appropriately. Data products encode domain definitions and translate between them when necessary. “Customer” is not reconciled globally, but interpreted contextually with traceability back to source definitions.
These tolerances are not solved independently. They are properties of a single engineered artifact. The result is that AI applications can connect to enterprise data without the months of custom integration work that typically kills projects.
The axle works. The wheel can turn.
Breaking the Historical Pattern
Here is where the historical metaphor reaches its limit, and where the opportunity becomes most interesting.
Ancient civilizations were prisoners of their environmental conditions. The Inca built 40,000 kilometers of roads through some of the world’s most challenging terrain, but never used wheeled transport. This was a rational calculation given their mountainous geography and lack of draft animals.
Sub-Saharan societies faced biological barriers: the tsetse fly made draft animals impossible across vast regions. Medieval Europe had the technology but lacked political coordination.
These constraints were fixed. You could not will horses into existence or eliminate endemic disease.
Enterprise AI Adoption Does Not Work This Way
The environmental conditions that block AI deployment, including fragmented data, legacy systems, governance gaps, and skill shortages, are not fixed constraints. They are variables. The question is how quickly you can identify which constraints actually bind and address them specifically.
This is what changes when you have a working axle. The feedback loop compresses dramatically.
Deploy an AI Use Case
See immediately where the tolerances fail, whether that’s where format breaks, where quality issues emerge, where temporal misalignment corrupts results, or where semantic confusion produces errors. Fix the specific gaps. Redeploy. Measure.
Progress is visible at each iteration. You are not waiting for environmental conditions to align. You are actively shaping conditions based on empirical feedback.
Line of sight is restored. Executives don’t take on faith that data infrastructure will eventually enable AI. They see specific use cases moving from concept to production, specific blockers resolved in specific timeframes.
Industrialising the Axle
Once the axle is understood as a data product discipline and tolerances are identified, the remaining challenge is scale. Ancient societies solved this by standardizing tools, techniques, and training so that wheelwrights could reproduce reliable axles across settlements.
Modern enterprises face a similar challenge: how do you enable many engineering teams to build their own precision-engineered connections without each team reinventing the fundamentals?
A data operating system construct acts as a standardized workshop that makes building axles repeatable at enterprise scale. It is not the axle itself, but the means through which precision-engineering is first established, and then reproduced.
Operating systems have been at the heart of enabling masses to access and leverage countless benefits of digital applications without the need to be skilled in infrastructure and dirty plumbing. Even app developers who are into heavy engineering need not bootstrap the whole system to build their applications. Instead, they put together different unique capabilities available on the OS to spin up these applications and deploy at scale.
~ Data Operating System, The Philosphy
DataOS, as the platform implementation, provides the essential building blocks that data engineers need to create, operate, and evolve data products: standardized interfaces for format tolerance, embedded quality contracts, temporal awareness for time-based alignment, and semantic translation capabilities.
These aren’t abstract platform capabilities, but the practical tools that let engineering teams solve the four tolerance challenges simultaneously for their specific use cases.
Every enterprise needs different axles. A manufacturing company’s supply chain and AI for inventory requires different precision engineering than a bank’s fraud detection system.
But both need to solve the same fundamental tolerance problems. DataOS, by virtue, reduces the cost of that precision engineering to make it possible for domain teams to build outcome-first, context-rich data products without each team having to invent their own approach to format conversion, quality validation, temporal alignment, and semantic translation.
In the analogy, DataOS is the workshop that gives every wheelwright the standardized tools, jigs, and techniques to build reliable axles, while the wheelwright still does the precision engineering work for their specific cart and terrain.
The Leapfrog Opportunity
In the historical pattern, late adopters were permanently disadvantaged. Societies that missed the wheeled transport revolution couldn’t catch up until underlying conditions changed, which often took centuries.
The AI adoption pattern is different.
Organizations that start behind, with messier data, more legacy systems, and more governance gaps, are not necessarily condemned to stay behind. If they can identify their specific blocking factors and address them rapidly, they can leapfrog competitors who are still trying to boil the ocean with multi-year transformation programs.
The advantage goes not to whoever has the cleanest starting position, but to whoever can iterate fastest. And iteration speed depends on having infrastructure that makes the feedback loop tight: deploy, observe, fix, redeploy.
This is the opportunity that most enterprises don’t yet see. They assume they must spend years preparing before AI can deliver value. They budget for eighteen-month transformation programs. They hire consultants to build roadmaps.
Meanwhile, organizations that solve the axle problem first are already iterating. Each iteration makes them better. Each deployment generates data about what works. Each failure teaches them something specific. The gap widens not because of better technology, but because of faster learning.
Results Need Action
The wheel took millennia to spread globally. The institutions that accelerate technology transfer today, including venture capital, research universities, global supply chains, and digital communication, simply did not exist.
AI is spreading in months, not centuries. What took generations now happens in budget cycles.
This compression changes the nature of the challenge.
Organizations do not have the luxury of waiting for conditions to be right. By the time conditions are right, competitors who shaped their own conditions will have moved on.
But the compression also creates opportunity.
The same speed that threatens laggards empowers fast movers. If you can identify what’s blocking you, not in a theoretical multi-year roadmap but in concrete, measurable terms, you can address it now. If you can solve the axle problem, you can start turning the wheel while others are still building roads they may never need.
The historical metaphor is useful for understanding patterns. Enabling infrastructure matters. Adoption is uneven. Resistance is rational. Context shapes deployment.
But history is not destiny.
The Sumerian farmer could see that a cart worked because grain moved faster. He could not, however, conjure roads or draft animals into existence. His adoption was constrained by environmental conditions beyond his control.
We are not similarly constrained.
The environmental conditions that determine today’s AI adoption, including data infrastructure, integration architecture, governance frameworks, and workforce capability, are within our power to change. Not easily or instantly. But measurably, iteratively, with clear line of sight from investment to outcome.
The wheel works fine. The question is whether you have the axle to make it turn.
Author Connect 🤝🏻
Discuss shared technologies and ideas by connecting with our Authors or directly dropping us queries on community@moderndata101.com
Connect with Sagar on LinkedIn 🤝🏻
MD101 Support ☎️
If you have any queries about the piece, feel free to connect with the author(s). Or feel free to connect with the MD101 team directly at community@moderndata101.com 🧡
From MD101 team 🧡
🧡 Join 1500+ on The State of Data Products
Introducing The Catalyst, a special edition of The State of Data Products that compiles insights around the ups and downs in the data and AI arena that fast-tracked change, innovation, and impact.
📘 The Catalyst, first release is our annual wrap-up that compiles the most interesting moments of 2025 in terms of developments in AI & data products, with expert insights from across the industry.
Some focal topics
The gap in AI readiness for enterprises
The shift towards context engineering
Addressing governance debt with a focus on lineage gaps
Revisiting fundamentals for better alignment b/w business vision and AI.
 | A guest post by
|