Governing the Model: Versioning, Change Control, and Ontology Stewardship
📍 Where we are: Part VI · The Whole Graph — Chapter 22. The digital thread is powerful and, we admitted, prone to drift. This chapter is about keeping the model true over years — the governance that turns a clever graph into a trustworthy, maintained system.
The previous chapter ended on a warning: a graph is a derived view that drifts unless it is governed, and a model is only as trustworthy as the discipline maintaining it. That warning has echoed since Part I — consistent is not correct, validated is not measured, a model is a practice not an artifact. This chapter confronts the practice directly. An ontology in a regulated setting is not a file you write once; it is a controlled asset that must be versioned, changed under control, and stewarded across a product lifespan that can run for decades. Getting that governance right is what separates a model you can stake a release on from one that quietly rots.
A dictionary is not finished the day it is printed — language changes, and a good dictionary is maintained: new words added, old ones marked archaic (never silently deleted, or every book that used them breaks), every edition dated and tracked. An ontology is a dictionary for your process, and it needs the same stewardship: a process for proposing changes, a rule never to break old meanings, a version on every release, and a keeper responsible for it. This chapter is about being a good dictionary-keeper — because in regulated manufacturing, a meaning that silently changes is a record that silently lies.
What this chapter covers
We treat the ontology as a controlled artifact: versioned, change-controlled, and stewarded. We cover the cardinal rule of deprecate, don't delete (IRI permanence), the council-governance model the field uses, single-source authoring with LinkML so downstream schemas cannot drift, and the GxP wrapper open standards leave for you to build. We dissect one ontology change, and close on the honest truth that governance is a social problem technology only supports.
Deprecate, never delete: the permanence of meaning
The first rule of ontology governance follows directly from Part I's identifier discipline: an IRI, once issued, is permanent. If bp:monomerPct ever meant something, that IRI must keep meaning it forever, because records, results, and released lots refer to it. When a concept is superseded, you do not delete its IRI — you deprecate it (mark it obsolete, point to its replacement with an annotation like owl:deprecated or skos:deprecated and a replacedBy link) and leave it resolvable. Deleting an IRI is the ontology equivalent of shredding the page every old record cites: the historical data still points there, and now points at nothing. This is why ontologies grow and annotate rather than overwrite, and why a ten-year-old batch record can still be interpreted against the vocabulary it was authored in. Permanence of meaning is not pedantry; in a regulated archive it is the difference between a legible record and an orphaned one.
This is why the vocabulary itself is stamped as a versioned, controlled artifact. The running example's bp: vocabulary opens with an ontology declaration carrying a owl:versionInfo string, the single most basic act of governance — every load knows exactly which edition of the meanings it was reasoned against. This file is now on its second edition, and the declaration shows the full change-control vocabulary in use, not just the floor:
# bioproc.ttl
bp: a owl:Ontology ;
rdfs:label "Bioprocess running-example vocabulary" ;
owl:versionInfo "2.0.0" ;
owl:versionIRI <https://example.org/bioproc/2.0.0> ;
owl:priorVersion <https://example.org/bioproc/1.0.0> ;
rdfs:comment "Local vocabulary for a CHO mAb process modeled end to end; aligns up to BFO/IOF/AFO/OBI/QUDT/RO/PROV in align.ttl. v2.0.0 grew the v1.0.0 genealogy-spine model to real-world depth across every unit operation, the full release CQA panel, serialization, and distribution. See the governance chapter for the change record." .
A version string alone is the floor, not the discipline, and this declaration shows the rest of the OWL change-control vocabulary doing real work: owl:versionIRI pins this edition's permanent address, and owl:priorVersion links it back to the 1.0.0 edition it superseded. That 1.0.0 → 2.0.0 bump is the whole running example growing from its genealogy spine to real-world depth — every unit operation given its material and process, the full release panel modeled, serialization and distribution added — and because it was a bump rather than an overwrite, the prior edition is still named and still resolvable. A retired term, similarly, is annotated owl:deprecated (or skos:deprecated) with a pointer to its replacement rather than removed; the worked example of that is below.
Change control and council governance
A change to the model is a change to how the plant is described, and in a GxP setting that is a controlled act, not a quiet edit in a file [3]. A governed ontology has a change process: a proposal, an impact assessment (what records, shapes, and queries does this term touch?), review by people who understand both the domain and the model, a version bump, and a record of why. This is the data-governance discipline applied to the schema itself — the same rigor the axioms chapter said an axiom deserves, because an axiom is a decision about reality.
The running example carries one such change as actual triples — the very 2.0.0 bump above, recorded the way a GxP change must be. An old alias class, bp:monomerPurity, was superseded by the datatype property bp:monomerPct that the release gate now checks; rather than being deleted, it is marked obsolete and pointed at its replacement, and the change itself is captured as a proposal, an impact assessment, and a signed approval:
# instances.ttl — a worked, change-controlled deprecation (deprecate, don't delete)
bp:monomerPurity a owl:DeprecatedClass ; rdfs:label "SEC monomer purity (DEPRECATED alias)" ;
owl:deprecated true ;
obo:IAO_0100001 bp:monomerPct ; # IAO 'term replaced by'
bp:replacedBy bp:monomerPct ;
skos:historyNote "Deprecated in v2.0.0; superseded by the datatype property bp:monomerPct. Never silently overwritten — see the change record below." .
bp:CHG-2026-014 a bp:ChangeProposal ; rdfs:label "change proposal: add full release CQA panel + serialization (v2.0.0)" ;
bp:isAbout bp:Spec-DS-mAb-A .
bp:IA-2026-014 a bp:ImpactAssessment ; rdfs:label "impact assessment for CHG-2026-014" ;
bp:isAbout bp:CHG-2026-014 .
bp:CA-2026-014 a bp:ChangeApproval ; rdfs:label "change approval record for CHG-2026-014" ;
bp:isAbout bp:CHG-2026-014 ; bp:approvedBy bp:SIG-steward .
Note the two annotations that make the deprecation safe: obo:IAO_0100001 (the OBO "term replaced by" relation, reused here so the link is a standard one, not a private convention) and the local bp:replacedBy aligned to it by intent. A query or a person landing on the obsolete IRI is told exactly where the meaning went, and the historical record that cited bp:monomerPurity still resolves. The ChangeProposal / ImpactAssessment / ChangeApproval triple is the paper trail — what changed, what it touched, and who signed it off — modeled as first-class information artifacts rather than left in a wiki.
At industry scale, the model that works is council governance, proven by the OBO Foundry and adopted by the IOF and its biopharma (BMIC) groups: a shared vocabulary is stewarded by a council against published design principles, so no single person or vendor owns the meaning and changes are coordinated across everyone who depends on them [2]. This is what lets a shared ontology stay shared — the alternative, every site forking its own copy, is the ontology sprawl that destroys the cross-site interoperability that justified the ontology in the first place.
Single-source authoring: stop the schemas from drifting
A subtle governance failure is internal drift: the same Batch concept is written as an OWL class, a SHACL release shape, a relational table, and a JSON schema — four files, four chances to diverge the next time someone edits one and forgets the others. The open-source book's answer is LinkML: author the model once in YAML and generate the SHACL, JSON Schema, SQL DDL, OWL, and typed classes from it, so all of them are regenerated from one governed source under change control rather than hand-maintained [1]. Single-source authoring turns "keep four schemas in sync" — a discipline humans reliably fail — into "regenerate from the source," a build step. It is the most practical governance tool in the chapter: it makes the consistent part of correctness automatic, leaving human review for the part only humans can do.
One change, governed: proposed with an impact assessment, applied by deprecating rather than deleting, versioned and changelogged, regenerated from a single LinkML source, and signed off under change control — the opposite of the silent edit that makes a model drift.
Original diagram by the authors, created with AI assistance.
The unsolved part: governance is a social problem, and the GxP wrapper is yours to build
The honest difficulty is that none of this is a technology problem, and technology cannot solve it for you. Deprecation, versioning, and LinkML generation are mechanisms; whether anyone follows the change process, staffs the stewardship role, and resists the temptation to fork the shared vocabulary is an organizational and cultural question. The OBO Foundry's success is often misread as a technical achievement when it is mostly a governance achievement — a community that agreed to coordinate, sustained over years. Most ontology projects fail not because the OWL was wrong but because no one owned it, the change process was skipped under deadline pressure, and the model drifted from the plant it described until no one trusted it. There is no reasoner for organizational discipline.
The second gap is the one the open-source book is blunt about: open standards give you a clean engine, not a validated system. RDF, OWL, SHACL, and LinkML are mature and free, but a GxP-validated ontology — change-controlled per GAMP, with the load qualified as complete and correct, supplier accountability for the triplestore, and the whole lifecycle audit-trailed — is a wrapper you build or buy, not a feature you import [3]. And validating a thing that is meant to evolve strains traditional one-time validation the same way a learning model does: every model change is a new validated object, and the validation never quite ends. So the standard this chapter sets is sober and central to the whole book: the model's correctness over time is a governed human practice that open standards support but do not supply, and an ungoverned ontology — however elegant — is a liability that drifts into a confident liar. Governance is not the boring appendix to the technology; it is the thing that makes the technology trustworthy.
Why it matters
Every guarantee this book offered — queryable lineage, enforceable release, interoperable meaning — silently assumed the model stays true, and that assumption is only as good as the governance behind it. Version and deprecate properly and a decade-old record stays legible; change under control and the model never silently lies; author from a single source and the schemas cannot drift apart; steward by council and the shared vocabulary stays shared. Skip the governance and the most sophisticated graph in the plant becomes untrustworthy faster than a spreadsheet, because its confident structure hides its rot. Governance is where the model earns the right to be relied on, which is why a regulated setting demands it as much as it demands the data integrity beneath it.
In the real world
Council-governed ontologies are a proven model — the OBO Foundry has coordinated biomedical ontologies for nearly two decades, and the IOF and its biopharma council apply the same discipline to manufacturing [2]. LinkML is in production at major data-coordination efforts, generating downstream schemas from one source [1]. And computerized-system validation under GAMP 5 is the established framework regulated manufacturers already apply to software — extending it to cover the ontology and its loads is the live frontier [3]. What no standard hands you is the will to govern: the staffed stewardship, the enforced change process, the resisted fork. That is a management commitment, and it is the single best predictor of whether a plant's ontology is an asset in five years or an abandoned graph no one trusts.
Key terms
- Deprecate, don't delete — the rule that an IRI, once issued, is never removed but marked obsolete and pointed at its replacement, so historical records stay interpretable.
- Change control (of the model) — treating an ontology change as a proposed, impact-assessed, reviewed, versioned, signed act, not a silent file edit.
- Council governance — stewarding a shared vocabulary by a coordinating body against published principles (OBO Foundry, IOF, BMIC), so no one owns the meaning and changes stay coordinated.
- Single-source authoring (LinkML) — modeling once in YAML and generating SHACL, JSON Schema, SQL, and OWL from it, so downstream schemas regenerate rather than drift.
- GxP wrapper — the validated, change-controlled, qualified system around the open-standard engine; built or bought, never imported.
- Governance as a social problem — the recognition that deprecation, versioning, and generation are mechanisms, while ownership, discipline, and resisting forks are organizational commitments no technology supplies.
Where this leads
We can govern the model so it stays true. But "true to the plant" is not the same as "useful to the world" — a perfectly governed graph can still fail the goal that justified it. The next chapter, FAIR in Practice: Measuring Whether the Graph Actually Delivers, turns the FAIR principles from an aspiration into a measurement, asks whether the graph is genuinely Findable, Accessible, Interoperable, and Reusable, and confronts the uncomfortable, well-documented gap between standards-compliance and FAIRness in fact.