Context Gravity vs. Data Gravity: Enabling actionable AI in distributed landscapes with SAP BDC

[stojanm]

In recent years, there has been a strong push towards distributed data landscapes — bringing compute closer to where data lives (data gravity), enabling more capable AI across more data sources. But this shift has in many cases also moved AI further from the context needed to act on what it finds. This blog series is about an equally important force: context gravity — the pull that business context exerts on AI output, drawing predictions toward the systems where they become actionable.

Data gravity is a volume argument: compute should run where the majority of data is, because moving large datasets is expensive and slow. And it is a valid argument. Context gravity on the other hand is a different type. It is not about the volume of the data — SAP master data is modest in size compared to sensor streams or transaction logs. It is about the complexity, dynamics, and relationships contained in this data. A contract table might have a few hundred rows. But those rows are connected to customer hierarchies, credit exposure, service organizations, approval workflows, and penalty structures that have been modelled, governed, and maintained over many years. That network of facts and information is what makes a prediction actionable — and it is next to impossible to be replicated by simply moving a file.

The following example from a recent customer engagement makes that concept more concrete.

A manufacturing company had moved from selling equipment to selling outcomes — guaranteed uptime, defined OEE targets, contractual SLA commitments. The engagement covered ten assets, seven active contracts — a total at-risk exposure of roughly €20,000/day (illustrative figure) across the portfolio. The IoT sensor data from the shop floor was stored in a data platform; contract terms, financial data, maintenance records as usual in SAP. A model that could predict machine failure had no way, on its own, to know which contract was at risk, what the penalty clause said, or whether the right technician was available. A machine with 1.1 days to failure means something very different if the contract expires in 91 days than if it expires in 2. That gap — between a technically correct prediction and a decision someone (a human or an AI agent) could act on — is what this series is about. It discusses how SAP Business Data Cloud(BDC) helps to provide the right context for AI to make it business relevant.

This series consists of several blog posts, which will be updated once published:

1. Overview: Context Gravity vs. Data Gravity: Enabling actionable AI in distributed landscapes with SAP BDC <- This blog post
2. The business case: Outcome-Based Manufacturing in Practice: Managing SLA Risk Across Industrial Assets with AI
3. Implementation and solution architecture: Cross-Platform AI Pipelines in Practice: Combining IoT Data and SAP-RPT-1 for SLA Risk Scoring
4. Closing the loop: Outcome-Based Manufacturing and SAP Joule: From SLA Breach Prediction to Autonomous Prevention

Ok, let's start reviewing the details.

Two systems, one problem

The data landscape of this manufacturing customer matched the standard enterprise split: IoT sensor and operational data (shop floor) in the customer's data platform (here Snowflake), contract terms and financial data in SAP (top floor). The ML problem required both, and we considered two ways to bring them together — the two failure modes that enterprise AI projects on SAP landscapes typically fall into.

The first option: move the SAP data into the customer's data platform and run the model there. This would have solved the compute problem — the warehouse has the tools and the scale. But it would have created a governance problem. SAP master data is authoritative, frequently updated, and subject to strict access controls. Copying it into a warehouse introduces staleness, duplication, and compliance exposure. The model would have ended up running against a copy of the truth, not the truth itself.

The second option: build the model close to the SAP data, using SAP's analytics capabilities. This would have kept the data in place and avoided the governance risk. But it would have created an integration challenge — the IoT signals the model also needed were already established in the customer's data platform, alongside the pipelines, tooling, and data engineering expertise built around them. Moving that workload would have introduced the same copy-and-ETL problem in reverse. The model would have ended up working with an incomplete or delayed picture of the shop floor.

Both options reflect the complexity of enterprise landscapes where data is distributed by design — different systems optimized for different purposes. The mechanism that resolved this for the project was SAP BDC Connect, which links SAP Business Data Cloud to external data platforms using zero-copy technology — without copying data, without ETL pipelines, and without synchronization schedules. It keeps each system handling what it does best. More details can be found in this blog post.

The sharing via SAP BDC Connect works in both directions. SAP‑managed data products — e.g. plant maintenance records, contract master data — can be selectively shared outward to the data platform so that models running there have the specific slices of business context they need as training and inference inputs. Predictions and derived data products — time‑to‑maintenance scores, risk classifications, anomaly signals — can be shared back into BDC, as custom data products, where they can be joined with the rest of the SAP context and the authoritative semantics stay in one place.

A data product shared outward carries its values. It does not carry what surrounds it in SAP — the customer hierarchy it belongs to, the credit exposure linked to that account, the service organization responsible for a breach, the approval chain a penalty triggers. Those relationships are not columns in a table. They are a system: connected, governed, and continuously updated and trying to replicate that system outward is, in practice, rebuilding SAP in a different system. Context gravity is the architectural argument that it is cheaper — and more correct — to bring predictions to where that system lives than to move the system to where the predictions run. Because the actual business relevance comes from the whole context, rather than the context slices, which are available to the external platforms for their workloads. 

So, the strategic value of this setup was not just technical convenience. It meant the choice of data platform became a reversible decision rather than a constraint — providing more flexibility than in architectures where the context is baked into whichever warehouse you happened to build in first.

From sensor to risk score

Here is how this works in practice.

The diagram shows six steps that make up the full data flow:

1. SAP source systems — S/4HANA plant maintenance records, asset master data, contract and financial data — are available through SAP Business Data Cloud as data products.
2. IoT sensors and devices on the shop floor stream readings into the customer's data platform — vibration, temperature, pressure, fault history.
3. SAP-managed data products are shared outward to the data platform via BDC Connect. No copy is made; the data remains authoritative in SAP.
4. ML Model #1 runs in the data platform against the combined dataset. It produces one prediction per asset: days until next required maintenance (time-to-maintenance, TTM).
5. The TTM predictions are shared back into SAP Business Data Cloud via BDC Connect as a custom data product — a single float per asset, traveling in the opposite direction to step 3.
6. ML Model #2 runs in BDC, joining the TTM prediction against eight further features from SAP and calls SAP-RPT-1 via the Generative AI Hub to produce a breach probability per contract.

Let's review the two models in more detail.

ML Model #1 — Time-to-Maintenance (TTM) ran in the customer's data platform. It ingested the IoT sensor features — vibration, temperature, pressure — alongside plant maintenance records shared via BDC Connect. A Snowpark ML RandomForestRegressor, deployed as a stored procedure, produced a single prediction per asset: days until next required maintenance. The output — a small JSON array of floats — was shared back to SAP BDC via the BDC Connect.

 But, as mentioned before, the TTM prediction alone was not useful. A days-until-maintenance figure provided value only after it was placed against the contract it affects. Four examples from the implementation worth mentioning:

• A sensor reading becomes a contract risk when you know the SLA target, the penalty rate, and the remaining days on that specific contract. Without that context, a vibration of 8.29 g RMS is a maintenance signal. With it, it is a €236,000 liability on a named customer.
• A maintenance prediction becomes a dispatch decision when you know which technician holds the relevant certification and whether they are already committed to another job. Without that context, you send the wrong person and discover the conflict on site.
• A breach probability becomes a financial provision when you know the GL account, the cost centre, and the document type the finance team needs. Without that context, the provision does not get posted until quarter-end.
• A component failure becomes a portfolio exposure when you know which other assets share that component under the same contract. Without that context, you fix one machine and miss the one next to it.

All this information cannot be inferred from the sensor data alone. It is located in S/4HANA plant maintenance structures, in contract and financial master data, in the HR structures that know which technician holds which certification, etc.

ML Model #2 — SLA Breach Probability runs against BDC. The TTM prediction arrives as an input feature and joins against eight further features: OEE, asset health score, open fault count, spare parts lead time, contract remaining days, target uptime, current uptime, production capacity utilization. This is where the context makes the difference — eight of the nine features come from business data, including both master data and transactional context.

The model was SAP-RPT-1, SAP's Relational Pretrained foundation model, called via the Generative AI Hub on SAP AI Core. RPT-1 uses in-context learning: you provide labelled historical rows directly in the API payload and the model scores the query rows against them. More details can be found in the following blog post.

The two models ran in sequence — TTM first, because its output is an input feature to Model #2. The orchestration was done via an agent built with LangGraph, which enforces this dependency through graph structure. More details will be shown in the technical blog post from the series.

The differentiating point in this pipeline were the contextual features, which were available within SAP BDC and made the breach probability meaningful. Without the SAP data, Model #2 cannot distinguish between a machine with 1.1 days to maintenance on a contract with 91 days and €2,855/day exposure (illustrative figure), and the same machine on a contract with 2 days remaining and no penalty clause. That gap — between a number and an actionable signal — is what the architecture is designed to close.

The main learnings from this project, can be summarized along the following four dimensions:

• Design for context gravity, not data gravity. The classical data gravity argument says compute should run where the data is because moving data is expensive. That is correct for sensor data and transaction logs. But SAP data is different — it is not primarily a compute substrate, it is a context substrate. The right principle is that predictions should travel to where the context is, not the other way around or into yet another outdated copy of the SAP model.
• The data platform choice is reversible; the context architecture less so. Choosing one data platform over another is an infrastructure decision that can be revisited. Choosing how to model contract terms, component hierarchies, and business relationships is a strategic decision that compounds over time. The SAP-managed data products in BDC together with the semantic layer is where the long-term AI advantage comes from.
• RPT-1 simplifies ML operations. The traditional ML pipeline for a classification problem like SLA breach prediction requires training data, a training run, a model artefact, a deployment, a retrain schedule, and version management. RPT-1 replaced all of this with labelled examples in a context window and a single API call. 
• The richer the semantic layer, the smarter the agents. An agent working with flat feature tables can score a risk. An agent that can also traverse contract coverage, component dependencies, and resource availability across the same context layer can turn that score into a decision. 

What comes next

The architecture described so far can tell you which contracts are at risk, how severe the exposure is, and roughly when a breach becomes likely.

The next posts in this series cover the full picture — the dashboard and agent interfaces built on top of this context architecture, how SAP Joule can operate as an action layer that surfaces risk proactively, and how a Knowledge Graph co-located with the context adds a relational dimension to what the models answer quantitatively. The context gravity principle stays the same throughout: the architecture does not change, only the intelligence layer above it is extended.

Have you seen similar patterns in your day-to-day business? If you are building on a similar stack or running into the same architectural questions, I am happy to compare notes.