Skip to content

GAMP 5 Computerized System Validation

Standard: ISPE GAMP 5 (2nd Edition, 2022): A Risk-Based Approach to Compliant GxP Computerized Systems Applicability: Software categorization and computerized system validation (CSV) lifecycle for regulated deployments Overall Status: Category 4 (Configured Product), with executable qualification protocols, change control, and the audit trail feeding the customer validation lifecycle

GAMP 5 is risk-based guidance with no clauses to enumerate, so this document is not a requirements matrix like the other traceability documents in this directory. What a regulated buyer screens for is (1) a stated, defensible software category and (2) evidence that the product feeds their validation lifecycle. A blank-template documentation exercise is what that evidence spares them. This document states both. The final categorization and validation plan are always owned by the customer's quality unit under their own CSV procedures. The assessment below is the supplier-recommended starting point.

Software Categorization

Cloud-Native DCS is designed for deployment as a GAMP 5 Category 4 (configured product) system. The shipped software (operators, gateway, engine, CLI) is standard supplier-maintained product. Everything a site authors to describe its process is configuration applied via declarative Kubernetes resources. None of it is custom code.

Layer GAMP 5 category Rationale
Kubernetes, PostgreSQL/TimescaleDB, cert-manager, MQTT broker Category 1 (infrastructure software) Established platform layers underneath the product; typically qualified through installation and configuration control in the customer's assessment, and functional testing is not expected at this category
Cloud-Native DCS shipped images (operators, gateway, engine, CLI) Category 4 (configured product) Standard supplier software configured per process through declarative resources; no site-specific code is compiled into the shipped images
Site-authored declarative resources (see list below) Configuration within Category 4 Schema-validated at admission by CRD OpenAPI validation; version-controlled and change-controlled like any other configuration
Custom Go function-block types / forked images Category 5 (custom application), and only if a site authors them Not required for normal recipe and equipment authoring; a site that forks the product owns proportionally more CSV documentation for its custom code

The following artifacts are always configuration and do not shift the system into Category 5:

  • Recipes (General / Site / Master / Control) and their formulas
  • Equipment hierarchy (Enterprise / Site / Area / ProcessCell / Unit / ControlModule)
  • Phase templates, Operation templates, Unit-Procedure templates
  • Control-module templates instantiated with tagBindings and parameters
  • Alarm definitions and their exception actions
  • IOModule configuration (protocol, address, channel map)

Authoring brand-new function block types in Go and building a forked image would shift the system into Category 5 with proportionally more CSV documentation. The shipped template library does not require this for normal recipe and equipment authoring.

Configuration as declarative text: one phase template read and edited in the product's own editor, in VS Code, and in vim under git, with the edit that lands going through the governed change-control path.

Validation Lifecycle (V-Model) Mapping

GAMP 5 structures validation as a V-model: specification activities on the left leg, verification activities on the right, with each verification stage tracing back to the specification it confirms. The product supplies executable, re-runnable artifacts for the right leg and machine-enforced change control around the whole lifecycle. The customer writes their plans and requirements, and the system supplies the evidence.

Lifecycle activity What Cloud-Native DCS supplies Detail
Supplier assessment Versioned releases from a CI pipeline with unit, integration, and e2e tests; cosign-signed images; SBOMs per component Secure-development surface documented in the IEC 62443 traceability matrix
User requirements (URS) Customer-owned. The compliance traceability matrices in this directory map regulatory requirements to implemented controls, so URS items citing ISA-88, 21 CFR Part 11, or IEC 62443 trace directly to evidence Compliance index
Functional / configuration specification The applied configuration is itself the specification: site-authored CRs are declarative, schema-validated at admission, and version-controlled in Git under GitOps enforcement -- there is no drift between "specified" and "applied" Change Control, GitOps enforcement
Design review and change control ChangeRequest propose-approve-merge workflow with HMAC-SHA256 electronic signatures and enforced segregation of duties (self-approval refused); the change-control admission webhook writes an AuditRecord for every gated admission -- no admit without audit 21 CFR Part 11 §11.10(k)
Installation Qualification (IQ) dcs qualify iq reads live cluster state (Kubernetes version, CRDs, Helm release and values digest, deployments and image digests, RBAC hash, PVCs, ServiceAccounts) and compares it to a quality-approved baseline; re-runnable after every deploy Executable Validation Protocols
Operational Qualification (OQ) dcs qualify oq drives canned batches through all 8 external ISA-88 commands across five scenarios and threads every state transition to an immutable AuditRecord; customers extend the scenario set for site-specific requirements Executable Validation Protocols
Performance Qualification (PQ) dcs qualify pq runs N batches, queries the historian for a Critical Quality Attribute per batch, and computes Mean/StdDev/Cpk with a CAPABLE/NOT_CAPABLE verdict against a configurable Cpk minimum (default 1.33) Executable Validation Protocols
Traceability and retention of validation records Every IQ/OQ/PQ run persists its full report as an immutable Qualification AuditRecord; historical runs are queryable via dcs audit export --target-kind Qualification and archived on the standard audit retention schedule 21 CFR Part 11 §11.10(c)
Operational phase / continued verification --fail-on-deviation turns IQ/OQ/PQ into deploy gates in the CI/CD pipeline; IQ baseline hashes detect out-of-band configuration drift between runs; scheduled archive-integrity verification re-checks the audit archive on an interval Executable Validation Protocols, 21 CFR Part 11 §11.10(c)

Four of the table's rows are on camera, in row order.

Functional / configuration specification: declared 100 ms, patched out-of-band to 9999 ms, and back to 100 ms with a DriftCorrected audit record naming the foreign writer. The enforcement layer on camera is the ControlModule compiler. A hardened deployment's GitOps admission policies deny the patch outright.
Version-controlled configuration: provisioning equipment is a pull request, the merge is the deployment, Flux reconciles it live, and the resulting audit record carries the commit SHA.
Design review and change control: one e-signed approval ceremony, two realisations. A routine change lands by direct apply and the production change opens a pull request, with the ceremony identical in both.
The right leg of the V-model, executed: IQ against a quality-approved baseline, OQ driving the state machine with every transition landing in the audit trail, PQ computing Cpk across three batches to a verdict, then the same suite re-run with its history queryable as ordinary audit records.

The distinguishing property is that the right-leg artifacts are executable and re-runnable. Qualification runs after every deploy and persists its evidence into the same immutable audit trail as production records. A one-time commissioning exercise whose documents go stale is the thing this replaces. The rationale for this design is covered in Executable Validation Protocols.