AWS Ontology: An Introduction to Context Ontology Accelerator
What you’ll learn
- How definitions of business meaning, data layouts, relationship records, and related-document retrieval serve different roles
- How the Context Ontology Accelerator’s Scan, Model, and Serve stages map to AWS services
- How to start with one business question and assign approval, authorization, cost, and maintenance responsibilities
AWS ontology gives AI agents business meaning and relationships
An ontology gives differently named data a shared set of business meanings, relationships, and rules. AWS’s Context Ontology Accelerator is a public implementation for discovering, modeling, and serving those relationships to AI systems. Separating it from the future AWS Context capability and conventional RAG clarifies which business questions need connected relationships and which approval, access, and maintenance decisions still belong to people.
By the end of this article, you will have practical criteria for answering “When should an ontology be added instead of relying on conventional RAG?” in your own context.
Context Ontology Accelerator and AWS Context Have Different Delivery Models
AWS currently provides Context Ontology Accelerator, whose contents anyone can inspect and use to supply AI with the meaning and relationships in enterprise data. This self-deployed release must be distinguished from AWS Context, a future service AWS plans to operate for customers.
Context Ontology Accelerator is an available open-source implementation
AWS released Context Ontology Accelerator under the Apache License 2.0 on July 31, 2026. AWS describes an ontology as a machine-readable model of an organization’s products, customers, policies, and operating rules.[1]
The Accelerator connects to data organized in tables and to documents whose structure varies, then uses AI to draft meanings and relationships. The generated material does not immediately become authoritative knowledge. People who know the business area review, edit, and approve it before storing it in a form that lets the organization trace how one item relates to another. The public release uses common standards that several products can read and supplies the information through MCP, a shared connection point between AI and outside tools or data.[1]
The initial release primarily uses three services.[1]
- Amazon Neptune: Stores business items such as customers and contracts and the relationships between them
- Amazon OpenSearch Serverless: Finds information whose meaning is close to a question
- Amazon Bedrock: Provides AI services that suggest meanings and relationships and assist retrieval
This is not a completed service operated by AWS. It is an Accelerator deployed into the adopting organization’s AWS account. Data connections, access control, model configuration, monitoring, and cost management remain part of the adopter’s design responsibility.
AWS Context is positioned as a future managed capability
In June 2026, AWS announced AWS Context as a forthcoming service that would automatically map relationships across existing data into a knowledge graph. The service is intended to give AI agents governed data relationships, business rules, and domain knowledge at runtime.[2]
The July 31 announcement states that the Accelerator’s user-defined ontology capability is planned to become a native managed feature of AWS Context. AWS also says that ontologies created with the Accelerator will be usable and manageable through AWS Context.[1]
An adoption plan should therefore keep these two stages separate.
| Category | Current position | Adopter responsibility |
|---|---|---|
| Context Ontology Accelerator | A public release that an organization installs and may modify | Installation in AWS, updates, monitoring, cost, and maintenance of business terms and relationships |
| AWS Context | A forthcoming service that AWS plans to operate | Confirm the formal scope, pricing, and migration conditions after release |
Separate ontology, schema, knowledge graph, and RAG
An ontology defines the meaning of concepts, relationships, constraints, and rules in real business operations. It is not a data storage location. Its role differs from database structure and retrieval methods.
| Element | What it defines | Example |
|---|---|---|
| Database | Where actual data is stored | Customer table, contract table |
| Data blueprint (schema) | Tables, fields, and whether a value is text or a number | account_id is text |
| Business-meaning design (ontology) | Meanings such as customer and contract, plus relationships, constraints, and rules | A customer holds a contract |
| Traceable relationship record (knowledge graph) | Actual items and relationships connected under those definitions | Company A → holds → Contract 123 |
| Related-document retrieval (RAG) | A process that finds relevant information and gives it to AI as answer material | Retrieve policy documents before answering |
For example, a sales system’s Account and a core system’s Customer may refer to the same business concept, but an AI agent cannot determine that from their names alone. Adding the shared concept and mapping to an ontology translates system-specific terminology into business meaning.
If the ontology defines that a customer may hold a contract, the knowledge graph stores a fact such as Company A holding Contract 123. When this distinction is unclear, AI-proposed relationships and organization-approved relationships may be treated as if they have the same level of trust.
The Accelerator follows a Scan, Model, and Serve workflow
The official Context Ontology Accelerator repository explains the architecture as a three-stage Scan, Model, and Serve workflow.[4]
Scan discovers candidates from existing data
Scan examines how connected data is arranged, adds basic information such as names and descriptions, and imports documents whose format varies. An AWS technical article describes both starting from an ideal overall model and building upward from relationship candidates found in existing data structures and values.[3]
The bottom-up approach begins with data that actually exists. However, similar column names or values do not necessarily represent the same business concept. Automated extraction should be treated as a process that creates review candidates rather than a completed model.
Model turns meaning and rules into reviewable knowledge
During Model, AI proposes business items, words with the same meaning, relationships, and measurements for people familiar with the business to review. The public release places the creation and management of meanings and relationships, measurement definitions, and a relationship map that connects several data sources by meaning in this stage.[4]
Teams need to trace who approved each proposed meaning and relationship. Recording the concept owner, source data, confidence, approval state, and deprecation state makes incorrect relationships easier to correct later.
Serve supplies only the context required by the question
Serve searches across several relationship records, follows their connections, and sends only information needed for the question to AI through MCP.[4] A system can first find an item whose meaning is close to a user’s question, then follow the relationships that have been stated explicitly.
Instead of giving an AI agent all available data, retrieval can be limited to the concepts, relationships, rules, and evidence relevant to a question. This also makes it easier to record the path used as the basis for an answer.
Conventional RAG differs in retrieval target and answer structure
Conventional vector RAG is suitable for finding passages with meaning similar to a question. Ontology and graph retrieval are suitable for traversing explicit relationships and rules across several entities. They are complementary rather than replacement technologies.
AWS characterizes vector search as finding semantically similar information and graph search as exploring how information is connected. GraphRAG—RAG that includes a graph in retrieval—combines vector retrieval and graph traversal before providing context to an LLM.[5]
| Question or requirement | Prioritize vector RAG | Consider ontology and graphs |
|---|---|---|
| Summarize a policy or manual | Suitable | Not essential |
| Find similar documents | Suitable | Can be used as support |
| Traverse relationships among a customer, contracts, products, and incidents | Documents alone are often insufficient | Suitable |
| Unify business terminology across systems | Difficult to govern with only a search dictionary | Suitable |
| Filter candidates against business rules | Requires rules to be implemented separately | Rules can be stated in the ontology |
| Share one meaning model across several AI agents | Knowledge often fragments by RAG application | Can serve as a common layer |
If document summarization is the only goal, evaluating conventional RAG first keeps the architecture smaller. Ontology has a clearer purpose when questions repeatedly cross systems and depend on relationships.
Consider relationship retrieval through an AI adoption and training example
The following is an illustrative example created for this article, not an official implementation case. It assumes that training, AI tool requests, use cases, risks, and outcomes are stored in separate systems.
This is not a set of program instructions. It is a list that defines how business concepts connect in the ontology. The following table reads from left to right as “who or what,” “how it is related,” and “what it connects to.” For example, the first row means “an employee belongs to a department.” The terms in parentheses are the concept and relationship names used in the system.
| Who or what (starting concept) | How it is related | What it connects to (target concept) |
|---|---|---|
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) |
With this structure, a question can be decomposed into a relationship path.
Which departments have employees who completed generative AI training but have not yet registered a use case?
Training
→ Employees who attended
→ Their Departments
→ Employees who created an AIUseCase
→ Compare the departmental setsVector RAG can retrieve relevant documents, but accurately comparing attended, belongs-to, and created relationships requires identifiers and relationship definitions. The value of ontology is not a longer answer. It is the ability to manage the comparison logic as reusable business knowledge.
Begin enterprise adoption with one business question
My recommendation in this article is to begin with one business question that requires relationship retrieval, rather than attempting to build an enterprise-wide ontology immediately. The following sequence keeps technical validation and governance design within the same scope.
- Choose a representative question: Select a question that document retrieval cannot answer well and that requires relationship traversal
- Limit the core concepts and relationships: Define only the customers, contracts, departments, requests, or other elements required by that question
- Map the evidence data: Record which system and field support each concept and relationship
- Design approval states: Separate AI-proposed, under-review, approved, and deprecated knowledge
- Prepare evaluation questions: Test not only correct answers but also evidence paths, authorization, and repeatability after updates
- Expand only the useful scope: Add concepts and data sources after the evaluation demonstrates value
Success criteria should include whether incorrect relationships can be detected, source permissions can be preserved, and a person can verify the basis of an answer. In practice, ontology quality is better judged by the organization’s ability to maintain approved relationships than by the number of concepts in the model.
Evaluate governance and operating load before adoption
An adoption decision for Context Ontology Accelerator must evaluate incorrect relationships, information exposure through inference, and self-hosted operations—not only expected retrieval quality.
Keep AI-proposed relationships separate from authoritative 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 carry evidence, confidence, a reviewer, and an expiry condition. The production agent also needs a state boundary that prevents it from using candidates before approval.
Authorize relationship paths as well as source data
Information may be individually viewable in its source systems while revealing new information when several relationships are connected. Linking projects, assignees, organizational units, and planned transfers, for example, can derive organizational information not shown on any one source screen.
Access control should therefore be evaluated for namespaces, concepts, relationships, and query results in addition to rows and columns. The official repository includes namespace isolation and role-based access control in its design.[4]
Assign owners for self-hosted cost and maintenance
The Accelerator combines Neptune, OpenSearch Serverless, and Bedrock with ingestion, authentication, runtime, and other supporting components. The operating model should assign responsibility for more than cloud charges.
- Tracking data-source and schema changes
- Reviewing and versioning the ontology
- Evaluating model output and retrieval quality
- Managing permissions, audit logs, and incident response
- Reassessing migration options after AWS Context becomes available
There is no reason to add this operating load when conventional RAG meets the requirement. It becomes an investment candidate when complex relationship retrieval and shared business definitions are continuously required.
Compare Palantir Ontology by published scope
Calling the AWS initiative “AWS’s version of Palantir Ontology” can overstate the currently published scope. Palantir describes Foundry Ontology as an organization’s operational layer, including objects, properties, and links as well as actions, functions, and dynamic security.[6]
Context Ontology Accelerator, by contrast, is currently a semantic context layer deployed into the adopter’s environment. Its published focus is Scan, Model, Serve, and agent access through MCP. The formal AWS Context specification will need to show how far the managed service extends into business actions and operational capabilities.
The comparison should use a PoC, or Proof of Concept—a limited validation of feasibility—to evaluate requirements rather than map product names directly.
- Is the goal to manage meaning and relationships, or also execute business updates 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?
- Should operational responsibility sit with a vendor or with the adopting organization?
Summary: Test Ontology on One Business Question That Document Retrieval Cannot Answer
AWS ontology provides business meaning, relationships, and rules for enterprise data so AI agents can retrieve the context required for a task. Planning must distinguish between the currently available Context Ontology Accelerator and the forthcoming managed AWS Context service.
- The Accelerator is released under Apache 2.0 and deployed into the adopter’s AWS environment
- Neptune stores relationships, OpenSearch Serverless supports semantic search, and Bedrock provides AI processing
- Domain experts review AI proposals and manage approved knowledge separately
- Conventional RAG is suited to passage retrieval, while ontology and graphs are suited to explicit relationships and rules
- Adoption requires decisions about relationship approval, authorization of inferred results, operating ownership, and cost
The first question to ask is whether the business problem can be answered through document retrieval or requires relationships across several systems. Selecting one recurring problem in the second category and validating it with a small set of concepts and evaluation questions makes the value of adding ontology easier to judge.
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, 2026
- Amazon Web Services, Improving generative AI accuracy with vector and graph search hybrid queries, May 18, 2026
- Palantir, Ontology architecture
For the latest releases and updates, check the official website and official documentation.