A high-priority sales order lands at twenty to nine on a Tuesday. One line, confirmed for the fourteenth. The VIP customer was told the tenth.
Four people will look at that order this morning and none of them wants the same thing from it. The rep is on the phone in twenty minutes and needs to know what can be done to improve the date. The planner needs to know what else moves to make the tenth. The finance manager needs to know whether the exception the rep is asking for is permitted, and who signs it. The operations director needs to know what this does to this week’s fill rate, and why this customer keeps coming up.
Ask any of those questions of an AI assistant sitting inside your SAP system and you will get an answer. What is not obvious from the answer is where the knowledge behind it came from.
Those answers will not all come from the same place. Some of what the assistant knows arrives with SAP. Some of it you supply. And some of it you can decide to own outright. Most estates end up with more than one, which is why it is worth knowing what each one commits you to.
SAP’s semantics — the Knowledge Graph
SAP’s framing at Sapphire was three layers: public models, SAP’s context, and the customer’s context.[1] The middle layer is where the investment is going, and the Knowledge Graph sits at the centre of it.
SAP describes it as an SAP-managed semantic layer.[2] What it contributes is the connective tissue — what a sales order is, how a schedule line relates to a delivery, which documents depend on which. An agent working from it can traverse from the rep’s order toward the planner’s question without being handed the model each time it is asked. That is the difference between an assistant that can quote a field and one that can follow a relationship.
Two things are worth separating before you plan around it.
The first is that a semantic layer describes. It does not enforce. When an agent goes on to post something, it goes through the same API the rest of your estate uses, and that is where availability checks, credit checks and incompleteness rules run — exactly as they did when a batch input session called a transaction. The graph makes an agent legible to your data. The write path is what keeps it safe.
The second is that knowing what a sales order means is not the same as retrieving yours. Meaning comes from the graph. Your actual orders, customers and configuration come through supported, authorised access to application data or data products. Nothing has to be copied into the graph for an agent to answer the rep’s question, and the two questions — does it understand this, and can it reach this — have different answers and different owners.
Which makes coverage the thing to establish rather than assume. SAP’s own material puts the S/4HANA graph at 452,000 ABAP tables, 80,000 CDS views and 7.3 million fields, drawn from its metadata model.[3] That is a substantial delivered foundation. What it does not tell you is how much of your implementation is represented in it.
There is a documented case that shows the gap cleanly, on the data side rather than the graph side: custom fields can arrive in SAP-managed data products while SAP’s delivered analytical models ignore them until you model their use.[4] Availability is not understanding. Transporting a field is not explaining what you meant by it.
SAP’s architecture guidance is candid about direction here. It names custom fields, custom APIs and tenant-specific configurations, and states that the long-term vision is a customer-specific knowledge graph with a shared enterprise ontology.[5] Long-term vision is architectural direction, not a delivery date.
So go and establish it rather than inferring it. Does the graph cover the field you repurposed in 2019? The custom object your team built? The second CRM you inherited in an acquisition and never retired, or the three EDI packages doing the same job in three regions, or the process you have not been able to standardise yet because one plant needed it that way? Some of those are roadmap questions. Some of them were never SAP’s to describe, and no delivered semantic layer is going to arrive knowing them.
Then the correction question. The delivered graph is SAP’s to change, not yours. That does not mean your only option is to build something outside — SAP documents customer-managed data products, custom semantics and access controls within the SAP-managed platform.[6]
So there are three things to establish for your own estate, not two. What the graph already covers. What you can extend yourself. And what it is never going to describe, which you will have to account for somewhere else.
Your documents — grounding
The least glamorous of the four and the most clearly shipping.
You point it at your policy documents. It retrieves from them. It answers the finance manager’s question, and on the documented enterprise plan for Joule document grounding it is metered on records.[7]
The correction path here is the one most people describe wrongly. It is not edit the document and the answer is fixed. An edit has to reach the retrieval system — ingestion runs on a schedule or is triggered manually — and then the answer has to be re-tested, because a wrong answer can come from selecting or interpreting the wrong material even when every document is correct.[8] Content accuracy and answer accuracy are two different responsibilities, and only the first one lives in the file you just edited.
What is also true is that part of your content estate becomes a production input. Only the selected content that has successfully indexed, and only what is reachable under the configured retrieval and access rules. That selection is a decision somebody made, and in most organisations it is not written down anywhere as a decision. The retrieval works. What it retrieves is whatever that selection contains.
Your operating knowledge — Company Memory
This is the interesting one.
Built on the Signavio foundation, it ingests from sources your organisation already has — policy documents, process models, agent traces, voice input — and structures what it finds into process atoms, each with a stated purpose, scope and guiding principles, with no manual transcription required.[9] It aims directly at the director’s question, the one about why this customer keeps coming up, and it addresses the actual reason enterprise agents disappoint: the operating logic of a company is distributed across material nobody has ever consolidated.
It also has the most explicit governance design of the four. SAP states that business owners curate and approve every behaviour in their domain, with a full audit trail for every change, that contradictions are surfaced before an agent acts on conflicting rules, and that a behaviour updated once reaches every connected agent at the next execution without redeployment.
Two things about that.
First, it is the most specific published answer to who can change this among the four — and it assigns that answer to your business owners rather than to SAP. Second, the page carries a label: the solution is in closed beta. What the page establishes is a governance design and an advertised status, not evidence of how that design performs in production. Forrester’s note in May recorded no public production references at announcement;[10] treat that as a dated snapshot rather than a current finding, and ask SAP directly where it stands now.
There is an implementation question underneath the governance design that is worth thinking through early. If your policy estate looks like most — a 2019 credit policy and a 2023 one, a regional procedure that contradicts the global standard because the region has a carve-out that lives in somebody’s head — then surfacing contradictions is going to produce a queue of decisions your organisation has managed to avoid making for two decades. Those decisions route to business owners who have day jobs. The constraint may not be getting the knowledge in. It may be adjudicating what comes out.
And the shape is worth naming plainly. The raw material is yours, and your people curate and approve what it comes to mean. But SAP supplies the structuring approach — what counts as a unit of operating knowledge, and where one ends and the next begins. Your business owners are approving behaviours expressed in units whose boundaries somebody else drew.
Your own context service
The first three are things SAP supplies. The fourth is not a capability at all — it is a decision about architecture, which is why it does not sit comfortably beside the others. You maintain your own retrieval and reasoning service and connect it to the assistant, rather than handing the knowledge over for the platform to hold.
Be careful about the reason. Reach is not it. SAP states that Company Memory delivers through MCP at runtime, CLI at build time and chat for business users, to Joule and to any agentic framework — so cross-interface delivery is something the platform is claiming, through the same protocol you would use.
What stays yours is narrower and more durable: authorship, and scope. You decide what counts as a unit of company knowledge rather than inheriting that decision. And you decide what goes in — including the material that no delivered structuring was designed to look at, which for most estates is where a meaningful amount of the operating logic actually lives.
A shared service will not guarantee identical answers. Instructions, permissions and history still differ from one assistant to the next. What it does mean is that disagreements are about interpretation of a shared source, rather than about which source was consulted.
What you pay is operating responsibility, and the bill is specific: keeping the corpus current, enforcing access at retrieval and keeping any inherited source permissions accurate, evaluating answer quality on an ongoing basis, and running an integration the assistant now waits on. None of it is exotic. All of it continues every month after go-live, and it is easy to underweight at pilot stage, when there is one corpus, one use case, and someone who cares about it personally.
The capability decides what your AI can know. The choice decides who keeps it true.
The choice you have already made
Put the four side by side and a distinction surfaces that most intake processes have no name for.
Approving a source document and approving an agent’s behaviour are two different signatures.
Your document libraries may well already have content approval. That is a mature control and plenty of organisations run it properly. What it establishes is that a version of a file was fit to publish. Company Memory’s published design establishes something else — that a business owner approved what the agent will do, as a structured statement of behaviour rather than as a document.
Most people will assume the first covers the second. It does not, and the gap between them rarely has an owner.
There is an open question underneath that worth taking to your own estate rather than assuming: when a grounding connector ingests from a library, does it respect that library’s approval state, or does it take what is there? Ask your integrator. Do not infer it.
All of which is what makes this foundational rather than a feature selection. Whichever combination you end up with, the knowledge does not stay true on its own. Policies change, processes drift, exceptions become norms and nobody writes it down. Someone has to keep each of these current, and those someones are different people with different authority on different clocks.
That obligation is the thing you are actually buying, and it rarely appears as a line item in the case that got the pilot approved. It also gets settled early — usually inside a pilot, by whoever sits closest to the first use case, on the grounds of what could be demonstrated fastest.
So look at your own intake. Somewhere between the team wants an assistant and we approved the pilot there should be a step where someone asks where the knowledge will live, who maintains it, and who can change it when it is wrong. If that step is not there, the question has already been answered by default.
It is worth finding out what you answered.
SAP Sapphire 2026 — three-layer framing (public models / SAP context / customer-specific context). SECONDARY as captured. Only unchased source in the piece; see open items at publication.↩︎
SAP Business AI Platform product page — “SAP-managed semantic layer” phrasing. SAP primary.↩︎
SAP Learning, “Exploring SAP Knowledge Graph” — S/4HANA knowledge graph based on 452,000 ABAP tables, 80,000 CDS views, 7.3 million fields. SAP primary. Establishes the scale of the delivered foundation; does NOT establish identical coverage across customers, and must not be used to claim that.↩︎
SAP Learning, Business Data Cloud, “Describing data products” — custom fields arrive in SAP-managed data products while delivered analytical models ignore them until customers model their use. SAP primary. SCOPE: this is a BDC data-product and analytical-model boundary. It illustrates availability versus semantic use. It does NOT establish what the Knowledge Graph understands about any particular custom field. Keep the qualification on any reuse.↩︎
SAP Architecture Center, AI-Native North Star Architecture, Foundation Layer — names custom fields, custom APIs and tenant-specific configurations; states the long-term vision as a customer-specific knowledge graph with a shared enterprise ontology. SAP primary. Establishes architectural direction, NOT a delivery date or a capability available today.↩︎
SAP Learning, Business Data Cloud — customer-managed data products, custom semantics and access controls within the SAP-managed platform. SAP primary. Establishes a verified capability; does NOT establish an unrestricted customer-editable Knowledge Graph.↩︎
SAP Help Portal — Joule document grounding, records-based metering. SCOPE: documented enterprise data-manager service plan. Records are defined in document-size blocks, not database rows. Not a universal SAP grounding meter and not SAP AI Core grounding. SAP primary.↩︎
SAP Help Portal — grounding content ingestion, scheduled and manually triggered. SAP primary.↩︎
SAP Company Memory preview page (signavio.com/company-memory, page modified 2026-08-17) — Capture / Govern / Deliver; process atoms with purpose, scope and guiding principles; “no manual transcription required”; business-owner curation and approval with full audit trail; contradiction surfacing; propagation at next execution without redeployment; MCP at runtime, CLI at build time, chat for business users, to Joule and any agentic framework; “Solution in closed beta”. SAP-owned primary, fetched and read directly 2026-09-16.↩︎
Forrester, SAP Sapphire 2026 analysis, May 2026 — no public production references for Company Memory at announcement. Snapshot, not current status. Date carried in body.↩︎