.png)
In this interview, Steven Mellare shares his insights with Vanessa Jalleh to unpack how organisations can move beyond isolated AI experiments and design data architectures that enable compounding intelligence at scale. Steven explores the concept of the AI Flywheel - a self-reinforcing loop where data, features, model outputs, and outcomes continuously feedback into a unified lakehouse to improve decisions over time. The discussion cuts through the hype to focus on what’s actually required to make this work: strong enterprise data models, reusable AI signals, embedded governance, and observability that accelerates learning rather than slowing it down.
How do you define the ‘AI Flywheel’ in the context of data architecture, and what are the essential components organisations need in place before that flywheel can begin to turn?
The AI Flywheel is about turning isolated AI wins into a self reinforcing engine for intelligence. In data architecture terms, it’s a closed loop where every decision, outcome, and model output flows back into a unified platform—usually a lakehouse—so those signals can be reused to improve not just one model, but an entire ecosystem. Each cycle compounds insight and increases the organisation’s capacity for automation.
To get that flywheel turning, several foundations are essential, and the most important is an integrated enterprise data model. It provides the structure needed for consistent entities, flexible extensions, and scalable integration of model outputs and telemetry. I strongly advocate Data Vault for this, because it supports history, auditability, and change at enterprise scale.
Alongside this, organisations need a unified data platform with ACID compliant storage, a feature store and output registry for versioned signals, and telemetry pipelines that capture outcomes and overrides. Add governance for lineage and compliance, MLOps pipelines to automate retraining and deployment, and a roadmap that sequences high leverage models first—and you have the architectural conditions for the AI Flywheel to start generating compounding value.
What architectural shifts are required to ensure AI outputs can continuously feed back into the data lakehouse in a way that improves models over time?
To enable AI outputs to flow continuously back into the lakehouse and genuinely improve models over time, organisations need to shift from linear, model by model pipelines to an architecture that supports the network effect. That begins with making every prediction, outcome and override reusable—treating them as first class data products that are versioned, governed, and stored alongside core data. This only works if the underlying platform is built on a flexible, integrated data model, because that model provides the structure needed to incorporate new signals without constant rework.
On top of that foundation, you need the right mechanisms: a telemetry framework to capture decision events and performance signals; feature engineering patterns that anticipate cross model reuse rather than isolated feature sets; and strong lineage and governance so downstream consumers can trust what they're using. Combined with MLOps automation to trigger retraining based on telemetry and drift, you get an environment where models don’t just improve themselves—they actively accelerate one another through shared outputs.
Many organisations struggle with operationalising AI. What practical steps help teams move from standalone AI projects to a scalable, integrated flywheel where insights drive ongoing optimisation?
Operationalising AI at scale starts with a roadmap anchored in business imperatives. That must always come first. But once those priorities are clear, the architect can bring significant extra value by using a Model Interdependency Map to show how different AI workloads relate to each other, and applying Flywheel Leverage Scores to highlight which models create the strongest downstream benefits. This allows teams to sequence delivery so that early models generate reusable signals—such as segments, risk tiers, or intents—that amplify the impact of later ones.
The other crucial step is making the flywheel visible. Publishing KPIs like lift, delinquency delta, or cycle-time improvements—and showing which upstream models contributed to those gains—helps teams see how the ecosystem compounds over time. When people can see that one workload strengthens the next, optimisation becomes self reinforcing. That’s how organisations shift from isolated projects to a scalable, integrated AI flywheel.
How can data quality, governance, and observability be designed to support a flywheel approach without introducing bottlenecks or regulatory risks?
Supporting a flywheel approach means designing data quality, governance, and observability so they’re invisible in day to day work, but highly effective underneath. In the context of the six components of the AI flywheel — Data → Features → Outcomes → Telemetry → Governance → Better Data — the governance component is especially important. It acts as the quality gatekeeper that ensures each loop of the flywheel strengthens the next rather than introducing noise or regulatory risk.
The most practical way to achieve this is to embed quality at source: define SLAs for accuracy and timeliness, enforce schema and anomaly checks in ingestion pipelines, and treat feature and model output contracts as part of data governance, not an afterthought. Layer on policy driven access and explainability, where RBAC protects sensitive attributes and explainability services support human exception workflows. Finally, automate compliance hooks—privacy checks, bias detection, retention rules—so they run inside CI/CD pipelines rather than slowing delivery. When these safeguards are embedded in the platform and aligned to the governance component of the flywheel, the organisation gets continuous improvement without bottlenecks, and the flywheel can spin faster while staying safe
What are the biggest misconceptions you see when organisations attempt to build an AI-driven lakehouse ecosystem, and how can leaders avoid these pitfalls?
The obvious misconception is that simply adding an individual AI workload to a data platform will deliver sufficient value to your business. It’s just the first step. And in reality, without a feedback loop—telemetry and model-output registries— it's difficult to channel insights back into the AI ecosystem, where the flywheel risks stalling. Another older myth is that data modelling has become less important with modern technology. It hasn’t. Flexible, extensible data models remain critical for integrating new signals and scaling AI workloads effectively. And thinking one model at a time is enough ignores the real advantage: an ecosystem where models share outputs, such as segmentation and CLV informing marketing and guiding LLM-driven customer interactions.
Leaders can avoid these pitfalls by designing for continuous learning: capture outcomes and outputs as first-class data products, map interdependencies to sequence workloads for maximum leverage, embed observability so drift and performance issues trigger automated retraining, and ensure strong modelling foundations to support adaptability. When models learn from each other on a well-structured platform, the lakehouse becomes an engine for compounding intelligence.
Steven Mellare is a speaker at Data & AI Architecture Sydney 2026. Interested in learning more about Data? Join us at Data & AI Architecture Sydney this March!
Also don't miss CDAO Sydney and Enterprise AI Sydney, happening in the same space as Data & AI Architecture Sydney!
.png?width=352&name=CDAO%20Sydney%20(1).png)
-1.png?width=352&name=Malaysia%20(1)-1.png)