The Honest Verdict: Open Source vs Commercial

📍 Where we are: the last chapter before the references. The stack is built, the capstone batch has flowed end to end, and now we add up the bill — honestly. Where did pure open source win, where did it fall short, and how do you write that decision down so the next engineer (or the next auditor) understands why?

The whole book has been one long argument that you can build most of a bioprocess data platform in open source, on a laptop, against a deterministic simulated fed-batch CHO + Protein A monoclonal-antibody (mAb) line — a CHO (Chinese Hamster Ovary) cell culture grown in fed-batch mode (nutrients fed in over days) that secretes a mAb (a therapeutic antibody protein) later purified on a Protein A capture column. The companion repo proves the runnable half: clone it, type a handful of make targets, and the historian (the time-series database that records every measurement) fills, the batches contextualize (raw tags get linked to the batch and equipment they belong to), the audit chain verifies, and the soft-sensor (a model that infers a hard-to-measure quantity from easy-to-measure signals) trains. But "you can build it" was never the same claim as "you should build all of it." This chapter is the reckoning. It is deliberately the least code-heavy chapter in the book, because the artifact it produces is a decision, not a service.

The simple version

Building a data platform is like building a house. You can pour the slab, frame the walls, run the plumbing, and wire the lights yourself — open source hands you genuinely excellent, free materials for all of that. But when the building inspector signs the occupancy permit, you are on the hook, not the lumber yard. For the rooms the inspector cares about most — the ones that hold the legal record of what you made and shipped — most people hire a licensed contractor who carries insurance and signs their name to the work. This chapter is the honest scorecard of which rooms you frame yourself and which you contract out, plus a one-page form for writing down why you chose what you chose.

What this chapter covers

• A layer-by-layer scorecard of what the pure open-source stack we built genuinely delivers, and where commercial or hybrid is the responsible choice.
• The hidden costs the price tag never shows: validation burden, supply-chain ownership, and vendor accountability.
• A build-vs-buy decision framework and an Architecture Decision Record (ADR) template you can paste into your own repo.
• A reference "honest hybrid" target architecture — the shape a real facility actually ships.

The scorecard: what we actually built, and what it actually cost

Every chapter in this book turned on one more layer of the same stack and then told you, plainly, where that layer stopped being enough. Collect those verdicts in one place and a pattern appears. Open source wins decisively at the bottom and the middle of the stack — the layered architecture, read from the plant floor at the bottom up to analytics at the top: connectivity, ingestion, historization, contextualization, semantics, analytics — and the score tilts toward commercial or hybrid exactly where the validated GMP record of truth lives.

Here is the honest scorecard, layer by layer. The OSS tools and their pins are the real ones from the running stack defined in examples/platform/compose/compose.yaml; the verdicts are the ones the earlier chapters earned.

Layer	OSS tool in this book	Pure-OSS verdict	Where commercial / hybrid wins
Edge connectivity	OPC UA (asyncua)	Wins. Mature, standards-based, free.	Vendor driver certification; the many field devices (the instruments and controllers on the plant floor) that mis-handle OPC UA security, the part most deployments skip.
Message bus	MQTT + Sparkplug B (eclipse-mosquitto:2.0.22)	Wins. Light, ubiquitous, broker-agnostic.	Brokered HA clusters with vendor SLAs.
Historian / TSDB (time-series database)	TimescaleDB (timescale/timescaledb:2.17.2-pg17)	Wins for capture & query.	HA (high availability), compression at PB (petabyte) scale, and 30-year retention SLAs (service-level agreements) — the Timescale License (TSL) commercial tier.
Batch & equipment model	PostgreSQL (the ISA-88/95 batch and equipment standards — see Batch & Equipment Model) — same timescale/timescaledb:2.17.2-pg17 container as the historian	Wins. A relational join backbone is a relational join backbone.	A validated, configurable MES (Manufacturing Execution System) product.
Contextualization	SQL views	Wins. This is just good schema design.	—
Semantics / digital thread	RDF / SPARQL (apache/jena-fuseki:5.2.0)	Wins. Open standards (RDF triples plus the SPARQL query language) beat any proprietary graph here — see Semantics & the Knowledge Graph.	Managed graph + ontology curation services.
Visualization	Grafana (grafana/grafana-oss:11.4.0)	Wins for local use.	AGPL redistribution/SaaS triggers obligations; commercial dashboards bundle support.
Compliance / record of truth	Postgres audit + hash chain (each record cryptographically linked to the previous one, so any later change is detectable)	Partial. Detectable, not tamper-proof — it reveals tampering but cannot prevent it.	Commercial/hybrid. Validated MES / eQMS (electronic Quality Management System), qualified e-signatures, vendor accountability.
Analytics / soft-sensor	Python (scikit-learn PLS)	Wins. The science is open.	Validated modelling platforms for release-impacting models.

The two easy rows: where open source simply wins

The two analytics rows are the cleanest "OSS wins." When we trained the Raman-to-titer soft-sensor in examples/analytics/soft_sensor.py — a PLS (Partial Least Squares) model that predicts titer (the antibody concentration in the culture, in grams per litre) from an in-line Raman spectrum (a light-scattering measurement that reports which molecular bonds are present) — the open stack did not merely run; it produced a genuinely useful model. R² (how much of the variation the model explains, where 1.0 is perfect) came out near 1, and RMSE (the typical prediction error, in g/L) came out small:

PLS soft-sensor (titer from Raman): R2=0.9923 RMSE=0.1498 g/L (6 comps, 701 wavenumbers, 235 train / 101 test)
ASSERT ok: R2 > 0.85 — the Raman dataset is genuinely predictive of titer.

scikit-learn (BSD-licensed) gave us an R² of 0.99 on a within-batch hold-out split (not field accuracy — proper leave-one-batch-out validation and applicability-domain limits are covered in Process Analytics: SPC, MVDA & Soft Sensors), for nothing — the in-line Raman spectrum tracks the same molecular bands that report rising antibody concentration as titer climbs from ~0 to several g/L over the fed-batch, which is why a PLS model recovers it with R²=0.99. There is no commercial PLS engine that would have done the chemometrics better. This is the side of the verdict where the answer is easy. Peer-reviewed surveys of "Bioprocessing 4.0" reach the same conclusion from the other direction: industry adoption of digital tools is held back far less by the availability of algorithms than by the absence of common standards and integration — exactly the gap an open, standards-based stack is good at closing [9].

But notice what that single number is not, because the gap between it and a release-grade model is exactly where the easy verdict turns hard. R²=0.99 came off a within-batch hold-out — train and test rows drawn from the same fed-batch runs — and within-batch siblings are not independent examples: every batch in this campaign descends from the same working cell bank, often sharing a media lot and a capture skid, so a row-wise random split lets a near-twin land on both sides of the line and the model effectively scores itself on data it has already seen. The honest discipline is a grouped split — leave-one-batch-out, every record from a batch wholly on one side — which is the GroupKFold/nested cross-validation default Book 5's models-and-validation chapter builds, and the genealogy a derivedFrom walk traces is the group key it splits on. A field-grade soft sensor also needs an applicability domain — a gate (a PLS Hotelling's T²/SPE pair, say) that declines to predict when a new batch sits outside the spectral envelope the model was trained on, so it refuses to guess out of its depth rather than extrapolate confidently [9]. And once deployed it needs the whole MLOps afterlife the process-drift discussion covers: a Raman calibration is bound to its exact probe (instrument-to-instrument differences alone moved a published cell-density prediction by roughly 20% until an explicit calibration transfer halved it), the living cells genuinely wander campaign to campaign (process drift, a real signal to preserve), and the predictor goes stale against that moving process (model drift, a defect to detect) — two distinct things a monitor must keep apart, the first via a label-free input-drift check (PSI) and the second only at the sparse offline grounding points. None of that lives in scikit-learn the library; it lives in the validated lifecycle around it. That is precisely the scorecard's distinction: the chemometrics is an OSS win, but a release-impacting model — one whose output can change a disposition — inherits the same validated-and-accountable bar as the record of truth, which is why the analytics row reads "wins" for engineering and monitoring and "validated modelling platform" for release.

The hard row is the compliance one, and it is hard for reasons the price tag never shows.

The hidden costs: validation burden, supply chain, accountability

A naive cost comparison says open source is free and commercial software is expensive. That comparison is wrong in both directions, and the chapter's whole point is why.

Validation burden does not disappear when the license fee does

No open-source component in this book ships as "21 CFR Part 11 compliant" (the FDA rule governing electronic records and electronic signatures), because compliance is a property of a validated system plus procedures, not of a download — a theme the preface set and every Trust chapter reinforced. GAMP 5 (the ISPE industry guidance for compliant GxP computerized systems), 2nd edition, is explicit that regulated firms (manufacturers bound by Good Manufacturing Practice) should maximize supplier involvement and leverage vendor documentation to reduce their own validation effort [1]. When you choose open source, there is no supplier to leverage — you are the supplier. You write the user requirements, the IQ/OQ/PQ (Installation, Operational, and Performance Qualification — see Validating an Open-Source Stack: GAMP 5 & CSA), the traceability matrix, the supplier assessment, all of it. The good news, the same direction GAMP 5 has been moving and the FDA's Computer Software Assurance (CSA) guidance pushes hard, is that this burden is risk-based: low-risk, non-record components can lean on automated testing and existing evidence rather than heavyweight documentation [2]. That is why this book made the test suite (make test) the validation evidence and pinned every image by tag, recording immutable sha256 digests in versions.lock (with one image, the relocated community Fuseki, flagged verify-before-use) — to make the assurance effort least-burdensome, not to make it vanish.

The supply chain you no longer pay a vendor to own

You inherit the supply chain you no longer pay a vendor to own. Choosing open source means choosing to manage third-party and supply-chain risk yourself. NIST's Secure Software Development Framework names the obligation directly: you must vet the components you reuse and express security requirements you would otherwise delegate to a vendor [6]. The 2026 reality — a compromised release of a widely-used container scanner earlier in the year — is a reminder that even your security tooling is part of the threat surface.

The open-source answer is transparency: a Software Bill of Materials gives you the supplier, component, and version visibility to own the record-of-truth without a vendor, while honestly documenting the maintenance you have just signed up for [7]. And the tooling for that is itself excellent open source — Syft generates an SBOM straight from a container image or filesystem [8]. The repo ships a make sbom target that runs Syft over every pinned compose image (see examples/Makefile); the command below is the single-image shape of what it does — run against the real historian image pinned in versions.lock, it inventories exactly what is running, by digest:

# The single-image shape of `make sbom`. Inventory the real historian/relational
# image — the accountability OSS *can* deliver.
syft timescale/timescaledb:2.17.2-pg17 -o spdx-json > sbom.spdx.json

An SBOM with the NTIA minimum elements — supplier, component name, version, unique identifier, dependency relationship, author, timestamp — is the open-source operator's substitute for "call the vendor": you can answer what is in my stack and where did it come from without anyone's permission [7].

Anatomy of an SBOM record: the operator's substitute for calling the vendor

That list of seven elements is abstract until you open the file Syft would write. The spdx-json output is one large JSON document describing the image as a graph of packages; pick out a single package entry — say the OpenSSL library the historian container links against — and every one of the seven NTIA minimum elements maps to a concrete JSON field. The dissection below is that one package, field by field. It is also the field-level mirror of the gov.supplier_register table the book builds in examples/platform/db/40-gov.sql — component, image, digest, license, gamp_category — generated, the comment says, from versions.lock, the same digest pins the SBOM inventories. The point of laying it out this way is to make the abstract obligation concrete: when a CVE (a Common Vulnerabilities and Exposures entry — a publicly published security flaw with a unique ID) drops against libssl3 (the OpenSSL cryptography library), the versionInfo and the PURL (Package URL — a standard string that names a package and its exact version) in this record are what let you answer am I affected in seconds, with no vendor on the phone.

One SPDX package entry, dissected against the seven NTIA minimum elements: the open-source operator's substitute for calling the vendor, grounded on the real digest pinned in versions.lock. Original diagram by the authors, created with AI assistance.

The values shown are representative of what Syft emits for a Debian-based image like timescale/timescaledb:2.17.2-pg17; the fields — name, versionInfo, supplier, externalRefs, relationships, creationInfo.creators, creationInfo.created — are exactly the SPDX 2.3 carriers the NTIA minimum elements require [7]. The make sbom target emits CycloneDX; the dissection here uses the equivalent SPDX 2.3 fields — both carry the seven NTIA minimum elements, which are format-agnostic. The accountability this delivers is real, but notice its shape: the SBOM tells you what and where from. It does not tell you who answers when it breaks — and that is the one cost open source structurally cannot supply.

Accountability is the cost that has no open-source substitute

When an inspector finds a data-integrity problem in your batch record, EU Annex 11 (the EU GMP rule for computerised systems) is unambiguous about who answers for it: there must be formal agreements with suppliers stating their responsibilities, the supplier must be assessed, and the regulated manufacturer remains ultimately responsible [3]. A commercial vendor signs that formal agreement and carries that responsibility contractually. An open-source project's license, by design, disclaims all warranty. For the record-of-truth itself — the data that FDA guidance requires to be reliable, accurate, attributable, with reviewed audit trails [4] — that missing accountability is precisely the factor that tilts a responsible build-vs-buy decision toward a validated, vendor-backed system.

This is exactly why our compliance layer is honest about its own limits. The ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate — plus enduring and available) audit chain in examples/platform/db/50-alcoa.sql is a beautiful, free mechanism — but read the comment at the top:

-- 50-alcoa.sql — ALCOA+ by construction (Chapters 20 & 21).
-- A generic, trigger-based audit trail: every INSERT/UPDATE/DELETE on a
-- registered table is appended to audit.change_log with who/what/when/old/new,
-- and each row is hash-chained to the previous one so tampering is *detectable*.
-- The book is explicit that a superuser who disables the trigger can still
-- bypass this — hash chaining makes tampering evident, not impossible.

make alcoa runs audit.verify_chain() and returns 0 broken links when the chain is intact. That is real, and it is worth having. But "detectable, not impossible" is the whole verdict in five words: the mechanism is open source; the compliance — the validated procedures, the change control, the accountable owner — is the hybrid last mile.

Field evidence: what an OSS LIMS gap analysis actually found

This is not an abstract worry; the evidence is published. SENAITE, the open-source LIMS this book used as a teaching system, is the cleanest documented case. The only public 21 CFR Part 11 gap analysis of SENAITE — version 1.3.2, dated 1 October 2019 and posted to the project's own community forum — walks the regulation requirement by requirement and finds the predictable open gaps: electronic-signature handling, audit-trail completeness, account identification and password controls, and data-retention enforcement are all flagged as work the implementer must still do, not properties the download already has [11]. That document is exactly the field-failure to keep in mind: it is six years old, written against a version long superseded, and authored by the community rather than an accredited assessor — so it tells you the direction of the gaps without being a current, defensible validation record. The lesson generalizes past SENAITE to every tool in the scorecard: an open-source project can be excellent software and still ship none of the validated procedures, signature controls, or retention enforcement that Part 11 demands. The gap analysis is the artifact that turns "we should validate this ourselves" from a slogan into a checklist — which is precisely the validation burden the earlier section said never disappears.

The build-vs-buy framework, and writing it down as an ADR

So how do you actually decide, layer by layer? The framework is one question asked four ways:

1. Does this layer touch the regulated control strategy or the record of truth? If a value flowing through it can change a release decision, the bar is "validated and accountable." If it is engineering, monitoring, or analytics downstream of the record, open source is usually the better buy. The A-Mab case study — the canonical fed-batch CHO + Protein A QbD (Quality by Design — building quality in by understanding the process rather than testing it in afterwards) reference grounded in the ICH Q8(R2)/Q9/Q10 guidelines (the international harmonized standards for pharmaceutical development, quality risk management, and the quality system) — is the map of which parameters are critical and therefore which parts of the stack inherit that bar [10]. Concretely, "the record of truth" is the disposition that hangs off the downstream purification train Book 1 walks: the Protein A capture pool's host-cell-protein clearance, the log-reduction value (LRV — the factors of ten a step removes a contaminant by) summed across the orthogonal viral-safety steps (viral inactivation and 20-nanometre viral filtration), the polishing step's aggregate clearance, and the final concentration and buffer of UF/DF. Each of those is a CQA whose acceptance limit decides release, so the system that holds and signs those results inherits the validated-and-accountable bar — while the historian that merely trends the in-process pressure on the same skid does not. The boundary is a unit-operation question before it is a software one.
2. What is the validation burden, and can CSA make it proportionate? A low-risk historian read-replica (a read-only copy of the database that other systems can query without ever writing to it) is cheap to assure; a system that captures the qualified electronic signature on a batch disposition is not [2]. The burden is concrete: a system on the regulated path earns the IQ/OQ/PQ ladder — installation qualification proves it was deployed to the specified version (which the tag-plus-digest pin in versions.lock gives you as machine-checkable evidence), operational qualification proves it behaves to spec across its range, and performance qualification proves the end-to-end behaviour reproduces a known result on real data — and any later change to the image digest, the schema, or the load job re-enters that ladder under change control rather than being hot-patched. And because a plant is not one site forever, the same evidence travels through tech transfer: when the stack moves from a development site to a commercial plant, or scales from a 10-litre development bioreactor to a 2000-litre production train, the validated artifacts re-qualify against the receiving site's systems rather than being re-invented — which is exactly why pinning by digest and modeling on open standards (so the IRIs and SHACL shapes travel unchanged) lowers the cost of the move CSA is trying to make proportionate.
3. Who carries accountability if it fails an inspection? If the honest answer is "no one but us, with no warranty," that is a real cost, not a free one [3].
4. What is the lock-in cost of the alternative? Open standards (OPC UA, MQTT/Sparkplug, ISA-88/95, RDF) are the strongest argument for OSS: they make every future migration cheaper, and an SBOM keeps the door open [7].

The bioprocessing literature frames the same fork as three execution paths: partner with system integrators, buy off-the-shelf, or develop in-house — and documents that low Industry 4.0 adoption and a lack of common standards are what make the choice hard [9]. A scorecard is not a sales pitch only if you record the reasoning. The discipline that turns an opinion into a defensible engineering decision is the Architecture Decision Record: a short, dated document capturing context, the decision, and its consequences [5]. Here is the template the repo recommends you commit beside the code it governs:

# ADR-0028: Build-vs-buy for the GMP record-of-truth
- Status: Accepted   Date: 2026-06-14
## Context
The fed-batch CHO + Protein A line needs a system of record for the
batch disposition. Open-source Postgres + audit hash chain makes
tampering *detectable* (make alcoa -> 0 broken links) but ships no
vendor accountability and is not Part 11-compliant out of the box.
## Decision
Use a VALIDATED commercial MES/eQMS for the signed record of truth.
Keep the OSS stack (TimescaleDB historian, contextualization, SPARQL
digital thread, PLS soft-sensor) as a read-mostly NOA (NAMUR Open
Architecture)-side layer.
## Consequences
+ Vendor carries the Annex 11 supplier agreement & accountability.
+ OSS layer stays cheap, fast to evolve, lock-in-resistant (open standards).
-  Two systems to reconcile; the OSS<->MES boundary must stay explicit.
-  We still own validation of the OSS layer (risk-based, CSA-leveraged).

The point of the ADR is not the verdict; it is that six months later, when someone asks "why didn't we just use Postgres for everything?", the answer is written down with its reasoning intact.

Anatomy of an ADR: writing the decision down so it survives the engineer

The template above is short on purpose, and every line in it is load-bearing. Michael Nygard's original formulation — the source of the ADR as an engineering artifact — is just a handful of named sections, each answering one question an auditor or a successor will eventually ask [5]. Read ADR-0028 field by field and the discipline becomes visible: the id is a stable, sortable handle you can cite forever; the status says whether this is a draft opinion or a live commitment; the date stamps when this reasoning was true, because context ages; the context states the forces before the verdict, so a reader can judge whether they still hold; the decision is the single choice the record commits to; and the consequences list the wins and the costs honestly, on purpose, so nobody later pretends the trade-off was free.

ADR-0028 dissected field by field — the slug, the status pill, the date, context, decision, the honest plus-and-minus consequences, and the supersedes linkage that lets a later decision retire this one without erasing it. Original diagram by the authors, created with AI assistance.

The field most engineers skip is the one that matters most under audit: the implicit supersedes / superseded-by linkage. An ADR is never edited in place — when the trade-off changes, you write a new ADR that supersedes the old one, and the old one stays in the repo with its date intact. That append-only habit is the same one the ALCOA+ audit chain enforces on data, applied to decisions: the record of why is as immutable as the record of what. A wiki page that anyone can quietly overwrite cannot do this; a dated file committed beside the code it governs can.

The verdict itself is a triple, and the boundary is a SHACL shape

The scorecard's central artifact — the OSS<->MES boundary the ADR draws in ink — is not just a Markdown table; it is something the digital-thread layer this book already built can carry as data. The semantics chapter modeled the plant in RDF, where every fact is a subject–predicate–object triple (the Resource Description Framework's atom) and the genealogy is a chain of derivedFrom edges — see Semantics & the Knowledge Graph. The build-vs-buy decision drops straight into the same graph: bp:DispositionRecord bp:governedBy bp:ADR-0028 and bp:DispositionRecord bp:ownedBy bp:ValidatedMES are two triples that record which layer owns the signed record, the same way the ontology book records that a released lot carries a signature attributed to a bp:QP-role (the upper spine, relations and genealogy). Stated as data, the boundary becomes machine-checkable.

That is what lets the scorecard's "validated and accountable" bar be enforced rather than remembered. In the ontology book the release specification is a closed-world SHACL gate (the Shapes Constraint Language — a W3C standard that validates a graph has the required structure): bp:ReleaseShape insists every released lot carries exactly one in-range value per CQA and an attributable bp:approvedBy signature, the 21 CFR Part 11 / Annex 11 condition, failing closed when any is missing — the release gate and SHACL. The boundary this chapter argues for falls out of one extra shape: a constraint that any node typed bp:DispositionRecord must be bp:ownedBy a validated, vendor-backed system, so a disposition wired to the bare OSS audit chain fails the gate exactly as a missing signature does. The discipline is the same one the ontology book runs as executable competency questions (CQ — a question the model must answer, paired with an expected result, run as a PASS/FAIL test): "is every signed disposition owned by an accountable system?" is a one-line ASK query, and "show me every record governed by a superseded ADR" walks the same supersedes linkage above. The verdict, in other words, is not only prose — it is a triple a gate can check, which is precisely the open-standards portability (RDF over a proprietary graph) that made the digital-thread row an OSS win in the first place.

The honest hybrid target architecture

Put the scorecard and the framework together and you get the architecture a real facility actually ships — not "all open source," not "all commercial," but a deliberate hybrid with the boundary drawn in ink.

The honest hybrid. The wide open-source zone — everything you built in this book — handles connectivity, historization, contextualization, semantics, and analytics, all on open standards that resist lock-in. The narrow commercial-and-validated zone owns the signed record of truth and the qualified signatures, where vendor accountability is non-negotiable. The line between them is the read-mostly NOA (NAMUR Open Architecture) boundary: the open stack reads and models; the validated system holds the record. Original diagram by the authors, created with AI assistance.

This is not a compromise born of weakness. It is the strongest design: it spends open source where open source is genuinely better — speed, cost, openness, lock-in resistance — and spends accountability where accountability is genuinely required.

Why it matters

Get this verdict wrong in either direction and it costs you. Build the regulated record on unvalidated open source because it was free, and you discover during an inspection that "free" carried a validation-and-accountability bill you never budgeted for [3]. Buy everything commercial because it felt safe, and you pay vendor margins for connectivity, historization, and analytics that open standards do for nothing, while quietly locking yourself out of your own data. The engineers who get it right are the ones who can say, layer by layer, here is what we built, here is what we bought, and here is the written reasoning — which is exactly what the scorecard, the framework, and the ADR give you.

In the real world

The hybrid this chapter scores is the pattern that actually ships. A real CHO + Protein A mAb facility runs a validated commercial MES and historian for the signed record-of-truth, and increasingly runs an open-source layer alongside it for contextualization, analytics, and engineering — because that layer is cheaper to own and faster to evolve, and because open standards keep the data portable. The same scorecard holds whether the upstream is classic fed-batch or intensified perfusion with multi-column continuous capture: the regulated-record boundary does not move. Note carefully where these boundaries have to be real rather than theoretical: as of mid-2026 no open-source tool in this book — not PostgreSQL, not Grafana, not Fuseki, not Keycloak (the open-source identity and login server) — ships as a "Part 11-compliant product." They ship the mechanisms; you build, validate, and procedurally surround the compliance. SENAITE, the OSS LIMS this book treated as a teaching system, is the cautionary footnote: its only published Part 11 gap analysis dates to 2019 and still lists real gaps in e-signatures, retention, and password controls [11]. Marketing maturity is not validated maturity — and the honest verdict is the one that keeps that distinction in ink.

Key terms

• Build-vs-buy — the decision, taken per layer, between assembling a capability from open-source parts (build) and licensing a vendor product (buy); often resolved as a deliberate hybrid.
• Total cost of ownership (TCO) — the full lifetime cost of a choice, including the costs no price tag shows: validation burden, supply-chain maintenance, and the cost of missing vendor accountability.
• Architecture Decision Record (ADR) — a short, dated, version-controlled document capturing the context, decision, and consequences of one architectural choice, so the reasoning survives the engineer who made it.
• Validation burden — the IQ/OQ/PQ, traceability, and supplier-assessment effort a regulated firm must perform; reducible (not removable) by risk-based CSA and by leveraging supplier evidence — which open source lacks because you are the supplier.
• Vendor accountability — the contractual responsibility a commercial supplier carries under agreements Annex 11 requires; the cost open source structurally cannot supply, because its licenses disclaim warranty.
• Software Bill of Materials (SBOM) — a formal inventory of every component, version, and supplier in a system; the open-source operator's substitute for "call the vendor," and the basis for owning supply-chain risk transparently.
• NTIA minimum elements — the seven data fields a usable SBOM must carry for every component — supplier, component name, version, unique identifier, dependency relationship, author of the SBOM data, and timestamp — each mapping to a concrete field in an SPDX or CycloneDX record.
• Supersede (ADR lifecycle) — the append-only convention by which a changed decision is captured in a new ADR that supersedes the old one, rather than by editing the original; it keeps the dated reasoning immutable, exactly as the audit chain keeps data immutable.
• Honest hybrid — the target architecture this book argues for: a wide open-source zone for connectivity through analytics, a narrow commercial-and-validated zone for the signed record, joined at a read-mostly NOA (NAMUR Open Architecture) boundary.
• Grouped (leave-one-batch-out) split — the validation discipline of putting every record from a batch — ideally every batch off one cell bank — wholly on one side of the train/test line, so a model is scored on genuinely unseen lots; the derivedFrom genealogy is the group key, and the within-batch hold-out behind the soft sensor's R²=0.99 is not this, which is why that number is a within-batch result, not field accuracy.
• Applicability domain — the envelope of inputs a model was trained on, plus the gate that declines to predict when a new batch falls outside it (a PLS Hotelling's T²/SPE pair, for the soft sensor), so a release-impacting model refuses to extrapolate confidently rather than guess out of its depth.
• Process drift vs. model drift — process drift is the living cells genuinely wandering campaign to campaign, a real manufacturing signal the digital thread should preserve; model drift is the predictor going stale against that moving process, a defect to detect — conflating the two is how a monitor cries wolf or misses a real shift.
• Disposition-boundary shape — the SHACL constraint that makes the scorecard's OSS<->MES boundary machine-checkable: a bp:DispositionRecord must be bp:ownedBy a validated, accountable system, so a signed record wired to the bare OSS audit chain fails the gate exactly as a missing signature does — the verdict expressed as a triple a competency-question test can enforce.

Where this leads

That is the verdict, and it is the end of the build. One short section remains: the References — the verified sources behind every claim in this book, the citations you can hand to a reviewer who, reasonably, wants to check that "every claim is runnable or cited" was a promise we kept.