Glossary of SAP analytics language and architecture terms

How to read this glossary

A glossary earns its place when it changes how you talk in a design review. The danger with SAP analytics vocabulary is that the product names multiply faster than the concepts behind them, so people end up arguing about labels when the real disagreement is about ownership and sequence. I have grouped these terms by the job they help you do rather than alphabetically, because the question that matters is rarely "what does this word mean" and almost always "whose layer is this, and what does it commit me to next."

Read each group with a working question in mind. In Semantics and modeling, ask where business meaning is defined and who is allowed to change it. In Planning, ask whether the numbers people enter sit on the same governed foundation as the numbers they report. In Governance, lifecycle and trust, ask how a definition stays safe after go-live. In Modernization, ask what you are carrying forward and what you are deliberately leaving behind. In Integration, ask where data physically lives and who owns the connection. And in AI and agents, ask what the model is allowed to act on, and how you would catch it when it is confidently wrong. When a term becomes clear, the right move is to return to the topic hubs, an architecture page, or the learning path where the actual decision still waits.

Read terms by job — Semantics and modeling

This is the layer where business meaning is defined once and reused everywhere. Most analytics failures I am asked to fix are not tooling problems; they are semantic problems wearing a tooling costume. The terms here describe how SAP turns raw tables into trusted, governed meaning, and where that responsibility belongs.

SAP Analytics Cloud (SAC)

SAP's cloud surface for business intelligence, planning, and predictive analysis, where most business users actually live. It is best understood as a consumption and decision layer rather than a place to define semantics: stories and planning models should sit on governed meaning defined downstream, not invent their own. Treating SAC as the system of record for business definitions is the most common way teams fragment their own numbers.

Story

The core authoring and viewing object in SAC, where charts, tables, input forms, and narrative are assembled into an interactive page. A story is a consumption surface, not a model, so the discipline is to keep query and calculation logic minimal inside it and let the semantic layer carry the definitions. Stories age badly when they accumulate local logic that quietly disagrees with everyone else's.

Optimized Story Experience

SAP's unified, responsive model for editing and viewing stories on a single modern canvas. Since SAP deprecated the Classic Experience at the end of Q2 2026, it is the only story experience: classic stories, analytic applications, and classic Data Analyzer insights are no longer accessible, and SAP's Story Conversion Tool handles bulk migration. Its practical value is consistency: one canvas means fewer surprises when content moves between authoring and consumption, on a desktop or on a phone.

SAC Planning

The planning and forecasting capability built into SAC, where users enter assumptions, run versions, and write values back rather than only reading them. Its architectural value appears when planning models sit directly on a governed semantic foundation, so the dimensions and hierarchies people plan against are the same ones they report on. Planning that runs on its own imported copy of the data eventually drifts from reporting, and reconciling the two becomes a recurring tax.

Analysis for Office (AfO)

An Excel-based client that lets analysts query SAP models, including BW queries, inside the spreadsheet they already trust. With SAP Datasphere it reaches only analytical datasets, a deprecated object type; Datasphere analytic models are consumed in Excel through the SAP Analytics Cloud add-in for Microsoft Office instead. It remains widely used in finance because it preserves the grid-and-formula muscle memory of power users while still reaching governed data. The design caution is the same as with any spreadsheet front end: it is a consumption tool, and business logic that migrates into local workbooks is logic that has escaped governance.

SAP Datasphere

SAP's data fabric and semantic modeling environment, and in most landscapes the right place for business meaning to be defined and governed. It combines federation, replication, modeling, and access control so that one definition of revenue or customer can serve many consumers. I treat Datasphere as the center of gravity for analytics: not "our analytics database" but the layer that decides what the numbers mean before any tool renders them.

Datasphere Spaces

Logical containers in Datasphere that isolate teams, domains, or projects while still sharing a common modeling fabric underneath. Spaces carry their own storage allocation, access controls, and member lists, which makes them the unit of decentralized ownership in an otherwise shared platform. Used well, they let a finance domain and a supply-chain domain move at their own pace without colliding; used carelessly, they recreate the silos the platform was meant to dissolve.

Analytic Model

Datasphere's consumption-ready modeling object that organizes data into a star schema of facts and dimensions with semantic types, associations, hierarchies, and measures. Built in the Data Builder (the Business Builder is deprecated), it is the object you expose to SAC over a live connection, to Excel through the SAP Analytics Cloud add-in, and to other clients through Datasphere's OData consumption APIs, so it is effectively the contract between modeling and consumption. Analytic models can be stacked on other analytic models and shared to other spaces. Getting the analytic model right is what lets one definition serve a dashboard, a spreadsheet, and a data-science notebook without three different answers.

Fact and Dimension

The two structural roles in dimensional modeling: facts hold the measurable events such as revenue, quantity, and cost at the lowest sensible granularity, while dimensions describe the context such as customer, product, date, and region that you slice them by. Keeping this separation honest is what makes drill-down, aggregation, and conformed reuse behave predictably. When facts and dimensions blur together, queries become brittle and the same question starts returning different totals depending on who asks.

Semantic layer

The shared tier where business concepts are defined, governed, and made reusable, sitting between raw storage and the tools people actually open. Its whole purpose is to move definition out of individual dashboards and into one place, so that changing the meaning of a measure is a deliberate, traceable act rather than an accident discovered in a board meeting. In a SAP landscape this layer mostly lives in Datasphere, and it is the single most important control point for trust at scale.

Model stacking

The practice of building models on top of models in Datasphere so that business logic is encapsulated at distinct levels of abstraction: stable core semantics underneath, domain composites in the middle, and lightweight consumption views on top. Stacking eliminates duplication, because one domain owns a definition that everyone else inherits rather than re-deriving it. It costs more governance up front and pays back as analytics velocity later, since a corrected definition propagates everywhere instead of being patched in twenty places.

Data Access Control (DAC)

Datasphere's mechanism for enforcing row-level security at the semantic layer, so that authorization travels with the data and a sales representative sees only their territory in every story built on the model. A DAC reads a permissions entity (user IDs plus the values each user may see), several DACs on one object combine with AND, and SAP documents the filter for every user who reads the object directly or through a dependent object—when it is shared to another space, when SAC consumes it, and even in Data Builder previews. This is the architectural argument for defining security in the semantic layer rather than re-implementing it inside every downstream report, where it inevitably diverges.

Live versus import connection

The two fundamental ways SAC reaches data: a live connection queries the source in real time and leaves the data where it lives, while an import connection pulls a copy into SAC's own store. Live connections keep a single source of truth and honor source-side security but depend on source performance and network latency; imports decouple performance from the source at the cost of freshness and an extra copy to govern. The choice is an architecture decision about where truth and control should sit, not a convenience setting.

Semantic modeling

The discipline of turning raw data into trusted, named business concepts through views, analytic models, associations, and hierarchies. Done properly it produces a layer where finance, sales, and operations all draw on the same customer and the same revenue, which is the only durable cure for reconciliation arguments. The work is unglamorous and front-loaded, but every downstream capability, from self-service to AI, is only as trustworthy as the semantic model beneath it.

Read terms by job — Planning

Planning is where analytics stops describing the past and starts committing to a future. The terms here matter because planning is the place organizations most often duplicate their semantics by accident, building a parallel universe of numbers that no longer ties back to reporting. The architectural goal is a closed loop where what you plan and what you report rest on the same governed foundation.

Seamless Planning

The capability that stores the fact and master data of an SAC planning model in a Datasphere space, chosen per model, while SAC keeps the model structure, calculations, and planning processes. It needs SAC on SAP HANA Cloud linked 1:1 to a Datasphere tenant and models in the Optimized Design Experience (classic account models can't be deployed), with planning licensed through SAC users and storage and compute through Datasphere capacity. Its significance is architectural rather than cosmetic: plan data lives next to governed actuals in the same layer, which closes the loop between deciding and measuring. It is the difference between a plan that can be reconciled to actuals by design and one that requires a spreadsheet to bridge the gap every cycle.

Input-enabled model

A model whose data users can change, not just read: in SAP terms, an SAC planning model whose input-enabled tables let users enter plan assumptions or actuals that persist in the model (and, with seamless planning, in a Datasphere space). Datasphere's analytic models themselves are consumption objects; the write path for plan values runs through SAC planning. The governance point is that write-back must respect the same access controls and definitions as reads—SAC data access control distinguishes read and write rights per member—or the plan silently becomes a less-trusted dataset than the report it feeds.

Version management

The planning discipline of maintaining parallel states of the data, such as actuals, budget, forecast, and scenarios, that can be compared, copied, and promoted. Good version handling is what lets an organization explore "what if" without contaminating the official numbers, and what lets a forecast graduate cleanly into a baseline. Weak version handling is how a working assumption ends up quoted as fact three meetings later.

Smart Predict

SAC's built-in automated forecasting and statistical modeling, covering time-series, classification, and regression scenarios without leaving the analytics surface. It lowers the barrier to predictive analysis for planners who are not data scientists, embedding forecasts directly where the planning happens. I treat it as a first-class consumption pattern rather than a late-stage add-on, but with the usual caution that an automated forecast is only as sound as the governed history it learns from.

Write-back

The flow that pushes user-entered values from a planning surface back into the underlying model or database, persisting decisions rather than discarding them after a session. Write-back is what distinguishes planning from reporting at a technical level, and it is where security and concurrency questions become real. The architectural test is whether write-back lands on the same governed entities the organization reports on, because that is what keeps plan and actual speaking the same language.

Read terms by job — Governance, lifecycle and trust

This group answers a question that product demos rarely address: how does a definition stay safe after go-live. Governance is not a compliance afterthought; it is the operating system that keeps meaning, lineage, and access coherent as the landscape changes. These terms describe how trust is engineered and, crucially, how it is recovered when it slips.

Data Product

A named, owned, versioned, and documented data asset that bundles semantic meaning with quality expectations, service levels, and access policy. It elevates a useful dataset from informal artifact to governed product with a publisher who is accountable for it, which is what makes reuse safe at enterprise scale. The discipline it imposes — clear ownership, documented contracts, deprecation warnings on breaking change — is exactly what is missing when teams quietly copy each other's models and the definitions drift apart.

Data Product Studio

SAP's announced environment for designing, packaging, and publishing data products in a guided, self-service workflow. SAP announced it at TechEd 2025 with general availability planned for the first half of 2026, but as of November 2026 no GA confirmation could be found, so treat it as announced, not shipped. Today, custom data products in Business Data Cloud are built from local tables in a file space and published through the Data Sharing Cockpit, with data product governance (terms and conditions, steward approval, access agreements) added in September 2026. Its promised value is organizational as much as technical: a visible lifecycle, so consumers can see ownership, quality, and version before they build on something.

Lineage

The traceable record of where a number comes from, following it from source through every transformation and model to the report that finally shows it. Lineage is what lets you answer "where did this figure come from" during an audit and what lets you debug a wrong total by walking the stack instead of guessing. In a governed semantic layer lineage should be column-level and intrinsic, not a document someone maintains by hand and forgets to update.

Stewardship

The assignment of named human ownership to definitions, models, and data products, so that someone is accountable for the meaning of a measure and the consequences of changing it. Stewardship is the unglamorous backbone of trust: tools can record lineage and enforce access, but only a steward decides whether a proposed change to "revenue" is legitimate. Where stewardship is absent, governance degrades into documentation nobody trusts and definitions nobody dares to touch.

Release gate

A deliberate checkpoint in the change lifecycle where a model or definition is reviewed, tested, and approved before it reaches production consumers. A release gate is what keeps a well-meant edit to a shared measure from silently breaking dozens of downstream stories. The point is not bureaucracy for its own sake but proportionate friction: the more consumers depend on an object, the more it deserves a gate.

Trust recovery

The practice of restoring confidence in the numbers after an error, an outage, or a definition change has shaken it. Trust is asymmetric: it accrues slowly through consistent, explainable results and collapses quickly the first time a board sees two different figures for the same thing. Designing for trust recovery means having lineage, version history, and clear communication ready before you need them, because the recovery conversation always happens under time pressure.

Capacity Unit

The consumption-based commercial metric SAP uses to meter Business Data Cloud, replacing per-user or per-item pricing with a pooled measure of platform capacity; SAP's BDC pricing page quotes capacity units on request, in monthly blocks, on contracts of 3 to 36 months. Since January 1, 2026, SAC and SAP Datasphere can no longer be bought with SAP BTP cloud credits for new subscriptions, and SAP's pricing pages license both through BDC capacity units. The shift changes the commercial conversation from "how many stories will we build" to "what total semantic and decision capacity do we need," which is a more honest question to plan against.

Hallucination governance

The set of controls that keep a generative system from presenting confident, fluent answers that are simply wrong, by grounding it in governed data and constraining what it is allowed to assert. In analytics this is non-negotiable, because a plausible but fabricated number is more dangerous than an obvious error: it gets believed. Practical hallucination governance leans on the semantic layer for grounding, on retrieval over invention, and on making the model show its working so a human can catch it.

Read terms by job — Modernization

Modernization is the art of moving forward without losing what already works. Most SAP analytics estates carry years of BW investment, and the honest question is never "rip and replace" but "what do we carry forward, what do we retire, and in what order." These terms describe the landing surfaces and bridges that make a phased path possible.

SAP BW/4HANA

SAP's modern, HANA-optimized data warehouse, the consolidation of the classic BW lineage onto a leaner, in-memory foundation, with SAP committed to the product line until at least the end of 2040. For many organizations it remains the operational core of analytics today, holding decades of modeled logic in InfoProviders, queries, and hierarchies. The modernization question is rarely whether to abandon it overnight but how it coexists with Datasphere during a deliberate, multi-year transition—increasingly via SAP BW, private cloud edition inside Business Data Cloud—where business meaning gradually moves to the newer semantic layer.

BW Bridge

A capability that brings existing BW models, business content, and ABAP-based logic into the Datasphere environment, letting organizations reuse familiar warehouse assets rather than rebuilding from zero. It is still supported in Business Data Cloud, but SAP now calls SAP BW, private cloud edition the strategic route for existing BW systems and positions the bridge for specific cases, such as reusing business content and ECC extractors or decommissioning BW. The bridge has no OLAP engine, so BW queries and analysis authorizations do not run there. I treat it as a bridge in the literal sense: useful for crossing, not a place to settle permanently.

InfoProvider

The umbrella term in BW for objects that provide data for reporting: InfoCubes and MultiProviders in classic BW, and advanced DataStore objects, CompositeProviders, and Open ODS views in BW/4HANA. They encode years of dimensional design and business rules, which is exactly why migration is a semantic exercise and not a file copy. When modernizing, the work is to map each InfoProvider's meaning to a Datasphere analytic model or a data product so the definition survives even as the underlying technology changes.

Coexistence

The deliberate state in which legacy and modern platforms run side by side, each owning the workloads it serves best while responsibility shifts gradually between them. Coexistence is the realistic shape of almost every modernization program, because cutting over a warehouse in one move is rarely safe or affordable. The skill is in drawing clean boundaries — what BW still owns, what Datasphere now owns — so the two do not quietly produce competing versions of the truth during the overlap.

Data Product Generator

The Data Product Generator for SAP Business Data Cloud: tooling that replicates data from BW InfoProviders—InfoObjects, DataStore objects, InfoCubes, MultiProviders, and CompositeProviders—into local tables in the Datasphere object store, from which teams publish custom data products. It requires BW to run as SAP BW, private cloud edition in BDC (BW/4HANA 2023 SP0+ or 2021 SP4+, or BW 7.50 SP24+). It moves data, not models: it does not convert BW queries or models into data products automatically. Its value is throughput: it makes the disciplined approach to reusable assets fast enough that teams actually use it under delivery pressure.

Read terms by job — Integration

Real enterprises have data everywhere, and pretending otherwise is how integration projects fail. The terms here describe how SAP connects to the rest of the estate — other clouds, non-SAP systems, event streams — and where data physically lives. The recurring architectural decision is whether to move data or to query it where it sits, and who owns the connection either way.

SAP Business Data Cloud (BDC)

SAP's unified data platform offering that brings SAC, Datasphere, SAP BW private cloud edition, SAP HANA Cloud with an object store, the partner engines SAP Databricks and SAP Snowflake, SAP Reltio for master data, and BDC Connect into a single commercial and architectural envelope priced in capacity units. It is better understood as a packaging and unification strategy than a brand-new product: it draws the analytics, semantic, and data-foundation layers into one governed whole, and SAP's Business AI Platform now unifies it with SAP BTP and SAP Business AI. The practical effect is that the conversation shifts from buying individual tools to provisioning a platform and adding the data foundation each landscape needs.

BDC Connect

The zero-copy, bidirectional sharing of SAP-managed and custom data products between SAP Business Data Cloud and partner platforms, so consumers use the data in place instead of copying it (SAP allows caching where needed). Databricks reached general availability in October 2025, Snowflake on May 4, 2026, and Google BigQuery in July 2026; Microsoft Fabric was still in public preview in November 2026 with GA planned for the second half of 2026, and Amazon Athena is planned for the first half of 2027. It needs a BDC subscription and a BDC Connect instance in the same region and hyperscaler as the data product, and SAP meters cross-region data transfer and API requests in capacity units. The architectural payoff is that organizations can layer SAP analytics and planning on top of data already sitting in another cloud—and share SAP data out—without re-ingesting it.

Zero-copy

An integration pattern in which a platform reads and reasons over data where it already resides instead of duplicating it into its own store. The appeal is economic and architectural at once: no second copy to store, secure, reconcile, or keep fresh, and no lag between source and analysis. The trade-off is that you depend on the source system's performance and availability, so zero-copy is a deliberate choice about where truth and cost should live, not a free lunch.

Federation

The technique of querying multiple source systems in place and presenting the results as if they came from one, without first consolidating the data physically. Federation keeps storage costs and copy-management down and data fresh, but pushes load onto the sources and is sensitive to their latency. In Datasphere it sits alongside replication as one half of a deliberate persistence decision: federate what must be live and lean, replicate what must be fast and self-contained.

Lakehouse (in Business Data Cloud)

An architecture that keeps data in open table formats on object storage and queries it in place with SQL engines, combining a data lake's flexibility with a warehouse's management. In SAP Business Data Cloud it arrives through the Dremio acquisition, completed in July 2026: native Apache Iceberg support with an Apache Polaris–based catalog integrated with the BDC catalog, plus a distributed SQL engine that can query lakehouse catalogs and relational databases. BDC already supports Delta Lake, and SAP plans general availability of the new lakehouse capabilities for Q1 2027. The architectural question it raises is which catalog is authoritative for which tables.

Data Product as integration contract

Beyond its governance role, a Data Product also functions as the unit of exchange between systems and clouds: a governed, versioned package whose semantic definitions can be shared, including zero-copy, to platforms like Databricks or Snowflake so consumers everywhere see consistent meaning. Treating the data product as an integration contract is what keeps a figure defined in Datasphere identical when it surfaces in another cloud. This is the difference between sharing data and sharing meaning, and only the latter survives contact with multiple consumers.

SAP Business Technology Platform (BTP)

SAP's cloud platform-as-a-service foundation, the runtime on which the analytics and integration services ultimately operate—now presented by SAP as a core part of the SAP Business AI Platform. It provides the application runtimes, AI services, integration components, and extension model that let analytics reach into the wider enterprise rather than stand alone. Understanding BTP is not optional for architects: the analytics platform is a cloud application on a modular foundation, and serious extensions, custom services, and integrations almost always touch BTP services.

Cloud Integration

The integration-flow capability within SAP Integration Suite for moving and transforming data between SAP and non-SAP systems through pre-built and custom flows. It is the modern successor to earlier middleware and the workhorse for connecting source systems into the analytics estate, whether event-driven or scheduled. The correct name is Cloud Integration rather than the older "Cloud Platform Integration," and it is best treated as the integration backbone of the landscape rather than a point tool bolted on late.

SAP Integration Suite

SAP's consolidated set of integration capabilities on SAP BTP, spanning Cloud Integration, API Management, and event-driven messaging; SAP's announced Enterprise AI Gateway (GA planned for Q1 2027) builds on it. It is the layer that connects the analytics platform to the rest of the enterprise, exposing models as APIs and wiring SAP and non-SAP systems together. For any landscape with data outside SAP — which is to say almost all of them — Integration Suite is table stakes rather than an optional accessory.

API Management

The component of Integration Suite that publishes, secures, and governs APIs, letting Datasphere models, SAC content, and planning workflows be called by external applications under managed policy. It turns analytics from a destination people visit into a service other systems can consume programmatically. Good API governance — versioning, rate limits, authentication — is what keeps that openness from becoming an uncontrolled surface.

Event Mesh and Advanced Event Mesh

SAP's event-driven messaging capability for asynchronous, publish-and-subscribe communication across the enterprise, with Advanced Event Mesh extending it to higher-scale, distributed event streaming. It lets models and workflows react to things happening elsewhere — an order posted, a threshold crossed — rather than waiting for the next scheduled batch. Event-driven architecture is what moves analytics from periodic reporting toward responding to the business as it actually unfolds.

OData

A standardized REST-based protocol SAP uses to expose data and models to external clients in a consistent, queryable shape. It is one of the main doors out of the semantic layer, letting Python, JavaScript, or third-party BI tools consume governed models while still honoring their definitions and row-level security. The point of standing on a standard like OData is that you expose meaning once and let many kinds of consumers reach it without bespoke plumbing for each.

Read terms by job — AI and agents

The newest and noisiest layer, and the one where the gap between demonstration and dependable production is widest. The terms here describe SAP's AI front door, the models behind it, and the emerging agent layer that does not just answer but acts. The question to keep asking is what the system is allowed to do, on what grounded data, and how you would catch it when it is confidently wrong.

SAP Business AI Platform

SAP's unified platform for enterprise AI, announced at SAP Sapphire in May 2026, which brings SAP BTP, SAP Business Data Cloud, and SAP Business AI together with SAP Knowledge Graph at its core. SAP describes three pillars—build (Joule Studio); contextualize and reason (the Knowledge Graph and Business Data Cloud); and govern (SAP AI Agent Hub, with SAP Enterprise AI Gateway planned for Q1 2027)—and SAP Learning now presents SAP BTP's capabilities as part of it. For analytics teams the useful reading is that the platform's context layer is built on exactly the governed models and data products they already own.

Joule

SAP's generative-AI copilot and natural-language front door across SAP Business AI, available in analytics contexts including SAP Analytics Cloud and SAP Datasphere; Joule Work, rolling out in phases since October 2026, extends it into one experience across SAP and non-SAP applications. In SAC, analytical insights in Joule run on just ask, SAC's natural-language query feature, which still exists alongside it—one capability family rather than separate products. Architecturally, Joule's usefulness depends entirely on the governed semantics beneath it: a copilot grounded in a strong semantic layer is helpful, while one grounded in fragmented definitions simply produces fluent inconsistency faster.

Joule Studio

The environment for designing, configuring, and extending Joule's skills and agents, part of the SAP Business AI Platform: its skill builder has been generally available since July 2025 and its agent builder since December 2025, with low-code and pro-code paths. It is where enterprise-specific grounding, actions, and guardrails are defined, and SAP now certifies the skill (Joule Studio Developer, C_JSD). The governance instinct applies directly: the more an organization teaches Joule to act, the more deliberately it must define the boundaries of that action.

Joule Agent

An agentic extension of Joule that can carry out multi-step tasks and take actions toward a goal rather than only answering a question. Agents are where AI crosses from describing the business to changing it, which raises the stakes on grounding, authorization, and auditability considerably. SAP's Autonomous Suite alone counts more than 50 Joule Assistants orchestrating more than 200 specialized agents (May 2026), but the architectural discipline is unchanged: an agent should act only on governed data, within explicit permissions, and leave a trail you can inspect afterward.

Joule skill

A discrete capability that Joule can invoke to perform a specific task or answer a specific class of question, composed together to handle richer requests. SAP's library passed 2,500 skills across its applications in Q1 2026, which signals breadth but is not the point on its own. What matters for an analytics architect is which skills are grounded in your governed models, because an ungrounded skill is just a confident guess with good production values.

SAP-RPT-1

SAP's relational pretrained transformer, the first of SAP's tabular foundation models: it uses in-context learning to make predictions on structured enterprise data without bespoke per-task training. SAP positioned it as dramatically more efficient than general large language models for tabular prediction—in its own framing, around 50,000 times less energy, 100,000 fewer GPU FLOPs, up to 3.5 times better predictions than LLMs, and 50 times more speed. SAP-RPT-1 retires by December 31, 2026, in favor of its successors (next entry). The significance is conceptual: it treats tables, the native shape of enterprise data, as a first-class input rather than forcing everything through text.

SAP-RPT-1.5, 1.6, and RPT-2

The successors to SAP-RPT-1. Tabular orchestration became a managed workflow on the generative AI hub in September 2026, launched with SAP-RPT-1.5; SAP-RPT-1.6, with a -large variant and a deep context mode for more than 8,000 rows, is generally available in the SAP AI Core model library; SAP-RPT-TS handles time-indexed metrics in SAP IBP; and SAP-RPT-2 (anomaly and outlier detection, embeddings, multi-table input) is planned for general availability in Q1 2027. The direction is the same throughout: efficient, grounded prediction oriented around structured data rather than free text.

SAP AI Agent Hub

SAP's registry and governance hub for AI agents, built on SAP LeanIX and generally available since May 2026: it discovers and inventories SAP and non-SAP agents, MCP servers, and large language models in one place, and an AI Governance Assistant that drafts EU AI Act risk classifications for legal review is planned for general availability in Q4 2026. It matters to analytics leaders because every agent that touches governed data should be registered, owned, and auditable before it reaches production.

Generative AI Hub

The capability within SAP's AI foundation on BTP that provides governed access to a range of foundation models—from OpenAI, Anthropic, Google, Mistral AI, Amazon, Meta, Cohere, Perplexity, and SAP itself—behind a consistent, enterprise-controlled interface, with orchestration for grounding, templating, content filtering, and data masking. It is what lets an organization use large models without surrendering control over data handling, model choice, or compliance; SAP states that customer data is not used to train or improve the models. In May 2026 SAP announced plans to make Anthropic's Claude a primary reasoning and agentic capability across its AI portfolio, powered by Joule, while keeping its open multi-model approach; for sovereignty requirements, SAP's EU AI Cloud runs models such as Cohere and Mistral AI on SAP infrastructure in Europe.

Knowledge Graph

A representation of enterprise data as entities and the relationships between them, giving AI a structured map of how business concepts actually connect rather than a flat pile of records. For grounded, explainable AI this is powerful, because relationships are exactly what a model needs to reason correctly about a question like "which customers in this region declined." A knowledge graph turns the semantic layer's careful relationship modeling into something an AI can traverse, which is why the two reinforce each other—and why SAP puts SAP Knowledge Graph at the core of the SAP Business AI Platform. At SAP TechEd 2026, SAP said the graph will add customer-specific context from SAP-managed and customer-managed data products (planned for Q1 2027) and announced SAP Business Data Cloud Ontology Manager, with a beta planned for November 2026, to curate domain-specific views of the graph for individual agents.

Intelligent Content (formerly Intelligent Applications)

SAP's prebuilt content for Business Data Cloud, organized by line of business: prebuilt reporting and analytics, AI and machine learning, My Metrics KPIs, and semantic and planning models built on certified data products, in packages such as Finance, Supply Chain, People, Spend, and Revenue Intelligence and Cloud ERP Intelligence Private. SAP launched these as "intelligent applications" in 2025 and now calls them intelligent content. They are how SAP intends to deliver pre-built value on top of the data platform; the architecture caution is to understand what each package assumes about your data foundation, because prebuilt content still depends on governed, well-modeled data underneath to behave as advertised.

Insight App

SAP's name for some individual intelligent-content packages in Business Data Cloud—for example, the People Intelligence Insight application announced in 2025—that turn curated data products into a directed analytical experience for one domain or decision rather than a blank canvas. They are useful precisely because someone has already made the modeling and curation decisions, which is also the reason to check that those decisions match how your organization defines its terms.

Master Data Governance and Reltio

The discipline and tooling for keeping core master data — customers, products, suppliers — consistent, deduplicated, and trustworthy across systems, which is foundational to any reliable analytics. SAP completed its acquisition of Reltio on May 7, 2026, and SAP Reltio in SAP Business Data Cloud is now generally available, bringing cloud-native master-data management into BDC as a core capability. The reason this belongs in an analytics glossary is simple: conformed dimensions and trustworthy AI both collapse if the master data underneath them is fragmented, so master-data governance is upstream of every clever thing built on top.

Agentic analytics

The emerging mode in which AI does not merely surface insight but takes steps toward a goal — investigating, deciding, and acting across multiple stages. It is the destination implied by copilots and agents, and it raises governance from "is the answer correct" to "was the action authorized, grounded, and reversible." I treat agentic analytics as a serious design problem rather than a feature: the more autonomy you grant, the more your semantic layer, access controls, and audit trail have to carry the weight.

Grounding

The practice of tying an AI system's responses to specific, governed source data so that what it says is anchored in reality rather than generated from pattern alone. Grounding is the single most important defense against hallucination in analytics, and it is where the semantic layer earns its keep a second time: governed models and a knowledge graph are exactly the trustworthy substrate a model should be grounded in. An ungrounded analytics AI is a confident narrator with no obligation to the facts, which is precisely the wrong thing to put in front of a decision-maker.