The problem the BI industry can't fix from where it's standing
Every enterprise software vendor on earth is now trying to do the same thing: make a large language model useful on top of a company's data. LLMs are extraordinary at language - they write working SQL, explain joins, draft commentary. For the first time it looks possible to put a natural-language interface in front of enterprise data and let executives ask questions directly.
It hasn't worked, and the reason is not a model-capability problem. An LLM can write the query. It cannot know whether the query is the right question to ask, whether the columns it joined represent what the business means by those terms, or whether the answer contradicts a rule that has never been written down. It guesses, and it guesses fluently. That is the problem.
They have no model of the business. They have a model of the data. Those are not the same thing - and the gap between them is where every Text-to-SQL demo quietly fails.
For descriptive questions on well-understood domains - "what was revenue last month, by region" - the guess is often right, and warehouse-plus-LLM is good enough. For the questions decision-makers actually ask - why did margin miss target, what changes if we shift this assumption, which constraint is now binding, which initiative is moving the value driver - the guess is almost always subtly wrong, and the user has no way to tell.
The industry's reflex: bolt on a semantic layer
Every major data and BI vendor has reached the same diagnosis and the same response. Snowflake added Cortex. dbt has a semantic layer. Databricks has Unity Catalog and Genie. Microsoft has Fabric semantic models and Power BI Copilot. Palantir built an ontology over Foundry. The pattern is identical: add a layer between the warehouse and the LLM that tells the model what the data means.
It is a reasonable response - and a partial one. A semantic layer maps physical columns to business names, encodes a handful of measures, and captures some entity relationships. On clean, well-bounded data it materially improves Text-to-SQL accuracy. But by construction it is a description of what is in the warehouse. The most consequential things about a business were never in the warehouse to begin with.
You can keep extending the semantic layer until it becomes an executable representation of how the business works. At which point you have a digital twin - built on the wrong foundations, in the wrong tool, by the wrong team. That is roughly where Palantir's ontology has been heading for years, and how far it has had to travel should tell you something.
What AI actually needs to reason about a business
Reason reliably across an enterprise and the requirement breaks into five elements. A semantic layer addresses one of them well and a second partially. A twin addresses all five natively.
-
Structure
How entities relate in the language of the business - sites within business units, circuits within plants, initiatives within strategic plays, decisions within governance forums. Not a star schema; the operational geometry of the company.
Semantic layer: partialTwin: native -
Business logic
How value is actually calculated, what rules apply where, and which rules trump which. "Sustaining capex excludes regulatory step-changes captured under Growth." "Throughput is bounded by the binding constraint, not nameplate capacity." None of these are columns. They are rules.
Semantic layer: not encodedTwin: native -
Metadata
Facts about the operating world that shape every calculation and never live in transactional systems - plant capacity, working days, maintenance windows, commodity grades, asset lives, regulatory thresholds. A warehouse has invoices; it does not have "this plant has a 22-day shutdown in Q3".
Semantic layer: not encodedTwin: native -
The data itself
Actuals - transactions, sensor readings, financials, headcount, safety events. This is what warehouses and lakehouses do well, and a twin-first architecture deliberately does not compete with them. The twin reads from where the data already lives.
Warehouse: nativeTwin: reads it -
Security, access control & auditability
Who can see what, who changed what, why an answer is what it is, which version of the rules was applied. Row-level security on tables is a brittle proxy for "the GM should see everything within her scope of accountability". Retrofitted provenance is almost always weaker than provenance designed in.
Semantic layer: at the marginsTwin: designed in
A semantic layer exposes element 4 well, captures element 1 partially, touches element 5 at the margins, and does not encode elements 2 or 3 in any meaningful sense. That gap will not be closed by making the semantic layer thicker. It is structural.
What ManagedAnalytics does differently
We built the platform from the other end. We started with the meaning. The foundation of Helm is a digital twin of the business - an executable representation of how the company actually works - and it natively encodes all five elements above. Assets, processes, value chains, costs, revenue drivers, constraints, organisational rules, planning assumptions, definitions, decisions and their metadata are all first-class objects. The data layer - Snowflake, Databricks, Fabric, on-prem warehouses, operational systems - plugs into the twin. The data is an input to the twin, not the thing the twin describes.
The AI Analyst sits above the twin and reasons over it. Asked "why did margin miss target", it does not generate a SQL query and hope the join was right. It walks the value-driver tree the business has agreed on, decomposes the variance using rules written down in software, identifies the binding constraint, traces it back to the operational mechanism that caused it, and shows its working. The answer is reproducible, auditable, and grounded in the same model the CFO uses for the board pack.
We build the twin itself with AI. Digital twins were once multi-quarter, expert-led exercises confined to a single asset - a refinery, a mill, a mine. AI-assisted modelling cuts that to roughly 20% of legacy cost, putting enterprise-wide twins within reach for the first time.
This is the substantive shift. Not "AI on top of the warehouse" - a model that natively encodes the business, with AI both inside it (as the analyst) and underneath it (as the construction toolchain). Everything else in the platform - the modules, the Strategy Alignment cockpit, the Meeting Manager integration, the board packs - sits on that foundation.
Why semantic-first will always come up short
There are three reasons the bolt-on path does not catch up, and they are not incremental.
A glossary over the data.
Physical columns mapped to business names, a few measures encoded, some relationships captured. The LLM still generates SQL against tables and hopes the definition matches what the user means today.
A model of the business itself.
Structure, logic, metadata, constraints and decisions encoded as first-class objects. AI reasons over the model and executes the rule, rather than approximating it in generated code.
Causality is not a label.
You can attach an "is_revenue" tag to a column. You cannot, with the same machinery, attach the rule that revenue is downstream of throughput, downstream of equipment availability, downstream of maintenance scheduling, downstream of capital-project sequencing. That is a structural model of the business - at which point the only question is whether you admit it is a twin.
Logic in the semantic layer is still a translation problem.
Even when a measure is encoded, the LLM still has to choose the right one, compose it, and trust the definition matches what the user means today. It is not running the rule - it is generating code that approximates it. Rules change quarterly; the layer has to be hand-updated with downstream effects nobody traces. Translation chains lose information at every step.
The most important knowledge isn't in the warehouse.
Planning assumptions, capital-allocation policy, last month's ExCo decisions, the constraint the operations director has worked around for two quarters - none of it lives in a fact table. No amount of semantic enrichment surfaces what isn't there. A twin includes these objects natively, because it was built to model the business, not to label the data.
Why the digital twin approach is both more effective and cheaper
There is a second bill arriving with warehouse-first AI, and it is only now becoming visible. Snowflake's recent results1 make the pattern plain: as enterprises put AI agents to work against the warehouse, consumption - and cost - climbs sharply. Agentic data access is expensive by nature. Where a human analyst asks one considered question, an agent reasoning its way to an answer issues many - probing schemas, sampling rows, retrying, and extracting and re-extracting data across multiple round-trips. The warehouse meters every one of them.
Helm's architecture inverts this. Because the digital twin already encodes the structure, logic and relationships of the business, it is the twin - not a swarm of agents groping through tables - that formulates the queries. Paired with a hyper-optimised backend, that collapses the number of database queries behind any given answer by orders of magnitude. The model already knows where to look, so it does not have to search to find out.
The same context makes every call leaner. An agent working against a bare warehouse spends most of its tokens on discovery - working out what the data is before it can use it. The twin has already done that work, so its queries carry far less ballast: fewer tokens, far less trial-and-error, and substantially lower cost per answer. The more questions the business asks, the wider that gap grows.
The twin answers better and cheaper for the same reason - it already knows where to look.
What twin-first does not solve
A position is more credible when it names its own limits, so we are direct about what a twin-first approach does not deliver.
A twin still requires the business to decide its rules.
AI accelerates construction; it does not decide how value moves or how a contested definition should be set. If your internal answer to "what is sustaining capex?" is "depends who you ask", the twin makes you resolve that - it does not bypass it. We consider that a feature, and we say so up front.
A twin must be maintained.
Businesses change - new plants, new product lines, restructures, divestments. AI-assisted maintenance is part of how we run twins at enterprise scale, but model governance, internal ownership and change tracking are real questions, and the buyer should ask them.
For descriptive ambitions, twin-first is overkill.
If your analytical ambition is bounded by dashboards on well-understood data, a good semantic layer on a clean warehouse will get you where you need to go. We do not pitch against that buyer.
A twin is a model, and all models can be wrong.
The right governance is provenance, version control, auditability and human accountability for the rules encoded inside it. We surface lineage and confidence on every answer; we do not absolve anyone of the obligation to read them.
Closing
The first wave of enterprise AI is being built on warehouses, with semantic layers bolted on top. It will produce real value on descriptive tasks. It will keep struggling on the questions executives actually need answered, because the architecture is wrong for the question.
The second wave will be built on models of the business itself, with AI inside the model rather than outside it. That is not a future bet. It is the foundation Helm has been built on for years, and the reason customers in the most operationally complex industries on earth use us where they used to use a board pack assembled by hand.
A model that understands your business is not a slogan. It is a specific architectural choice, with specific consequences - and it is the choice the rest of the industry is going to spend the next several years trying to rebuild towards. We started there.
- “Software sector rallies as Snowflake results soothe broader AI fears” (Investing.com, 29 May 2026). finance.yahoo.com. On Snowflake’s agentic-AI data direction, see “Democratizing Enterprise AI: Snowflake’s New AI Capabilities…” (3 June 2025). snowflake.com ↩