Operational context in pharma: ontologies, knowledge graphs, and source grounding

What operational context is

Operational context is the layer that lets a question be answered across systems rather than only inside one.

It has three parts, and they do different work. A definition of the things the operation deals with and how they relate to each other: vessels, materials, lots, batches, procedures, results, and people. A store of the actual instances and their links: this vessel, this lot, this batch, consumed at this step. And a record, attached to every value, of the document or system it was read from.

Those functions require meaning and provenance as well as storage. An operation can hold a complete copy of every system's data and still be unable to answer a question that crosses two of them, because the information needed to do the crossing is not in either copy.

That is the claim this guide defends, and it’s worth stating plainly we dive in: the hard part is not getting the data, it’s knowing what it refers to.

One vessel, five names

The abstraction is easier to hold after a concrete case.

Consider this fictional example. A 2,000-liter bioreactor in Suite 2 appears in the process historian as the tag path S2.A14.BR003.TT01.PV, which encodes site, area, equipment, instrument, and process value. The maintenance system holds it as asset BIO-2291, described as "Bioreactor #3, Suite 2". The batch system calls it work unit WU-BR-03 under a work center. The engineering drawing register calls it V-2140. The validation master plan calls it BRX-3.

Five identifiers, one vessel. In this example, no system records the equivalence. A question as ordinary as "which deviations touched this bioreactor last quarter" is answered today by a person who holds the mapping in their head, and that person is a single point of failure.

It gets worse when the asset changes. Replace the vessel after a failure and maintenance retires BIO-2291 and issues BIO-2847, while the historian keeps BR003, because that tag names a position rather than a thing, and the batch system keeps WU-BR-03, because a work unit is a role. A trend drawn across the replacement date now mixes two physical vessels without saying so. The standards bodies have been pulling these apart for exactly this reason: the second edition of IEC 61512-1, published in 2026, describes a role-based equipment model distinct from an equipment entity model, and the 2025 update to ISA-95 Part 1 similarly separates role-based equipment from physical assets.

*All equipment identifiers and values are fictional and illustrative

Materials behave the same way. Procurement knows a vendor part number and a supplier code. The warehouse knows a lot number and a bin. The laboratory knows a sample identifier drawn from that lot and tested against a specification. The batch record references a raw material code consumed at step 14. The dossier identifies the substance by its FDA Unique Ingredient Identifier. If the identifiers are not mapped, answering which batches used a supplier's material requires reconciling the records first.

Then there’s the collision that produces a wrong answer rather than no answer. Two systems both record a column called yield. One means grams of product per liter of harvest; the other means percent of theoretical. Both are consistent with themselves. Averaged together they mean nothing, and nothing in either system flags the overlap or mismatch.

Taxonomy, ontology, and knowledge graph

These four words are often used interchangeably in conversations, but they shouldn’t be. Each item is distinct.

These distinctions matter when you ask a question across systems. Shared definitions help explain what the records mean. The knowledge graph records which vessel, batch, or material they refer to and how those things are connected. Someone still has to establish and maintain those connections.

Why putting it all in one place does not solve this

The standard response to data scattered across systems is to centralize it. It’s a reasonable instinct, but it addresses the wrong half of the problem.

The FAIR principles, published in Scientific Data in 2016, are useful here because they separate the halves explicitly. Findable and Accessible are about location and retrieval. Interoperable is a separate requirement, specified as three things: a formal shared language for representing knowledge, vocabularies that are themselves governed, and qualified references between records. Centralized storage can support findability and access, but does not by itself satisfy FAIR requirements or establish interoperability. FAIR enumerates interoperability separately because it is not a consequence of access.

The technical reason is narrow. Copying a record preserves its contents and its original structure. It does not create a missing assertion that two records describe the same real-world thing. The historian's BR003 is not linked to the maintenance system's BIO-2291 in the historian, not linked in the maintenance system, and therefore not linked in any copy of either. Ingestion is faithful to the data and empty with respect to the relationship.

Deferring interpretation to query time moves the problem rather than solving it. Every analyst reconstructs the mapping independently; each reconstruction is undocumented, unversioned, unreviewed, and invisible to the next person. Ten analysts produce ten mappings and, the risk is, several different answers to one question. Mappings embedded in query code can be inspected, tested, and approved if the code is governed. Without versioning, ownership, and review, those mappings are difficult to reuse or audit.

Three consequences follow, and they’re the ones an operations cares about:

• Joins become inference. With no shared identifier, systems are joined on timestamps, fuzzy matches against free-text descriptions, or an analyst's recollection. Without recorded evidence and review, an inferred match can be mistaken for an established fact. Joining on time depends on clocks that may differ between systems and may not record a time zone at all.
• The answer is not reproducible. The same question asked twice, by two people or six months apart, can return different numbers.
• There is nothing to inspect. No artifact records what was mapped to what, so there is nothing for a reviewer or an inspector to review.

What a knowledge graph holds

A graph is a plain structure. Nodes are things, and edges are relations between them.

In a plant the nodes are the vessel, the lot, the batch, the step, the result, the specification, the procedure, the deviation, and the person. The edges are the statements that connect them: this batch was produced on that vessel, consumed that lot, executed that procedure version, produced that result, raised that deviation. Each entity carries a globally unique identifier, so a reference to it is unambiguous wherever it appears.

The gain is that the join is retrieved rather than inferred. "Which batches used material from lot 2231-B, and which of them raised a deviation" is a traversal of recorded edges, not a reconstruction. The links were defined once, by an accountable party, and can be examined.

There’s also a maintenance point here that’s easy to miss. A shared vocabulary is a living artifact, not a one-time decision. The OBO Foundry's principles make the strongest version of this rule: a term's identifier must always denote the same referents, and a change substantive enough to alter meaning requires a new identifier rather than a redefinition of the old one. That rule is what keeps an answer given two years ago still meaning what it meant then. Without it, historical results drift silently.

Published work exists in this domain. A paper in PLOS ONE in January 2026 described a bioprocess knowledge graph built on a four-level ontology, with a dictionary mapping term variants to standard names, and an interface that shows the source sentence and the identifier of the publication behind every link. A NIST-authored paper presented at ASME IDETC-CIE in 2024 built an ontology and knowledge graph for verification of a fed-batch bioreactor operation and tested it with executable queries derived from competency questions. Both are worth reading, and both are careful about what a graph is: a record of what the sources say, not an oracle.

Source grounding, and why it’s separate from accuracy

Source grounding means that every value carries a path back to the record it came from, so a result can be taken apart and checked.

It’s not the same thing as being correct, and conflating the two causes trouble. A grounded answer can be wrong, and that is the point: when it’s wrong, the error is findable, because the chain from conclusion to source is recorded. An answer without source links needs other adequate evidence before it can support a regulated decision; apparent correctness alone is insufficient.

The W3C has published a vocabulary for this since 2013. PROV-O includes three core classes and several relations; three useful relations are used here. An entity is a thing, physical, digital, or conceptual. An activity is something occurring over a period that acts on entities. An agent is a person, organization, or software agent bearing responsibility for an entity or activity. The relations state that an entity was generated by an activity, was derived from another entity, and was attributed to an agent. Mapped onto a plant, a value is an entity, the batch step or instrument run that produced it is an activity, and the operator or system responsible is an agent. Three statements give a traceable chain, in a vocabulary that has been stable for over a decade.

The Allotrope Data Format is a worked example of the same idea implemented at file level. It carries the numbers as multidimensional data cubes, the meaning as an RDF graph built over the Allotrope ontology, shape constraints that define what a valid instance must contain, and an audit trail, in one file. The ontology suite is versioned; implementations should record the release they use.

The connection to AI is direct. An AI answer is only as inspectable as its grounding. The draft EU GMP Annex 22 asks for recorded intended use, a characterized description of input data, recorded feature attribution, logged confidence scores, and monitoring of whether inputs stay within the range the model was built for. The EMA and FDA guiding principles published in January 2026 ask for data provenance, processing steps, and analytical decisions documented in a traceable and verifiable manner. Both address model quality as well as documentation and traceability. Provenance supports review, but does not by itself demonstrate model performance.

The standards that already exist

A plant building an ontology does not start from nothing. Several bodies have defined the nouns.

ISA-88 and ISA-95 define the manufacturing vocabulary. ISA-88, as IEC 61512-1, supplies batch, recipe, procedure, unit, equipment module, and phase, and its governing principle is the separation of recipe procedural elements from equipment procedural elements. ISA-95, as IEC 62264, supplies the equipment hierarchy, material, personnel, process segment, and work order.

ISA-95 Part 7, the Alias Service Model, addresses equivalent identifiers and their context across manufacturing and other applications. Section 1 of ISA's public preview separates that exchange mechanism from system ownership and namespace lifecycle management. Defining the mapping service does not assign responsibility for maintaining each operation's mappings.

Allotrope publishes an ontology suite aligned at its upper layer with the Basic Formal Ontology, modeling equipment, material, process, and results, along with the Allotrope Data Format and a lighter JSON-based model.

ISO IDMP supplies identification standards for substances, dose forms, units of measurement, medicinal products, and pharmaceutical products.

GS1 supplies supply-chain identification keys and EPCIS, ratified as an ISO standard, which models visibility events as what, when, where, why, and how.

W3C supplies RDF, OWL 2, SKOS, SPARQL, and PROV-O.

Pistoia Alliance maintains an IDMP Ontology released publicly under an open license, with pharmaceutical organizations named among its supporters.

A plant can reuse published definitions for equipment, materials, and processes, then map its own names and records to them. Defining operational context then requires bringing in the part specific to one operation: which of its systems hold which entities, and under which names.

What regulators already expect

Existing data integrity guidance already addresses context and metadata. The proposed ontology architecture below is one way to support the expectations of the current Annex 11 revision draft.

The MHRA's data integrity guidance, published in March 2018, defines metadata as data that describes the attributes of other data and supplies context and meaning, and names audit trails as an example. A regulator has already said, in plain language, that a value without its context is not a complete record.

PIC/S PI 041-1, which entered into force on July 1, 2021, sets out ALCOA and its four additions. Two of them bear directly here. Complete requires that all information needed to recreate an event be retained, including relevant metadata. Consistent requires that records be created, processed, and stored in a logical, defined way, including standard date formats, units, and rounding. Extending consistency from units to identifiers and terms is a difference of degree rather than of kind.

The draft revision of EU GMP Annex 11 is more specific still. It asks for documented traceability between requirements, design, and testing. It asks that routine transfer of critical data between systems rest on validated interfaces rather than manual transcription. On the migration of critical data, it asks that constraints on both the sending and the receiving side be considered. That provision can support assessment of semantic mismatch during migration; this is an implementation implication, not an express requirement to build an ontology.

How to tell whether context is working

Four tests for checking a context layer.

Ask what a value's source is, and watch what happens. A result should resolve to the document, page, field, or system record it came from, in one step. If the answer is a table name, the grounding is incomplete.

Ask who owns the mapping. For a given entity, ask which identifiers in which systems have been declared equivalent, where that declaration lives, who approved it, and how it is versioned. Mappings need an owner, version history, and review, whether they are held in query code or a separate record.

Ask what happens to a term whose meaning changes. The right answer is a new identifier and a preserved old one, so historical results still mean what they meant.

Ask what’s missing. A context layer that only returns what it found is less useful than one that reports what it expected and could not locate. Missing evidence is a finding.

A last distinction worth holding onto. Connecting systems is not the same as migrating out of them, and the two have different consequences. The Context Layer approach keeps customer systems as the source of truth and holds pointers back to them, which means the records stay where their owners and their validation already are.