POV | What We Believe, On the Record | Mactores

Ontology in AI: What Context Ontology Is and Why It Matters

Written by Gautham B | Nov 11, 2026, 12:23:06 PM

Key takeaways

  • Ontology in AI is the business's own map of its things, relationships, definitions and rules, and a context ontology hands that map to an AI system at the moment it answers.
  • The pump manufacturer in this guide had connectors to every system and retrieval over every contract, and its planning assistant still said no orders were at risk when 14 were.
  • The assistant's three misses were about meaning rather than missing data, since one part carried two codes, quarantined stock counted as available and an allocation rule sat in a supply agreement.
  • The same gap shows up in every industry, from a deposit's related accounts in banking to an attributed provider in healthcare, ARR in software and the SLA behind a network alarm in telecom.
  • AI drafted the manufacturer's first ontology in two days, and approving it took three weeks, because only the people who own each term can say what it means.
  • The open-source AWS Context Ontology Accelerator can run one today, and AWS Context, Databricks, Microsoft, Snowflake and Palantir all offer places to keep one as well.
 Mactores has been building data and AI systems on AWS since 2008. Since agents arrived, the problem we run into most isn't the model. It's an agent that can read every system a company owns and still doesn't know how the company works.

Our running example is an industrial pump manufacturer, made up but typical. It runs three plants, keeps purchasing and inventory in SAP, runs a separate manufacturing execution system at each plant and tracks stock in a warehouse management system. Last spring its planning team got an AI assistant with connectors to all three and retrieval over every supply agreement.

Its first real test came when a valve-housing supplier warned that a shipment would arrive 12 days late. A planner asked which customer orders would slip. The assistant found the purchase order, counted 340 housings on hand and said none would. Fourteen did, including two for the company's largest aerospace customer.

What Is Ontology in AI, and What Makes It a Context Ontology?

An ontology in AI is a formal model of a business domain that names the kinds of things in it, their properties, how they relate and the rules that hold between them, so software can work with that knowledge instead of guessing at it.

At the pump manufacturer, it would have been a written-down version of what its planners already knew. A housing called VH-2210 in SAP is the same part as M-4471 in the plant 2 MES. Stock in quarantine isn't available until quality releases it. When housings run short, the aerospace contract gets them first. None of that lived anywhere an AI could read it.

Computer scientists have used the idea for decades. Tom Gruber's widely cited definition calls an ontology an "explicit specification of a conceptualization", which is a precise way of saying it makes a shared understanding explicit enough for software to use.

A context ontology is that model put to work for AI. When an agent gets a question, it reads the ontology alongside the data, so it answers in the business's own terms rather than in whatever terms each table happens to use. That's why we describe it as the step after connectors and retrieval rather than a replacement for either.

What is a data ontology?

A data ontology is an ontology scoped to the data a company already holds. It describes what each table and field represents in business terms and how records in different systems relate to one another. At the pump manufacturer, it's the part that connects a purchase order in SAP to a work order in a plant's MES and a pallet in the warehouse system, and it knows that the pallet status QI means the housings on it are waiting for inspection.

None of those three systems could make that connection alone, because each one was designed to answer its own questions. That's why data ontology work usually starts with identity, meaning which records in which systems describe the same real thing, before it moves on to definitions and rules.

How is a context ontology different from a data catalog?

The pump manufacturer already had a catalog, and it listed every table in SAP and the warehouse system with an owner and a description. It could tell a planner where the stock table lived. It couldn't say that a status of QI on a pallet meant the housings weren't available, or that two part codes in two systems were the same housing. A catalog describes what data exists, and the ontology describes what the data means and how it connects, so most companies end up needing both.

Why Isn't More Data Enough for AI to Give Business Answers?

Because the pump manufacturer's assistant already had all the data, and that's what made its answer convincing. It saw 340 housings in the warehouse system, but 120 of them were in quarantine waiting on an inspection, and the warehouse system counts quarantined stock as on hand. It searched SAP for VH-2210 and never found the plant 2 work orders, which use the MES code M-4471. It also missed the allocation clause in the aerospace supply agreement, a paragraph on page 14 of a PDF that the retrieval step ranked below the delivery terms.

Retrieval-augmented generation did its job, which was finding relevant text. It couldn't tell the assistant that the clause was a rule that overrides the usual allocation, or that two part codes describe one physical housing. Those are facts about meaning, and no amount of extra data would have supplied them.

Gartner saw the wider version of this coming. In a February 2025 release, it predicted that through 2026 organizations "will abandon 60% of AI projects unsupported by AI-ready data," and a survey of 1,203 data management leaders found 63% either lacked the right data management practices for AI or weren't sure they had them. An AI-ready data foundation covers quality, lineage and access, and the ontology is the part of it that covers meaning.

Why can't the system prompt just explain the rules?

The manufacturer tried that first. After the late-housing miss, the planning team added the quarantine rule and the aerospace priority to the assistant's instructions, then a third rule about a second supplier, then a list of part-code pairs. By the time the prompt held 40 rules and 300 code pairs, the assistant was following some of them some of the time, and nobody could test which. Instructions in a prompt are suggestions the model weighs against everything else it reads, and the list never stops growing as the business changes.

What Does an Ontology Hold That a Database or a Document Doesn't?

A database holds records and a document holds text, and the ontology holds what connects them. For the pump manufacturer, the contents fell into five kinds, and each one came from somewhere different.

What it holds

At the pump manufacturer

Where it lived before

Things

Parts, suppliers, purchase orders, work orders, customer orders, warehouse locations

Tables in SAP, three plant MES databases and the warehouse system

Relationships

A housing goes into a pump, a pump fills a customer order, a supplier ships against a purchase order

Join logic in reports that one analyst maintained

Identity

VH-2210 in SAP and M-4471 in the plant 2 MES are the same housing

A spreadsheet on a planner's laptop

Definitions

Available stock excludes quarantine and stock already allocated to a work order

Three different SQL filters, one per team

Rules

When housings run short, the aerospace contract is filled first

Page 14 of a supply agreement PDF

The last two rows are where agents go wrong most often, because both look like data when they're really decisions someone made. Writing them down as part of the model, rather than as instructions in a prompt, is what lets the assistant follow them every time. It also lets a test catch the assistant when it doesn't.

 

That approach has already held up in production. At The New York Times, a graph built from the code of its PLATO subscription engine surfaced rules the team didn't know existed, which is part of how its legacy modernization with AI moved off Oracle in 12 weeks.

What are ontologies made of, and which standards do they use?

Most ontologies are built from the same few parts. Classes name the kinds of things, such as Part, Supplier and Work Order at the pump manufacturer. Properties describe them, like a pallet's status or a purchase order's promised date, while relationships connect them, so a supplier supplies a part and a part is used in a work order. Individuals are the actual records, such as the housing lot that arrived on Tuesday. Rules and constraints sit on top, for example that quarantined stock can't count toward available stock.

Ontologies meant to outlast one tool are usually written in open W3C standards. RDF describes facts as simple subject, relationship and object statements, OWL defines the classes and how they relate, and SHACL checks real data against the rules, so a pallet marked available while it's still in quarantine gets caught. AWS's Context Ontology Accelerator writes its ontologies in open W3C standards too, which is what lets an ontology move between platforms instead of being locked inside one.

What Does Context Ontology Look Like in Manufacturing, Banking, Healthcare, Software and Telecom?

The details change from one industry to the next, but the shape holds. In each of the five cases below, an agent gets a question it can't answer from any single system, and one rule changes the answer.

Industry

The question an agent gets

What the ontology connects

The rule that changes the answer

Manufacturing

"Which customer orders slip if this part arrives 12 days late?"

Part, supplier, purchase order, work order, stock location, customer order

Quarantined stock isn't available, and one contract gets priority

Banking

"Is this $9,400 cash deposit worth a second look?"

Depositor, business account, beneficial owner, related accounts

Cash deposits kept just under the $10,000 reporting threshold across related accounts are a structuring signal

Healthcare

"Which primary care provider owns this patient's A1c screening gap?"

Patient, care episodes, providers, network, payer contract

The payer contract's attribution method, not the most recent appointment

Software

"What was ARR at the end of Q3?"

Customer, contract, subscription, invoice, usage

ARR counts recurring subscription value live on the last day of the quarter, without one-time services or overages

Telecom

"Which enterprise customers does this fiber cut affect, and do any SLAs pay out?"

Network element, circuit, service, customer account, contract

Credits start only past the SLA's outage threshold and exclude planned maintenance

In manufacturing, the pump company's late-housing question is the typical first use case, and our context ontology for manufacturing work starts from the same kind of shortage question. For a global aerospace manufacturer, we're currently reconciling warehousing, shipping and material identifiers into one supply chain ontology.

In banking, an AML agent that sees the $9,400 deposit alone has nothing to flag. Linked to the beneficial owner and two related accounts that took $9,200 and $9,600 the same week, the pattern is obvious, and an examiner will later want to retrace how the agent saw it. That retrace depends on lineage captured as the work happens, the way Mactores built it for real-time MBS pricing at a capital markets firm.

In healthcare, a care coordination agent that credits the screening gap to the doctor the patient saw last month will route the outreach to the wrong practice. The ontology carries the payer's attribution method and the network each provider belongs to, with access to patient data set by policy, the same discipline behind KlearTrust's HIPAA-compliant claims platform, which passed its first-cycle audit.

In software, finance, sales and the board deck often carry three versions of ARR. An agent answering the CFO, or a customer's agent calling the product over MCP, has to use the signed one, and the ontology is where that definition lives along with seats and entitlements.

In telecom, the alarm names a network element, and nothing in the network system names a customer. The ontology walks from the element to circuits, services, accounts and contract terms, so a customer-facing agent, like the intent-based one Mactores built for Safaricom, can tell an enterprise customer what's affected and what the SLA says.

How Is a Context Ontology Built, and Who Decides What Each Term Means?

The pump manufacturer built its first one in about four weeks, scoped to the late-parts question and nothing else. AI did the first draft. Pointed at SAP, the three MES databases, the warehouse system and the supply agreements, it proposed the parts, suppliers and orders, the links between them and a list of likely matches across the systems' part codes. That draft took two days.

Approving it took three weeks, and the data team couldn't do it alone. The materials manager signed the definition of available stock. The commercial lead confirmed the aerospace allocation rule and the date it applies from, and a planner from each plant checked the part-code matches, rejecting 11 of the 212 the AI had proposed. Each term ended up with a named owner, which is the part most programs skip.

The last step was a test. Planners wrote down 25 questions they actually ask about shortages, with the right answers, and the assistant had to get them right before anyone relied on it. It now names the 14 orders in the original late-housing case, and it explains that 120 housings are in quarantine.

How does a context ontology stay current?

The same way it was built, with owners approving changes. In its first two months, the manufacturer added a second housing supplier, retired a plant 3 part code and renewed the aerospace contract with a new allocation share. Each change was drafted by the AI from the source systems, approved by whoever owned that term and checked against the 25 test questions before it went live. A change that broke an answer went back to its owner rather than into production.

A forward-deployed engineer is the role that usually holds this together, sitting with the people who own each term and turning their decisions into the model. The same owners decide what an agent may do with the answers, which is the authority question that decides whether AI agents in production can be trusted with real work.

Where Can It Live: the Context Ontology Accelerator, AWS Context or Another Platform?

The pump manufacturer's data already sat in an S3 lake, so it started on the open-source AWS Context Ontology Accelerator, which AWS released on July 31, 2026. The accelerator drafts the ontology with models on Amazon Bedrock, holds each element for an expert to approve, stores the result in a graph on Amazon Neptune that the company owns and serves it to agents through an MCP server. AWS says ontologies built this way will carry into AWS Context, the managed service it announced in June 2026 and still listed as coming soon in November.

Companies whose data lives elsewhere have their own options. Databricks offers Genie Ontology in public preview, Microsoft's Fabric IQ has an ontology item in preview, Snowflake put Horizon Context into preview in October 2026, and Palantir's Ontology has sat at the center of Foundry for years. The work of agreeing what each term means and who owns it is the same on all of them, which is why the manufacturer kept its signed definitions in an open format it could move.

How Mactores Builds a Context Ontology

Mactores is the agent-native AWS modernization firm. We build context ontologies in your own AWS account, on the Context Ontology Accelerator today and on AWS Context once AWS releases it, starting from one question your agents currently get wrong. Agents handle the repeatable work of profiling sources, drafting the model and proposing matches, while forward-deployed engineers work with your owners on every definition and rule.

The production date and fee go into the statement of work before anything starts, and 94% of our engagements have been delivered by the date we committed to, or earlier. The first step is a 30-minute working session with the engineer who'd own the work. Bring the question your AI got wrong last quarter, and we'll show you which definitions and rules it was missing.