The Quality Ontology: Why Pharma AI Needs a Knowledge Graph, Not a Data Warehouse

Consider a question that a VP Quality at a multi-site pharmaceutical manufacturer might ask: “Which of our products are at risk from the particle size variability we’re seeing in MCC lots from Supplier B?”

To answer this properly, you need to traverse data across at least four systems:

1. ERP — which products use MCC from Supplier B, and which material lots have been received recently?
2. LIMS — what are the incoming CoA results for those lots, specifically particle size D90?
3. MES — which batches consumed those lots, and what were the in-process and release results?
4. QMS — have any deviations been raised for those batches, and what were the root causes?

And you need to do this not just for one product, but across every product that uses MCC, across every manufacturing site, with enough historical depth to establish whether the particle size trend is real and whether it correlates with quality outcomes.

No QA analyst does this routinely. The data lives in four separate systems with different schemas, different naming conventions, and no shared context. The analyst would need days — or weeks — to manually extract, align, and analyse the data. In practice, they don’t. They investigate the deviation in front of them, in the system where it was logged, with whatever batch-specific context they can manually gather.

This is not a people problem. It is an architecture problem. And the architecture that solves it is not a data warehouse, not a data lake, and not a BI dashboard. It is a quality ontology — a connected knowledge graph where relationships carry meaning, enriched with a signal layer that maintains computed intelligence on every node and every edge, continuously updated as manufacturing data flows in.

This whitepaper describes what a quality ontology is, how it gets built by an AI agent, and why it is the prerequisite for every agentic use case in pharmaceutical manufacturing.

The quality ontology is a knowledge graph where the nodes are manufacturing entities — products, batches, CQAs, CPPs, raw materials, material lots, equipment, rooms, operators, deviations, CAPAs, stability studies, complaints, and specifications — and the edges are the relationships between them.

These relationships are first-class citizens in the ontology. They are not foreign keys in a relational database. They carry domain meaning:

• A Batch was manufactured using a Material Lot on an Equipment Train by an Operator in a Room under specific Environmental Conditions
• That Batch produced CQA Results that are governed by Specifications and trended against Process Capability history
• That Material Lot was supplied by a Supplier and has a Certificate of Analysis with Material Attributes (particle size, moisture, purity)
• A Deviation occurred during that Batch and was investigated with a Root Cause and resolved through a CAPA
• That Product is also manufactured at Site B, where the same CQAs are measured but different equipment is used

These relationships are what enable an agent to answer questions that no single system can answer. “Which material lots correlate with dissolution drift?” requires traversing from LIMS results → batch records → material lots → supplier data. “Which other products are at risk?” requires traversing from material lot → all batches using that lot → all products → their CQA trends. No SQL query across disconnected systems can do this. The ontology can.

Building a quality ontology manually — mapping every entity, every relationship, every field from every source system — would be a multi-month data engineering project. It would require deep knowledge of every system’s schema, every naming convention, every data format quirk. And it would be outdated the moment a new system was connected or a new product was launched.

In Celestara, the ontology is built by the Ontology Builder Agent — the base Celestara agent equipped with a specialised Ontology Builder skill. The quality expert works with the agent through a conversational interface: directing which systems to connect, reviewing proposed entities and relationships, and refining the ontology as the graph materializes in real time.

The agent has access to two categories of capabilities:

MCP Tools — one tool per connected source system. Each MCP tool is a purpose-built connector that can query, discover, and extract data from a specific system:

• mes-tool: connects to the MES (PAS-X, MESPAS, or Celestara MES). Lists batch records, queries process parameters, retrieves in-process results, enumerates equipment and room metadata.
• lims-tool: connects to the LIMS (LabWare, STARLIMS, Empower). Lists test methods, retrieves analytical results, queries specifications, enumerates instruments.
• qms-tool: connects to the QMS (Veeva, TrackWise, MasterControl). Lists deviations, investigations, CAPAs, change controls, complaints, and their relationships.
• erp-tool: connects to the ERP (SAP, Oracle). Queries material master data, supplier records, material lot receipts, inventory, and bill of materials.
• stability-tool: connects to the stability data system. Retrieves study designs, time-point results, storage conditions.
• env-monitoring-tool: connects to the environmental monitoring system. Retrieves room classifications, particle counts, temperature/humidity logs.

Each MCP tool exposes a consistent interface — discover_schema(), list_entities(), query_data(), get_sample() — allowing the agent to explore any connected system without system-specific knowledge hard-coded into the agent itself.

Ontology Builder Skill — a specialised skill that provides the agent with capabilities to propose entity types, propose relationships, map source fields to ontology attributes, validate mappings against sample data, and generate data lineage documentation.

The building process follows five structured steps, each with human-in-the-loop validation.

Step 1 — System Discovery

The agent uses each MCP tool to discover what data exists across all connected systems. It calls discover_schema() on MES, LIMS, QMS, and ERP to understand the data landscape: what entities exist, what attributes they have, and — critically — what the join keys are. For example, it discovers that batch_id appears in MES, LIMS, and QMS, establishing the cross-system link between production, testing, and quality events.

The agent discovers the data landscape automatically — no manual schema documentation required.

Step 2 — Ontology Proposal (Human-in-the-Loop)

The agent proposes an initial ontology structure based on what it discovered. This is where LLM reasoning is critical — the agent doesn’t just list tables, it understands pharmaceutical manufacturing and proposes a domain-meaningful ontology: Product, Batch, CQA Result, CPP Reading, Material Lot, Equipment, Deviation, CAPA. It proposes relationships: Batch uses Material Lot, Batch produced CQA Result, Deviation resolved by CAPA. And it asks specific questions: “Your LIMS has 47 test codes — which are CQA tests vs. routine? I see 23 deviations with no batch_id — should these link to Equipment or Room?”

The quality team reviews, answers questions, and approves or modifies. The agent shows its work and waits for confirmation.

Step 3 — Field Mapping and Sample Validation

With the structure approved, the agent maps specific fields from each source system to ontology attributes. For every mapping, it pulls sample data through the MCP tools and validates: “LIMS.test_results.result → CQAResult.measuredValue. Sample: Batch B-2024-0887, Test Dissolution, Result: 85.2%. Value is numeric, within expected range, units match.” It surfaces discrepancies: “LIMS uses product code MET-500 while MES uses METFORMIN-500MG. 12 products have mismatched codes — recommend creating a mapping table.”

Every mapping is validated against real data. Discrepancies are surfaced — not silently ignored.

Step 4 — Data Lineage and ETL Generation

The agent generates full data lineage documentation and executable ETL pipelines. For every attribute in the ontology, it documents: source system, source field, transformation applied, join path, refresh frequency, and validation rules. It produces working extraction scripts that use the MCP tool interfaces to pull, transform, validate, and load data — with scheduling configuration for real-time (API-connected), batch (daily dumps), and one-time (historical loads).

Data lineage is a first-class concept — every ontology attribute traces back to its exact source record.

Step 5 — Continuous Evolution

The ontology is not static. When a new LIMS test is added for a product, the agent detects it during the next data sync, proposes an ontology update (“New test code IMPURITY-D detected for Product X. Classify as CQA?”), and waits for human approval before implementing. When a new system is connected, the agent discovers its schema and proposes how it should integrate into the existing ontology. The ontology evolves with the manufacturing operation.

Every structural change requires human approval. The agent proposes — humans decide.

Once the ontology structure is validated, the agent builds the data pipelines that keep it alive — the full extraction, transformation, and loading DAG, generated through the same conversational process.

A knowledge graph with entities and relationships is a powerful data integration tool. But integration alone doesn’t answer quality questions. Knowing that a batch consumed a material lot is useful. Knowing that material lot variability has a 0.78 sensitivity coefficient to dissolution for that specific product — and that the sensitivity is increasing — is intelligence.

This is the signal layer: continuously computed metrics that live on every entity and every relationship in the graph, evolving as new manufacturing data flows in. Signals are not raw data. They are derived intelligence — computed by statistical tools that the agent invokes, maintained on the graph so that the agent can reason over them instantly without recomputing from scratch.

But the signal layer becomes uniquely powerful when applied to relationships — the edges in the graph. Relationships in a traditional database are binary: Product X uses Material Y. In the signalled ontology, relationships carry quantitative intelligence about the nature of that connection:

Signal computation is triggered by data events flowing through the ontology:

When a new batch’s CQA results arrive from LIMS, the agent recalculates: the product’s Ppk values, the CQA trend classification, the OOS probability projection, and the material sensitivity coefficients for the material lots used in that batch.

When a new material lot arrives (CoA data ingested from ERP/supplier quality), the agent recalculates: the supplier’s lot-to-lot variability index, the material quality trend, and checks whether the lot’s attributes fall in a range that historically correlates with quality risk for any product that uses this material.

When an equipment maintenance event is logged, the agent resets the “batches since maintenance” counter and recalculates the equipment quality output trend.

These are quantitative signals — computed by statistical tools the agent invokes. But the ontology also maintains qualitative signals — generated by the agent’s LLM reasoning over the quantitative signals and contextual data:

A risk narrative on a product entity: “Product X quality is stable overall, but dissolution margin is narrowing due to increasing MCC particle size variability from Supplier B. Two corrective actions are in progress. If the material trend continues without intervention, OOS probability will exceed acceptable threshold within 8 weeks.”

A supplier assessment on a supplier entity: “Supplier B has shown a gradual increase in MCC particle size D90 over the last 5 lots, moving from the middle of the specification range toward the upper boundary. No change notification has been received. This is not yet a specification exceedance but is creating downstream quality pressure for 3 products.”

A relationship insight on a Product→Equipment edge: “Product X produces consistently lower dissolution on Compression Line 3 compared to Line 1 (mean difference: 2.3%). Gap has widened from 1.1% to 2.3% over the last 6 months. Correlation with Line 3 tooling age suggests punch wear as the contributing factor.”

These qualitative signals are not static text. They are regenerated as the underlying quantitative signals change, ensuring the narrative always reflects the current state.

This is the mechanism that connects the ontology to every downstream use case. When an agent needs to reason about a specific quality question — “Should we be concerned about Product X’s dissolution trend?” — it assembles a context graph: the relevant subgraph of the ontology with all current signal values loaded on the nodes and edges.

For Product X’s dissolution question, the context graph includes:

• Product X node with signals: Ppk for dissolution = 1.35 (declining), OOS probability = 11%, trend classification = gradual drift
• Edge: Product X → uses → MCC with signal: sensitivity coefficient for dissolution = 0.78 (high), material attribute that matters most = particle size D90
• MCC Supplier B node with signal: PSD variability trending upward, quality trajectory = declining
• Recent MCC lots with signals: D90 values of 172, 178, 185, 188, 192μm over last 5 lots
• Compression Line 3 node with signal: 620 batches since tooling change (recommended: 500), quality output trend = slightly declining
• Edge: Product X → manufactured on → Line 3 with signal: equipment-specific quality offset for dissolution = -2.3% vs. Line 1

The agent doesn’t need to compute any of this at reasoning time. The signals are already on the graph, maintained by signal computation skills. The agent’s job is to assemble the context graph, read the signals, and reason about what they mean together:

“Dissolution is declining because of two compounding factors: material particle size is increasing (high sensitivity edge signal) and equipment quality is degrading (tooling age signal). Each factor alone accounts for roughly half the observed Ppk decline. Both are addressable independently.”

This is the fundamental mechanism behind every functional capability. The agent reasons over a signalled graph — not over raw data, not over pre-built ML models, not over dashboards. The signal layer transforms the ontology from a data integration platform into a quality intelligence system.

The quality ontology is not a standalone product. It is the foundation layer that enables every agentic use case in pharmaceutical manufacturing. Here is how the ontology’s capabilities — entity relationships, signal computation, and context graph assembly — map to specific quality operations:

The pattern is consistent across use cases. The ontology provides the connected data. The signal layer provides the pre-computed intelligence. The context graph provides the scoped reasoning input. The agent provides the domain reasoning and natural language output. No use case requires building custom software — each is delivered by configuring a skill that tells the agent what to reason about and how to act on its conclusions.

The quality ontology is not a product feature. It is the architectural foundation that determines whether AI agents can reason about pharmaceutical quality — or whether they remain chatbots that search documents and fill in templates.

With a signalled ontology, an agent can:

• Detect a CQA trend and autonomously investigate the probable cause across every connected system in seconds
• Predict which batches are at risk of OOS before they fail, based on the compounding signals from material, equipment, and environmental factors
• Generate a CAPA recommendation based on what has actually worked for similar root causes across the entire manufacturing network — not based on generic templates
• Produce an APQR that tells the genuine quality story of a product’s year, with forward-looking recommendations grounded in signal trajectories
• Answer novel quality questions that no one anticipated when the system was designed, because the graph structure and signal layer support open-ended reasoning

Without the ontology, every one of these use cases requires months of custom data engineering, manual cross-system analysis, and static query development. With the ontology, they are skills that an agent can execute immediately — because the intelligence is pre-computed, the relationships are navigable, and the data lineage is complete.

The ontology is what separates pharmaceutical AI that demonstrates well in a conference presentation from pharmaceutical AI that operates at production scale across 50 sites. It is the infrastructure layer that most organisations don’t think about until they try to deploy their third agentic use case and discover that the first two were built on bespoke data pipelines that don’t generalise.

Build the ontology first. Everything else follows.