A credit risk agent gets asked one question and has to cross four systems to answer it: the loan data sits in Snowflake, the policy exceptions live in Confluence, the contract terms are in Salesforce, and the definition of “risk tier” is buried inside a Tableau dashboard. None of the four can answer alone. Enterprise firms average 473 SaaS applications distributed across systems of record, data, and knowledge, the three categories of organizational truth in the enterprise stack: operational facts, analytical truth, and institutional memory. Atlan’s context layer sits above all four system types, ingesting entity relationships from systems of record, lineage and quality signals from systems of data, policy and decision context from systems of knowledge, and metric definitions from systems of semantics, into one governed, queryable vocabulary an agent retrieves at inference time, the same context portability requirement that keeps it consistent whichever system it queries.
| System type | What it stores | Examples | What it tells AI |
|---|---|---|---|
| Systems of record | Authoritative operational facts | Salesforce, SAP, Workday, ServiceNow | Who your customers are and what has happened |
| Systems of data | Analytical truth at scale | Snowflake, Databricks, BigQuery | What the numbers say |
| Systems of knowledge | Institutional memory and policy | Confluence, Notion, Slack, SharePoint | How and why decisions get made |
| Systems of semantics | Business definitions and metrics | Tableau, PowerBI, dbt, Looker | What the numbers mean |
Where does this taxonomy come from?
Permalink to “Where does this taxonomy come from?”The taxonomy builds on established enterprise architecture frameworks, including the “systems of record, systems of engagement, systems of insight” lineage Forrester formalized in 2015, building on Geoffrey Moore’s earlier systems-of-record-vs-engagement distinction, and extends them to reflect the AI-specific requirements of the modern stack. “Systems of knowledge” as a distinct category formalizes what earlier frameworks treated as edge cases: the unstructured institutional memory that makes structured data interpretable.
The data stack is shifting under AI
See the 7 shifts reshaping data infrastructure for an AI-first world, including why cross-system context is now the bottleneck.
Download the 2026 ReportWhat are systems of record?
Permalink to “What are systems of record?”Systems of record are the authoritative sources of operational truth. When there’s a dispute about what a contract says, the CRM is the system of record; when there’s a question about an employee’s role, the HRIS is. The key properties: transactional, authoritative, and operational, used to run the business, not analyze it. Enterprise firms with over 10,000 employees average 473 SaaS applications, and the majority are systems of record or connected to them. Common examples: Salesforce (CRM), SAP and Oracle (ERP), Workday (HRIS), ServiceNow (ITSM), and Veeva (life sciences CRM).
What are systems of data?
Permalink to “What are systems of data?”Systems of data are the analytical layer of the enterprise stack. They ingest data from systems of record, transform it through ETL and ELT pipelines, and store it in formats optimized for analysis at scale. Common examples include Snowflake, Databricks, Google BigQuery, Amazon Redshift, and Microsoft Fabric, the modern data stack center where data from dozens of systems of record gets unified and made available to data teams and AI systems.
What are systems of knowledge?
Permalink to “What are systems of knowledge?”Systems of knowledge are where institutional memory lives: the editorial policy on what content is appropriate for the homepage, the finance team’s rule for calculating ARR, the legal team’s guidance on which customer data can be used for which purposes. This knowledge is rarely structured; it lives in Confluence pages, Notion databases, Slack threads, and the heads of subject matter experts, making it the hardest category of enterprise knowledge to capture and govern. According to BetterCloud, 75% of IT teams report they lack a clear view of what SaaS applications are being used across their organizations, a direct consequence of how systems of knowledge proliferate without a unified governance layer.
What are systems of semantics?
Permalink to “What are systems of semantics?”Systems of semantics bridge systems of data and systems of knowledge: the metric definitions in a BI tool, the semantic layer that maps business terms to database columns, the dbt metrics layer that codifies how “revenue” is calculated from raw transaction data. A Tableau dashboard showing “Monthly Recurring Revenue” encodes the calculation logic, data sources, and business rules that produce that number, and for AI agents, that encoded logic is as valuable as the underlying data itself. Common examples: Tableau, PowerBI, Looker, dbt Metrics, and business glossary tools.
How do the three system types differ?
Permalink to “How do the three system types differ?”The distinction is organizational, not primarily technical: each system type stores a different kind of authority and serves a different purpose.
Systems of record hold operational authority: when the CRM says a contract’s end date is March 15, that’s the fact the business acts on. Systems of data hold analytical authority: when the warehouse says average deal size was $87,000 last quarter, that’s the number the business plans against, the same decision trace discipline that lets you prove which system produced which number later. Systems of knowledge hold interpretive authority: when the finance team’s Confluence page says “ARR excludes one-time professional services revenue,” that’s the rule that governs how revenue is calculated.
Each type carries a gap the other two must fill. Systems of record are authoritative but not interpretive: a CRM record shows a customer’s status is “Active” with no guidance on what “Active” means or how that definition differs from the risk team’s. Without context-aware AI agents that can resolve these conflicts, every system-of-record query carries ambiguity, the same data quality gap that produces confidently wrong answers downstream. Systems of data are analytical but not contextual: a warehouse can tell you average transaction value dropped 12% last month with no guidance on why. Systems of knowledge are contextual but not structured: a Confluence page may explain the drop, but in paragraph form, unqueryable, and invisible to an agent querying the warehouse, the same unstructured data problem that keeps institutional memory locked away from retrieval.
Why do AI agents need context from all three?
Permalink to “Why do AI agents need context from all three?”Enterprise AI agents are the first data consumers that can’t operate within a single system boundary. A streaming platform’s content agent asked to “identify the top 10 political shows to feature on the homepage this week” needs five distinct types of organizational context to answer correctly: viewing data from systems of data, editorial policy from systems of knowledge, the definitions of “Top 10” and “political” from systems of semantics, the asker’s role-specific logic from systems of record, and active experiments overriding the standard ranking from systems of knowledge.
Strip any one system type and the answer is wrong. Access to only systems of data produces a list ranked by the wrong metric. Only systems of knowledge produces editorial guidance without the viewing data. Only systems of record produces user-profile information with no analytical context, the same memory layer gap that shows up whenever an agent’s working context is missing a piece it needs.
Where's your cross-system context gap?
Run the Context Gap Calculator to see which of your four system types your agents still can't reach.
Calculate Your GapWhat is the fifth context type that none of the systems provide?
Permalink to “What is the fifth context type that none of the systems provide?”Even with access to all four system types, an agent is missing one essential layer: the governed, cross-system semantic layer that tells it which definitions are canonical when multiple systems carry competing versions. The CRM defines “active customer” one way, the warehouse carries a different version optimized for analytical cohorts, and the business glossary may define a third. The agent querying all three simultaneously has no organizational authority to determine which one governs, the organizational cold start problem expressed at the cross-system level.
This fifth context type, organizational context memory, is the governed, versioned, cross-system vocabulary that resolves definitional conflicts and makes the agent’s reasoning consistent across every query, the reason agents need a shared enterprise context layer rather than four independent connections. It’s what Atlan’s enterprise context layer provides above the four system categories.
What is the enterprise context layer and how does it unify the stack?
Permalink to “What is the enterprise context layer and how does it unify the stack?”The enterprise context layer sits above systems of record, data, knowledge, and semantics and serves unified, machine-readable organizational context to AI agents at inference time, resolving cross-system fragmentation before inference begins rather than after a wrong answer surfaces.
It ingests different signals from each category: entity relationships and ownership data from systems of record; lineage records, usage patterns, and quality signals from systems of data; policy documents and decision records from systems of knowledge; metric definitions and calculation logic from systems of semantics. The result is a unified data graph that links entities, definitions, lineage, and policies across all four system types in a queryable, versioned form, the same knowledge graph structure agents traverse to resolve any cross-system query.
A data architect reviewing a metric definition can navigate from the BI tool to the data dictionary to the Confluence page to the source table in the time it takes to answer a Slack message. An AI agent, working within a much tighter latency budget, has milliseconds. Cross-system context requiring sequential API calls to four platforms is too slow for practical inference, so the enterprise context layer pre-aggregates it into a unified semantic layer exposed via API and MCP server: one call retrieves the canonical definition, the lineage trace, the applicable policy, and the access authorization before constructing any query.
Real stories from real customers: unifying cross-system context for AI
Permalink to “Real stories from real customers: unifying cross-system context for AI”"Critical context had to be added manually, slowing down the availability and the usage of data products. With Atlan, we cataloged over 18 million data assets and 1,300+ glossary terms in our first year, so teams can trust and reuse context across the exchange."
Kiran Panja, Managing Director, Cloud and Data Engineering, CME Group
"Atlan is much more than a catalog of catalogs. It's more of a context operating system. Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
Sridher Arumugham, Chief Data and Analytics Officer, DigiKey
CME Group’s data estate spans multiple system types, and the challenge was making context from all of them available without requiring manual retrieval from each source; Atlan’s enterprise memory layer provided the automation that resolved it. DigiKey’s architecture requirement was a platform that could unify metadata across all system types and make it active: discoverable for analysts, governable for data teams, and queryable for AI agents through a single interface, the same talk-to-data pattern any cross-system agent depends on.
What's the ROI of a unified context layer?
Run the Context Layer ROI Calculator to size the cost of agents guessing across fragmented systems.
Calculate the ROIWhy fragmentation across system types is the root cause of AI context failure
Permalink to “Why fragmentation across system types is the root cause of AI context failure”The enterprise data stack was built for human consumers: systems of record for operational teams, systems of data for analytical teams, systems of knowledge for knowledge workers, systems of semantics for BI developers. None optimizes for an AI agent that needs cross-system context at inference speed.
The consequence is the context gap: the space between what any single system knows and what an agent needs to answer correctly. According to Gartner, poor data quality costs organizations an average of $12.9 million annually, and a significant portion of that cost is context fragmentation across system types: metrics calculated differently in different tools, definitions that conflict between systems of record and semantics, institutional knowledge that never reaches the analytical layer, the same gap that makes agent and human data discovery such different exercises across a fragmented stack.
Consolidating 473 SaaS applications into a single system type is structurally impossible; the systems exist for valid reasons. What organizations can do is build a context layer above all four that aggregates their output into a unified, governed vocabulary AI agents can query reliably, the same discipline behind how to implement an enterprise context layer applied once instead of once per agent. The credit risk agent that resolves “risk tier,” “active customer,” and “credit exposure” to the same canonical definitions whether it queries Salesforce, Snowflake, or a Confluence policy page is the production-ready version of that architecture, and the advantage accelerates as models improve: a stronger reasoning model operating on inconsistent cross-system context produces more convincing wrong answers than a weaker one. Governing the context layer is what converts model capability into reliable cross-system accuracy.
FAQs about systems of record, data, and knowledge
Permalink to “FAQs about systems of record, data, and knowledge”1. What is a system of record in enterprise data?
Permalink to “1. What is a system of record in enterprise data?”A system of record is the authoritative source of operational truth for a specific category of business facts. When there’s a conflict about contract terms, the CRM is the system of record; when there’s a question about an employee’s role, the HRIS is. Systems of record are transactional and authoritative.
2. What is a system of data in enterprise architecture?
Permalink to “2. What is a system of data in enterprise architecture?”A system of data is the analytical layer of the enterprise stack. It ingests data from systems of record, transforms it through ETL and ELT pipelines, and stores it in formats optimized for analysis at scale. Common examples include Snowflake, Databricks, BigQuery, and Amazon Redshift.
3. What is a system of knowledge and how does it differ from a system of record?
Permalink to “3. What is a system of knowledge and how does it differ from a system of record?”A system of knowledge stores institutional memory and business logic: policies, decisions, and contextual rules that make data interpretable. Systems of record store operational facts; systems of knowledge store interpretive context. Common examples include Confluence, Notion, SharePoint, and Slack.
4. Why do AI agents fail when they only access one system type?
Permalink to “4. Why do AI agents fail when they only access one system type?”Each system type holds a different category of organizational truth, and a complete answer to most business questions requires all three simultaneously. An agent accessing only systems of data retrieves numbers with no interpretive context; one accessing only systems of knowledge has context but no analytical grounding.
5. What is a system of semantics and how does it relate to the other three?
Permalink to “5. What is a system of semantics and how does it relate to the other three?”A system of semantics bridges systems of data and systems of knowledge by encoding business definitions in machine-readable form: metric definitions in BI tools and calculation logic producing specific numbers from raw data. Examples include Tableau, PowerBI, Looker, and dbt Metrics.
