Where does the data live that feeds a judgement layer?
The modern data stack narrative (Snowflake vs. Databricks, the lakehouse vs. the warehouse) is largely a Silicon Valley sideshow. In the real enterprise world, the story is about the tightening grip of the Systems of Record.
For the 200,000+ companies running on SAP, the biggest shift in their technology landscape isn’t an LLM. It’s RISE with SAP. On the surface, it’s a cloud migration and a “Clean Core” strategy. In reality, it is a sophisticated data consolidation maneuver. By moving companies into proprietary cloud environments, incumbents are constraining your ability to build an independent judgement layer.
When your business logic is locked inside a proprietary environment in the name of standardization, your ability to apply vectors of judgement is limited to the directions the vendor allows.
The Real Enterprise Landscape
The conversation about enterprise AI infrastructure tends to center on companies with dedicated data teams running Snowflake, Databricks, or Fabric. This describes roughly 30,000 organizations globally. They matter, but they’re not the majority.
SAP alone has over 200,000 customers. Add Oracle, Microsoft Dynamics, Infor, and the rest of the ERP ecosystem, and you’re looking at the vast majority of enterprises above €100M in revenue. These companies don’t have lakehouse architectures. They have ERP systems, Excel, and meetings. Their data lives inside transactional systems that were designed to run the business, not to feed external intelligence layers.
For these organizations, the question isn’t “which semantic layer do we choose?” It’s “can we get our own data out?”
What RISE Actually Means for Your Data
SAP’s RISE initiative is marketed as a cloud transformation. Move to a clean core. Standardize your processes. Get AI-ready. The pitch is compelling, and for many organizations the operational benefits are real.
But there’s a second effect that doesn’t appear in the sales deck.
Today, companies running SAP on-premise or in their own cloud tenancy have direct database access. They can extract, replicate, and analyze their data with tools of their choosing. There are limits. SAP already throttles extract volumes, capping gigabytes per hour or per day through standard APIs. Write access is more tightly controlled. But the data is reachable.
RISE changes the infrastructure model. SAP manages the environment. The database sits inside SAP’s cloud perimeter. The access patterns SAP permits become the access patterns you get. Organizations migrating to RISE are already discovering that the data extraction pipelines they built over the past decade need to be renegotiated, not just migrated.
This isn’t about SAP being adversarial. They’re running a business, and controlling the infrastructure their software runs on is a rational strategy. But for the enterprise building a judgement layer, or any independent intelligence layer, the implications are significant. Your ability to reason about your own business becomes mediated by the access your system of record vendor permits.
The Integrator Tax
The same dynamic plays out across the ERP landscape, not just SAP. Oracle’s cloud migration creates similar dependencies. Microsoft’s Fabric integrates tightly with Dynamics 365, convenient if you’re all-in on Microsoft, constraining if you’re not.
Each of these vendors is adding AI capabilities inside their perimeter. SAP has Joule. Oracle has its AI agents. Salesforce has Agentforce. These are useful features. They’re also strategic moves to ensure that when enterprises want AI-driven insights, the path of least resistance runs through the system of record, not around it.
This creates what I’d call the integrator tax. Every time you want to combine data from your ERP with data from your CRM, your supply chain visibility platform, your market intelligence feeds, or your planning tools, you pay a toll in complexity, latency, and permission. The more your systems of record tighten their grip, the higher that toll becomes.
The enterprises that noticed this early have been building data archives: copies of their operational data in open formats on infrastructure they control. S3 buckets, Azure Data Lake, BigQuery datasets. Not to replace the system of record, but to ensure they can still reach their own history when the access rules change.
For any organization considering a RISE migration or similar move: archive your existing database in an open format before you migrate. Not because the vendor is malicious, but because once the infrastructure changes hands, renegotiating access is harder than preserving it.
Context Caching, Not Data Ownership
There’s a common objection to maintaining data copies: “You’re duplicating data. That creates governance problems. Which copy is the source of truth?”
This is a category error.
When your browser loads a website, it creates a local copy of assets in cache. Nobody argues this creates a “governance problem” about which copy of the CSS file is authoritative. The origin server is the source of truth. The cache is a working copy that enables performance.
A judgement layer needs the same relationship with systems of record. It doesn’t modify source data. It doesn’t compete with the ERP for transactional authority. It reads data from external systems (CSV exports, APIs, direct database connections) and holds a working copy for the duration of its analysis. The system of record remains the system of record. The judgement layer is a cache with reasoning on top.
Read-only access is an architectural principle. The moment an intelligence layer can modify source data, it becomes entangled with the transactional system. It inherits the vendor’s access controls, the vendor’s release cycle, the vendor’s permission model. It loses independence.
Read-only access preserves the judgement layer’s ability to reason freely across data from any source, in any combination, without asking permission from any single vendor.
Building on Open Ground
The systems of record aren’t going away. They shouldn’t. They’re good at what they do: managing transactions, enforcing business rules, maintaining the authoritative state of the business.
The judgement layer, the infrastructure that captures why decisions were made, tracks reasoning accuracy over time, and compounds organizational intelligence, needs to sit on open ground. It needs to connect to SAP and Salesforce and Oracle and the planning tools and the market data feeds, without being owned by any of them.
This means the judgement layer must be:
Source-agnostic. It connects to whatever the customer runs. Not just the modern data stack. The messy, real-world stack of ERPs, spreadsheets, and legacy systems that actually run enterprises.
Read-only by design. It never modifies source data. The system of record remains authoritative for transactions. The judgement layer is authoritative for reasoning.
Portable. The organization’s captured judgement (calibration data, reasoning templates, institutional memory) belongs to them. Not to the vendor who built the layer.
The context graph conversation has focused on where the data lives and who gets to query it. The harder question is: who gets to build the reasoning layer on top, without being beholden to the platform underneath?
The answer has to be the enterprise itself.