Governing the Model: Versioning, Change Control, and Ontology Stewardship

📍 Where we are: Part VII · Maintenance, Publication & FAIR — the phase that keeps the model trustworthy after it is built. 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.

The simple version

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 — the Good-practice (GxP: GMP, GLP, and the rest of the "Good x Practice" regulated-quality regime that governs pharmaceutical work) validation and change-control envelope — open standards leave for you to build. We dissect one ontology change, assemble the mechanisms into a go/no-go release gate for a new edition of the model, 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 IV's identifier discipline: an IRI (the permanent web identifier for a concept), 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 owl:deprecated "true"^^xsd:boolean (and, for a class, type it owl:DeprecatedClass — owl:DeprecatedProperty for a property) with a skos:historyNote (or skos:changeNote / skos:editorialNote) explaining the retirement, and point at its replacement with bp:replacedBy, leaving it resolvable. (SKOS, note, has no deprecation flag of its own — there is no skos:deprecated term — so a SKOS concept scheme retires a concept the same way, with a skos:historyNote and a status convention.) One subtlety the reasoner forces on you: owl:deprecated is an annotation. A description-logic reasoner ignores it entirely — a deprecated class still classifies individuals exactly as before — so deprecation is a signal to editors, docs, and CI, not a change to the logic. That is the chapter's whole thesis in miniature: governance is the discipline around the logic, not inside it. 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. And in this plant the stakes are not only archival but operational: the same bp: IRIs are the targets the historian, MES-recipe, and LIMS-result loaders bind to — the running example's historian_to_rdf.py, opcua_to_rdf.py, and b2mml_to_rdf.py map live tags, setpoints, and batch records onto exactly these terms. Re-mean or delete bp:monomerPct and you do not just orphan an old record; you silently break the mapping that ingests today's batch — a data-integrity event in flight, not a dusty 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 third 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.1.0" ;
    owl:versionIRI <https://example.org/bioproc/2.1.0> ;
    owl:priorVersion <https://example.org/bioproc/2.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. v2.1.0 added the 'from the wire to the graph' boundary: unit-bearing QUDT QuantityValues on the realized setpoints, the ISA-95 equipment hierarchy, the IEC 63278 Asset Administration Shell of the vessel, and the ISO IDMP substance identity — with OPC UA / B2MML / ASM source artifacts mapped in by the standalone scripts. 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 2.0.0 edition it superseded — which in turn grew out of the original 1.0.0. The comment narrates two bumps. The 1.0.0 → 2.0.0 bump was the major one: the running example grew 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 — a deep enough change to justify a new major edition. The 2.0.0 → 2.1.0 bump was a minor one: it added the from-the-wire-to-the-graph boundary — unit-bearing QUDT quantity values on the realized setpoints, the ISA-95 equipment hierarchy, the IEC 63278 Asset Administration Shell, the ISO IDMP substance identity, with OPC UA / B2MML / ASM source artifacts mapped in — without breaking or removing any prior term, which is exactly what earns a minor rather than a major bump. Because each step was a bump rather than an overwrite, every prior edition is still named and still resolvable. A retired term, similarly, is marked owl:deprecated "true"^^xsd:boolean (typed owl:DeprecatedClass) with a skos:historyNote and a bp:replacedBy 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 (the ontology's own structural model) 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 — and re-typed from a reified purity class (a standalone quality individual the lot bears) to a scalar datatype property (a plain numeric literal on the lot) — by bp:monomerPct, the form 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.

Worth saying where these governance terms live: they are not a bolt-on. bp:ChangeProposal, bp:ImpactAssessment, bp:ChangeApproval, and bp:Signature are all rdfs:subClassOf bp:InformationArtifact — they sit under the same information-content-entity branch (a BFO generically dependent continuant / IAO information content entity) as a spec or a result, which is exactly right: a change record is information about the process, not a part of it. And the relation that ties the paper trail together, bp:isAbout, is aligned upward in align.ttl as rdfs:subPropertyOf obo:IAO_0000136 (IAO 'is about'), so the change log inherits the same continuant/occurrent discipline as the rest of the model. The paper trail also closes a loop the book opened in Part VI: an impact assessment's central question — what queries does this term touch? — is exactly what the 23 competency questions answer mechanically. A disciplined change process therefore ends by re-running the acceptance suite (validate.py over cq-catalog.json) and confirming every CQ still PASSes before the version is bumped and the approval signed; the suite is the model's regression test under change control.

The worked case is deliberate: CHG-2026-014 is the chapter's example not because it is the largest change but because it exercises every governance mechanism at once — a retirement (so you see deprecate-don't-delete), a re-typing (a reified class becoming a scalar property), and a touch on the registered release spec (so reportability and the acceptance suite both come into play). A pure addition would never show the deprecation half; a cosmetic rename would never reach the regulator. This one change therefore makes the whole procedure visible on a single example.

How CHG-2026-014 was governed. The change record is not narrated prose; it is the literal sequence a governed model follows, and it is worth walking once on this concrete change so the procedure is reproducible on the next one:

1. Propose and justify. Mint a bp:ChangeProposal (bp:CHG-2026-014) and state what it does and why — re-type the reified bp:monomerPurity alias to the scalar datatype property bp:monomerPct and add the full release CQA panel — with the proposal bp:isAbout the artifact it changes, here bp:Spec-DS-mAb-A. The proposal exists before any term is touched.
2. Impact-assess. Mint a bp:ImpactAssessment (bp:IA-2026-014) bp:isAbout the proposal, and answer its one central question — what does this term touch? — over records, the SHACL release shapes, and the queries. That question is not answered by hand: it is exactly what the 23 competency questions answer mechanically, so the impact assessment is anchored by re-running them.
3. Run the acceptance suite — it must stay green. Execute validate.py over cq-catalog.json and confirm every CQ still PASSes against the changed model. The release-gate question CQ-08 is the one this change must not break; if even one CQ regresses, the proposal is reworked, not bumped. The suite is the regression test under change control.
4. Deprecate, don't delete. Retire the old term in place: mark bp:monomerPurity owl:deprecated true (typed owl:DeprecatedClass), record a skos:historyNote, and point obo:IAO_0100001 / bp:replacedBy at bp:monomerPct so the obsolete IRI still resolves and says where the meaning went.
5. Version and changelog. Because this touched the release panel and a term's form, it earns at least a major bump: stamp owl:versionInfo "2.0.0", pin the new owl:versionIRI, link owl:priorVersion back to the edition it superseded, and narrate the change in the ontology rdfs:comment. A change that removed or re-meant nothing — like the later 2.1.0 wire-to-graph addition — would earn only a minor bump; SemVer encodes whether anything broke (semantic versioning numbers a release MAJOR.MINOR.PATCH: a breaking change — something removed or re-meant — increments MAJOR, a backward-compatible addition increments MINOR, and a fix that changes no meaning increments PATCH).
6. Approve and sign. Mint a bp:ChangeApproval (bp:CA-2026-014) bp:approvedBy bp:SIG-steward — the named, accountable sign-off that, at OBO or IOF scale, would be a standing council's. Only then is the change effective.

Steps 1, 2, 4, and 6 are the triples printed in the snippet above; steps 3 and 5 are the gates around them. The point is that the paper trail and the procedure are the same sequence — read the triples top to bottom and you are reading the governance steps in order.

Two facts about this change matter to anyone who has sat on a change-control board. First, look at what it is about: bp:CHG-2026-014 is bp:isAbout bp:Spec-DS-mAb-A — it touches the drug-substance release specification. A change to a registered release spec is never a purely internal act; depending on its nature it is a reportable change to the health authority — an FDA prior-approval supplement or annual report, an EU variation — assessed under the product's ICH Q12 lifecycle-management framework against the established conditions in the file [4]. So a governed ontology has to answer a question a wiki cannot: which of these model changes are reportable, and to whom? The impact assessment that names the release spec, the SHACL shapes, and the queries a term touches is the same artifact a regulatory-affairs reviewer needs to scope a filing. Second, a change like adding a CQA (critical quality attribute — a measured property like monomer purity that the release spec sets a limit on) to the panel almost always rides on a comparability judgement: when the process changes across a tech transfer — the running example's transfer to site B, with its engineering run and PPQ confirmation run — the meaning of each CQA must stay fixed so pre- and post-change lots remain comparable under ICH Q5E [5]. That stability of meaning across a process change is the deepest reason for deprecate, don't delete: a CQA whose IRI silently re-meant itself would make a decade of comparability data incommensurable overnight.

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. In the running example that council role shrinks to one named signature: bp:CA-2026-014 is bp:approvedBy bp:SIG-steward, the local steward's electronic sign-off on the change. It is deliberately small — one signature standing in for what, at OBO or IOF scale, is a standing committee — but it makes the point that governance has to resolve, in the end, to a person who is accountable, not a process diagram.

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 ontology release gate: a go/no-go before you cut a version

The drug-product release gate decides whether a lot may ship; the ontology has a release gate of its own that decides whether a new edition of the model may ship. It is the same idea one level up, and almost everything this book built supplies one line of its checklist. Before an owl:versionIRI is minted and a steward signs the bp:ChangeApproval, a governed project runs a go/no-go review — not prose an editor remembers to apply, but a checklist whose every line has a runnable or recorded piece of evidence behind it.

Gate	What it checks	Evidence / artifact	Pass condition
Acceptance suite green	Every competency question still answers correctly against the changed model	validate.py over cq-catalog.json (the 23 CQs)	23/23 PASS; the suite exits zero and gates the build
Pitfall scan clean	No modeling anti-pattern was reintroduced	the OOPS! pitfall scan plus the biopharma anti-pattern checks (CQ-14, CQ-19, CQ-23)	no critical/important pitfall; the anti-pattern CQs PASS
Identity permanence	No IRI was deleted or silently re-meant	the diff of bioproc.ttl; every retirement is an owl:deprecated + bp:replacedBy	deprecate-don't-delete honored; no orphaned reference
Version pinned	The edition is named and linked to its predecessor	owl:versionInfo, owl:versionIRI, owl:priorVersion	present and SemVer-correct (a major bump if anything broke)
Impact + reportability scoped	What the change touches — records, shapes, queries — and whether it is a reportable regulatory change	the bp:ImpactAssessment, anchored by the CQ re-run	assessment recorded; any ICH Q12 filing scoped
FAIR acceptable	The published edition is still Findable, Accessible, Interoperable, Reusable	the FAIR scorecard	no regression against the last edition's score
Signed off	A named, accountable person approved the release	bp:ChangeApproval bp:approvedBy bp:SIG-steward	signature present (a standing council's, at OBO/IOF scale)

Only when every line clears is the version effective. Two honesties survive the gate, exactly as they do for a lot. First, like the SHACL release gate, this checklist proves the edition is complete and well-formed, not that its modeling decisions are correct — a green suite cannot tell you a newly-added axiom describes reality, only that it broke nothing the suite tests, the same consistent-is-not-correct limit one level up. Second, the gate is necessary, not sufficient: the honest verdict that closes the book still applies, because a passed gate on an ungoverned team decays the moment someone skips it under deadline. The release gate is where the ontology earns the right to be relied on for another edition; the discipline to run it every time is the governance the next section admits no tool can supply.

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.

The same governance, two evolving artifacts: the ontology and the learning model

That parallel is worth drawing all the way out, because the companion ML book reaches the identical resolution from the other direction, and the two disciplines turn out to be the same pattern wearing two coats. A statistical model in a GMP plant cannot be allowed to learn freely either: the answer the industry and regulators converged on is the locked model governed by a PCCP (a Predetermined Change Control Plan — a pre-approved written specification of how a model may be retrained, against what acceptance criteria, with a rollback if it fails), so a retrain is a planned, documented event rather than a silent drift. Lay the two side by side and the mapping is exact: owl:versionIRI plus deprecate-don't-delete is to an evolving ontology what the locked model plus its PCCP is to an evolving predictor — both pin a frozen, named edition, both forbid the in-place overwrite, both make every change a controlled act with a signed record. The CQ acceptance suite re-run on every change (step 3 above) is, in MLOps terms, the ontology's regression test, exactly as a locked model is re-scored against its held-out gate before a new version is promoted [3]. Governance here is not two problems but one, applied to two artifacts that both refuse to hold still.

When the graph is the model's ground truth, an ontology change is a data change

The deeper tie runs the other way: in the AI frontier, this governed graph is the ground truth an ML system stands on — the SHACL-validated, version-pinned substrate a retrieval-augmented model is grounded against, and increasingly the labeled instance set a model learns from. That reframes an ontology bump as a problem for everything downstream of it. Re-typing bp:monomerPurity from a reified class to the scalar bp:monomerPct does not just retire an IRI; it changes the feature contract of any model trained over the graph, so a governed change must propagate into the model's own change control — a model card pinned to owl:versionIRI 2.0.0 is now stale, and a retrieval prompt that walked the old shape silently retrieves nothing. The honest test of a model learning over these instances is also constrained by the same lineage the ontology makes explicit: because the graph's records are grouped by batch (every value bp:derivedFrom its BATCH-2026-001 lineage), an evaluation that splits rows at random leaks one batch's character across the train/test divide and flatters the score, so learning over the instances demands a leave-one-batch-out (grouped) cross-validation, the ML book's batch-grouped split — the ontology's genealogy spine is what makes that grouping computable in the first place. And the validation paradox sharpens at the boundary: a reasoned graph carries a logical guarantee a learned model never can — a SHACL-conformant release subgraph is provably complete and well-typed, where a model's accuracy is only ever an estimate on the batches it happened to see. The governance this chapter demands is therefore not merely analogous to MLOps; it is the layer that makes the downstream model trustworthy at all, because a model grounded in an ungoverned graph inherits every drift the graph was allowed to accumulate — and states it back, fluently, as fact.

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.

One discipline the open standards never mention is periodic review. In a GxP quality system the control strategy and its controlled documents are re-confirmed on a schedule, not only when something changes — and an ontology that is the plant's controlled vocabulary inherits that duty. When continued-process-verification trending shifts a normal operating range, or a new resin vendor or cell-line subclone enters the process, someone must re-ask whether the model still describes the as-running plant or has quietly fallen behind it. The governance loop is therefore two loops: the event-driven change this chapter dissected, and a scheduled review that catches the drift no one filed a change for. A model that is never periodically re-confirmed against the floor is exactly the confident liar the chapter warns about — it just takes longer to notice.

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.
• Locked model + PCCP — the ML governance pattern (a frozen model plus a Predetermined Change Control Plan for how it may be retrained) that mirrors the ontology's owl:versionIRI plus deprecate-don't-delete: both pin a named edition and make every change a controlled, signed act.
• Ontology change as a data change — the principle that when a governed graph is a model's ground truth, re-typing or deprecating a term alters the downstream model's feature contract, so the bump must propagate into the model's own change control and trigger leave-one-batch-out re-validation.
• Ontology release gate — the go/no-go review that clears a new edition of the model to ship: the 23-CQ acceptance suite green, the OOPS!/anti-pattern scan clean, no IRI deleted or re-meant, the version pinned, impact and reportability scoped, the FAIR scorecard non-regressed, and a signed bp:ChangeApproval — the drug-product release gate's discipline applied to the model itself.

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, Maintenance: Publication, the Assembled Thread, and FAIR, 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.