DSDesign Specification

A Design Specification (DS) is the GAMP 5 deliverable that captures the technical implementation of a computerised system: the entities and relationships in the database, the API contracts of every integration, the infrastructure on which the system runs, the security model that protects records and signatures, and the algorithms that drive any GxP-impacting calculation. Where the User Requirements Specification (URS) says 'the system shall enforce a four-eyes review of master batch records' and the Functional Specification (FS) says 'on Save the MBR moves to a Pending Review state and a different user with the Reviewer role must sign before Release is enabled', the DS says 'master_batch_records.state is an enum with values draft|pending_review|released|retired enforced by a CHECK constraint and an RLS policy that joins to user_roles ON role = reviewer'. It is the lowest of the three classic specification tiers.

A DS is not marketing material. It is not a sales architecture diagram with a happy cloud icon. It is not the README of a code repository. It is the controlled, version-managed, signed-off document that an inspector or an internal QA reviewer can reach for when the question 'how do we know the system does what we said it does' demands a technical answer. In GAMP 5 Category 3 (non-configurable products) the DS is usually a thin pointer to the vendor's documentation. In Category 4 (configured products like V5) the DS is owned by the vendor and tailored where configuration meaningfully alters the technical surface. In Category 5 (custom code) the DS is owned by the developer of that code and is typically the most extensive specification in the pack.

Validation under GAMP 5 follows the V-model. The left side descends from user need to technical implementation; the right side ascends from physical install back up to user acceptance. Each specification on the left has a matching qualification on the right that tests against it:

The practical consequence: if your DS is wrong, your IQ is wrong, and the IQ failure cascades up. Drift between the actual system and the DS is one of the most common observations in EU GMP Annex 11 inspections — the inspector pulls the DS, walks to the system, and finds a configuration value, a table column, or a service version that doesn't match.

A defensible DS covers the technical surface of the system at a depth where another competent engineer could reproduce the design from the document alone. The standard sections:

1. Architecture overview — the deployment topology, the runtime (server-side rendering, edge worker, container, etc.), the trust boundaries.
2. Data model — the entity-relationship diagram, the schema of every GxP-impacting table, the primary and foreign keys, the constraints that enforce business rules at the database level.
3. Security model — authentication mechanism, session lifecycle, multi-tenant isolation (e.g. row-level security policies), role and permission model, encryption at rest and in transit, secret management.
4. Electronic records and signatures — how 21 CFR Part 11 §11.10, §11.50, §11.70 and §11.200 are implemented: append-only audit storage, hash-chain or other tamper-evident mechanism, two-component authentication on signing events, signature manifestation on the record.
5. Integration contracts — every inbound and outbound interface, with payload schemas, authentication, idempotency keys, retry behaviour, and failure-mode handling.
6. Algorithms with GxP impact — calculation logic for any field that drives a release, dosing, dispensing or labelling decision (yield, potency, expiry, label claim, dose calculation).
7. Backup, recovery and continuity — RPO/RTO targets and the mechanisms that achieve them.
8. Change-control model — how the DS itself is versioned and re-approved when the underlying system changes.

Under GAMP 5 the supplier owns the DS for any out-of-the-box or configured product. The customer does not re-author the supplier's DS in their own format; that is a waste of effort and creates two competing sources of truth. The customer's role is to (1) confirm the supplier's DS exists, (2) confirm the supplier has a quality system that maintains it, (3) reference the supplier's DS in their validation pack, and (4) document any customer-specific configuration deltas as an addendum.

This is the heart of the GAMP 5 'leverage supplier activities' principle. The 2022 second edition makes the point explicitly: regulated companies should not duplicate work the supplier has already done under a competent quality system. A supplier audit, a quality agreement, and a supplier DS that the customer has read and accepted are stronger evidence than a hand-rolled customer DS that no engineer at the vendor has ever reviewed.

Both EU GMP Annex 11 and US 21 CFR Part 11 implicitly require a DS, even though neither uses the exact term:

• Annex 11 §4.4 requires user requirements to be traced through the lifecycle — which presupposes a downstream design that can be traced to. §4.5 requires the regulated user to take reasonable steps to ensure the system has been developed under an appropriate quality management system — meaning the supplier has a DS and maintains it.
• Annex 11 §7 (Data Storage), §8 (Printouts), §9 (Audit Trails), §10 (Change and Configuration Management), §12 (Security), and §17 (Archiving) all describe technical behaviours that must be specified somewhere — that 'somewhere' is the DS.
• 21 CFR Part 11 §11.10 requires validation of the system to ensure accuracy, reliability and consistent intended performance — which cannot be demonstrated without a DS to validate against. §11.10(e) requires the use of secure, computer-generated, time-stamped audit trails — the DS is where the audit-trail mechanism is described.
• Part 11 §11.50 (signature manifestation), §11.70 (signature-to-record linking), and §11.200 (two-component signature) are all properties of the system's design — and the DS is where the auditor verifies they have been designed in, not bolted on.

The FDA's 2022 draft Computer Software Assurance (CSA) guidance is a deliberate re-emphasis on critical thinking over documentation volume. CSA right-sizes the evidence required to assure a system based on the risk that a software failure would compromise product quality or patient safety. CSA does not eliminate the DS. It changes the depth of the evidence the customer captures against it.

Under CSA, for a low-risk function (say, a notification email after a step is signed) the customer may rely on the supplier's DS, the supplier's testing, and a brief unscripted exploratory test on their install. For a high-risk function (the algorithm that calculates released yield, or the RLS policy that isolates tenants) the customer still wants a precise DS clause, a scripted test, objective evidence, and a signed result. The DS is the anchor; CSA changes how much rope you tie to it.

1. DS exists but is years out of date — the system has been upgraded twice and the DS still describes the old schema.
2. DS is a marketing diagram rather than a technical specification — there is no entity-relationship model, no description of the security mechanism, no calculation algorithms.
3. DS describes the system as 'cloud-hosted' with no statement of where data resides, how isolation is enforced, or how backups are taken.
4. Algorithms with GxP impact (yield, potency, dose, expiry) are not specified, so the IQ cannot verify the implementation.
5. Integrations are listed by name only ('connects to ERP') with no payload, no idempotency rule, no failure handling.
6. DS is owned by neither the supplier nor the customer — the supplier said the customer would write it, the customer assumed the supplier had one. Inspectors find this on the very first question.
7. Change-control of the DS is informal — there is no version, no approver, no link to the change request that triggered the revision.

Take a single requirement: the system must prevent release of a batch with an out-of-spec assay result.

Each tier is testable by a matching qualification (PQ, OQ, IQ). Each tier is owned by a different audience — business owner, business analyst, engineer. None of the three tiers can substitute for another.

A DS is not a one-time deliverable. Annex 11 §10 requires change and configuration management; PIC/S PI 011-3 §22 requires the system documentation to be kept current. Practically:

• Every change request that affects schema, integration, security or algorithm must include a DS update as a deliverable.
• The DS has a controlled version number and a change-history table.
• Periodic review (typically annual for high-criticality systems) re-affirms that the DS still matches the deployed system.
• Major release upgrades trigger a DS re-issue and a corresponding IQ refresh.
• Decommissioning is a DS event: the final DS revision describes the archival format of records that survive the system.

• Architecture clause — the SSR + serverless-worker runtime, the trust boundary at the edge, the multi-region data residency model.
• Data model clause — entity-relationship diagrams for every GxP table (batch records, audit events, signatures, training records, change controls), with primary keys, foreign keys, CHECK constraints and RLS policies enumerated.
• Security clause — Supabase Auth session lifecycle, JWT validation, Row-Level Security as the enforcement mechanism for tenant isolation, role and permission model joined through user_roles.
• Records and signatures clause — append-only audit_events table, hash-chained signature manifest, two-component sign-in for signature events, signature manifestation embedded on the printed/exported record per §11.50.
• Algorithms clause — yield calculation, dispense reconciliation, expiry date derivation, label-claim mapping — each specified with the SQL or server-function expression, the inputs and the test vectors.
• Integrations clause — each inbound and outbound contract (auth handoff, intake event, geo lookup) with the payload schema, idempotency key, retry policy and failure mode.
• Configuration deltas clause — the customer-specific layer (industry profile, signature workflows, label templates) is captured as an addendum so the baseline DS remains stable.
• Change-control clause — every release that touches the technical surface ships a DS revision in the release notes, and the validation pack is re-issued.