AWS Ontology: An Introduction to Context Ontology Accelerator
What you’ll learn
- How ontology, schema, knowledge graphs, and RAG play different roles
- How Context Ontology Accelerator works through its Scan, Model, and Serve stages
- How to evaluate a business question, approval process, access control, cost, and maintenance before adoption
Ontology connects business data through shared meaning
A sales system may use Account while a core system uses Customer. Even when both names refer to the same customer, AI cannot always determine that correspondence from the names alone.
An ontology—a definition of business concepts such as customers and contracts, together with their relationships and rules— organizes these differences. Defining that Account and Customer both represent a customer, and that a customer holds a contract, gives data a consistent meaning across systems.
AWS’s Context Ontology Accelerator is a public implementation that finds candidate meanings and relationships in existing data, then makes human-reviewed knowledge available to AI.
This article distinguishes it from RAG, a process that retrieves relevant information and gives it to AI as material for an answer. It then considers which business problems justify adding ontology and which approval, access, and maintenance arrangements adoption requires.
Context Ontology Accelerator and AWS Context have different delivery models
Context Ontology Accelerator and AWS Context use different delivery models. As of September 21, 2026, the former is a public implementation that an organization installs and operates, while AWS describes the latter as a forthcoming service.
Context Ontology Accelerator: a self-managed public implementation
AWS released Context Ontology Accelerator as open-source software on July 31, 2026, under the Apache License 2.0. AWS describes an ontology as a machine-readable enterprise model of products, customers, policies, and operating rules.[1]
The Accelerator connects to structured data, such as tables with defined fields and formats, and unstructured data, such as documents whose format varies. AI uses those sources to propose the meanings of terms and relationships among data.
People familiar with the business review, edit, and approve those proposals. The approved content is stored in a form whose relationships can be traversed and made available to AI. The public release expresses the ontology through standards supported by multiple products and can supply information through MCP, a common protocol that connects AI to external tools and data.[1]
The initial release primarily uses three AWS services.[1]
| AWS service | Main role |
|---|---|
| Amazon Neptune | Stores entities such as customers and contracts and the relationships between them |
| Amazon OpenSearch Serverless | Finds information whose meaning is similar to a question |
| Amazon Bedrock | Supports AI-generated meaning and relationship candidates and retrieval |
The organization deploys the Accelerator in its own AWS account. The adopter designs and operates its data connections, access controls, AI model configuration, monitoring, and cost management.
AWS Context: a planned AWS-managed service
AWS announced AWS Context in June 2026 as a forthcoming service. It is intended to map relationships in existing data into a knowledge graph—a record that makes relationships between entities traversable—and provide them to AI agents, which retrieve information or use tools to pursue a goal. That information includes data relationships, business rules, and domain knowledge, meaning knowledge specific to a business function or industry.[2]
The July 31 announcement says that the Accelerator’s user-defined ontology capability is planned to become a native feature of AWS Context. AWS plans to operate it as a managed capability and allow ontologies created with the Accelerator to be used and managed in AWS Context.[1]
| Category | Position as of September 21, 2026 | Adopter responsibilities and checks |
|---|---|---|
| Context Ontology Accelerator | An open-source implementation installed by the adopter | Installation in AWS, updates, monitoring, cost management, and maintenance of business terms and relationships |
| AWS Context | A forthcoming AWS-managed service | Confirm the formal scope, pricing, and migration conditions |
Ontology, schema, knowledge graphs, and RAG have different roles
These terms refer to different responsibilities: storing data, defining its structure, defining its meaning, recording relationships, and retrieving information.
| Element | Role | Example |
|---|---|---|
| Database | Stores actual data | Customer and contract tables |
| Schema (a definition of data structure) | Defines tables, fields, and data types | Treat account_id as text |
| Ontology | Defines business concepts and their meanings, relationships, constraints, and rules | A customer holds a contract |
| Knowledge graph | Records actual entities and relationships under those definitions | Company A holds Contract 123 |
| RAG | Retrieves information relevant to a question and gives it to AI as answer material | Retrieve policy documents before answering |
For example, an ontology can define that a customer may hold a contract, while a knowledge graph records the fact that Company A holds Contract 123. The former defines a relationship; the latter records a specific fact under that definition.
The Account and Customer labels from the opening can likewise map to a shared customer concept, allowing system-specific names to carry the same meaning.
This design also needs approval states. A relationship proposed by AI should not have the same level of trust as one the organization has reviewed and approved.
The three Scan, Model, and Serve stages
The official repository explains the Accelerator as a three-stage Scan, Model, and Serve workflow.[4]
Scan: inspect existing data and extract relationship candidates
Scan examines the structure of connected data, enriches it with metadata—information such as names and descriptions that explains the data—and imports documents whose format varies.
An AWS technical article describes both designing an overall model first and using a bottom-up approach that finds relationship candidates in existing data structures and values.[3]
The bottom-up approach starts from data that actually exists. Similar column names or values, however, do not necessarily represent the same business concept. Automated extraction produces candidates for human review, not a finished model.
Model: define and approve meanings, relationships, and rules
During Model, AI proposes business entities, equivalent terms, relationships, and measurements for people familiar with the business to review. In the public release, this stage covers creating and managing candidates, defining measurements, and building a graph that connects multiple data sources by meaning.[4]
Operations must track not only the output quality of an LLM—a large language model that understands and generates text—but also who approved what.
Recording the owner, source data, confidence, approval state, and deprecation state for each concept makes an incorrect relationship easier to correct later.
Serve: retrieve and provide information needed for a question
Serve searches across relationship data and supplies information needed for a question to AI through MCP.[4] A system can find an entity whose meaning is similar to a question and then follow recorded relationships from that starting point.
The supplied context can be limited to relevant concepts, relationships, rules, and evidence. This makes the path used to produce an answer easier to record.
How conventional RAG differs and when to use each approach
Conventional vector RAG, which represents text numerically and searches by semantic similarity, is suited to finding passages related to a question. Ontology and graph retrieval are suited to traversing relationships and rules among customers, contracts, products, and other entities.
AWS distinguishes vector search as the discovery of semantically similar information and graph search as the exploration of connected information. The two can be combined. GraphRAG—RAG that also retrieves a graph of relationships—combines vector retrieval and graph traversal before giving an LLM material for an answer.[5]
| Question or requirement | Vector RAG | Ontology and graphs |
|---|---|---|
| Summarize a policy or manual | Suitable | Not essential |
| Find similar documents | Suitable | Can provide support |
| Traverse relationships among customers, contracts, products, and incidents | Document retrieval alone is often insufficient | Suitable |
| Unify business terminology across systems | Difficult to govern with only a search dictionary | Suitable |
| Filter candidates against business rules | Requires separate rule implementation | Can state the rules explicitly |
| Share one meaning model among multiple AI agents | Definitions tend to fragment by RAG application | Can provide a common managed foundation |
If document summarization is the goal, evaluating conventional RAG first keeps the architecture smaller. Ontology becomes valuable when questions repeatedly cross systems and require relationship traversal.
Illustrative example: connecting training and AI adoption
The following is an illustrative example created for this article, not an official AWS implementation case.
Assume that an organization stores training attendance, AI tool requests, use cases, risks, and outcomes in separate systems. It wants to answer this question:
Which departments have employees who completed generative AI training but have not yet registered a use case?
Answering it requires relationships among employees, departments, training, and use cases. The table defines the broader set of business connections. Read each row from left to right, such as “an employee belongs to a department.” The terms in parentheses are system names.
| Starting entity | Relationship | Target entity |
|---|---|---|
Employee (Employee) | belongs to (belongsTo) | Department (Department) |
Employee (Employee) | attended (attended) | Training (Training) |
Employee (Employee) | created (created) | AI use case (AIUseCase) |
AI use case (AIUseCase) | uses (uses) | AI tool (AITool) |
AI tool (AITool) | is governed by (governedBy) | Policy (Policy) |
AI use case (AIUseCase) | has a risk category (hasRisk) | Risk category (RiskCategory) |
AI use case (AIUseCase) | creates (creates) | Business value (BusinessValue) |
The question can then be separated into three checks.
- Find employees who completed generative AI training and identify their departments
- Find employees who created AI use cases and identify their departments
- Compare the results by department and select departments that have trainees but no registered use cases
Vector RAG can retrieve relevant documents. Accurately comparing the attended, belongs-to, and created relationships, however, requires identifiers—values such as employee or department IDs that distinguish entities—and relationship definitions.
The value of ontology is the ability to manage these comparison conditions as reusable business knowledge.
Scope and evaluation criteria for enterprise adoption
A single business question that requires relationship traversal provides a limited scope for checking whether the required relationships can be retrieved and who will approve and manage them.
An adoption review should cover the following criteria.
| Evaluation item | Question to answer |
|---|---|
| Representative business question | Is it difficult to answer with document retrieval, and does it require relationship traversal? |
| Required concepts and relationships | Can the scope be limited to the customers, contracts, departments, requests, or other items needed for the answer? |
| Mapping to evidence data | Can each concept and relationship be traced to a system and field? |
| Approval-state management | Can AI-proposed, under-review, approved, and deprecated knowledge be distinguished? |
| Evaluation questions | Can the evaluation check not only the answer, but also the evidence path, authorization, and repeatability after data updates? |
| Scope expansion | Can more concepts and data sources be added only after the evaluation demonstrates value? |
Beyond answer accuracy, the evaluation should test whether incorrect relationships can be detected, source permissions can be preserved, and a person can verify the basis for an answer.
A large number of defined concepts does not make stale relationships useful. Without continuing maintenance of approved relationships, the evidence behind answers will drift away from business reality over time.
Governance and operating considerations
Adoption requires governance—the rules and responsibilities for handling information—in addition to retrieval quality. The main issues are how to treat AI-proposed relationships, who may view information inferred through relationship traversal, and how much self-managed operation the system requires.
Separate AI proposals from approved knowledge
customer_id, account_id, and user_id look similar, but they do not necessarily identify the same person or company.
An AI-proposed relationship should record its evidence, confidence, reviewer, and expiry condition. Candidates that have not been approved also need to remain separate from knowledge available to a production AI agent.
Control access to relationships and query results
Information may be viewable separately in its source systems while revealing something new when combined. Linking projects, assignees, organizational units, and transfer information, for example, may expose organizational information that no single source screen displays.
Access control should therefore cover namespaces—boundaries that separate data and definitions—concepts, relationships, and query results, not only rows and columns. The official repository includes namespace isolation and role-based access control, which assigns permissions according to a user’s role.[4]
Plan for self-hosting cost and maintenance
The Accelerator is self-hosted, meaning that the adopter installs and operates it in its own environment. It combines Neptune, OpenSearch Serverless, and Bedrock with data ingestion, authentication, runtime, and other supporting components.
In addition to estimating cloud charges, an organization needs owners for these tasks:
- Tracking changes to data sources and schemas
- Reviewing and versioning the ontology
- Evaluating AI model output and retrieval quality
- Managing permissions, checking audit logs, and responding to incidents
- Reassessing migration options after AWS Context becomes available
There is no need to add this operating load when conventional RAG satisfies the requirements. Compare benefit and cost when complex relationship retrieval or a shared business definition across systems is continuously required.
Points of comparison with Palantir Ontology
Calling the AWS initiative “AWS’s version of Palantir Ontology” can overstate its published scope.
Palantir describes Foundry Ontology as an operational layer that connects data with real business operations. In addition to objects, properties, and links, it includes actions that update business data, functions that perform calculations or processing, and dynamic security that changes access according to circumstances and conditions.[6]
Context Ontology Accelerator, by contrast, is a semantic context layer deployed into the adopter’s environment to supply business meaning and relationships to AI. Its published features center on Scan, Model, Serve, and AI-agent access through MCP.
The formal AWS Context specification will need to show how far the future service extends into business actions and operational capabilities.
A comparison should use a PoC, or Proof of Concept—a limited test of feasibility—to answer the following questions.
- Is the goal to manage meaning and relationships, or also to update business data on the same platform?
- How much of the existing AWS data platform and authorization design can be reused?
- Who approves ontology changes, and which applications receive them?
- Which operating responsibilities belong to the vendor and which remain with the adopter?
Summary: Choose ontology according to the business question
Ontology aligns the meanings of differently named data across systems and makes relationships and rules among customers, contracts, departments, and other entities traversable. Conventional RAG suits document summarization and similar-document retrieval, while ontology can add value when a business process repeatedly compares relationships across systems.
Context Ontology Accelerator is a public implementation for building that capability in an organization’s own environment. It should be evaluated separately from the future AWS Context service, with relationship approval, access to inferred results, maintenance ownership, and cost included in the decision.
The starting point is one question: “What business question is difficult to answer with the current document retrieval system?” Limiting the scope to one question, a small set of concepts, and explicit evaluation questions makes it easier to determine whether the additional system and operating load are justified.
This article is a general information summary and is not legal advice. Confirm practical decisions with a qualified specialist.
References
- Amazon Web Services, Amazon Web Services now introduces Context Ontology Accelerator, July 31, 2026
- Amazon Web Services, Context intelligence for your data and AI agents at scale, June 17, 2026
- Amazon Web Services, Build a semantic ontology to power AI assistants on AWS – Part 1, July 14, 2026
- Amazon Web Services, Context Ontology Accelerator
- Amazon Web Services, Improving generative AI accuracy with vector and graph search hybrid queries, May 18, 2026
- Palantir, Ontology architecture