Recipe Versioning

21 CFR 211.188 requires the BMR to be an "accurate reproduction" of the approved MMR. Years later, if a regulator asks which MMR version produced a specific lot, you must answer definitively and produce the exact version on demand. Without robust versioning:

• The current MMR has drifted from the version actually used; the BMR no longer reproduces anything traceable.
• Changes to the MMR have happened silently ("typo fix", "clarification") without change control.
• Multiple Active versions exist simultaneously and execution layer picked the wrong one.
• The version-of-record at the time of an NDA filing or PAI is gone.

Immutability is not "locked from edit in the UI". It is a system-level property:

• Approved versions are stored as content-addressed snapshots — any modification produces a different stored object.
• The original cannot be overwritten by database update; revisions go to new rows/objects.
• Audit-trail rows for the version cannot be deleted (Part 11 §11.10(e)) — including by admins.
• Cryptographic integrity (hash) optional but strongly recommended for high-criticality recipes.
• Backup and recovery preserve the immutable history — not just the latest snapshot.

Common conventions:

• Sequential integer — v1, v2, v3. Simple, unambiguous, no semantic meaning.
• Semantic — major.minor (1.0, 1.1, 2.0). Major = process change requires re-validation; minor = clarification.
• Date-stamped — 2026.05.31. Easy to read; risks ambiguity if multiple revisions on the same day.
• Status-prefixed — DRAFT-v2, REVIEW-v2, APPROVED-v2. Visible state without separate field.

Sequential or semantic is preferred for regulatory clarity. Whatever you pick, document the scheme in the SOP for recipe management.

• Any change to a process parameter (temperature, time, ratio).
• Any change to a component (vendor, grade, spec).
• Any change to equipment assignment (new line, new unit class).
• Any change to an IPC (method, acceptance criteria, sampling plan).
• Any change to a signature requirement or release rule.
• Typo fixes — yes, even typos. A typo in a setpoint matters; a typo in a header doesn't but the discipline of always-version-on-edit removes judgement calls.

Every new approved version must link to a change control record that captures:

• Reason for change — rooted in CAPA, deviation, post-approval supplement, or improvement.
• Impact assessment — which CPPs touched, which validation needs re-look, which descendant recipes affected.
• Regulatory implication — within Established Conditions? Triggers prior approval / CBE-30 / annual report?
• Training implication — which roles need refresher training before the new version is used?
• Effective date — when does the new version become Active?
• Approvals — author, reviewer, QA, regulatory affairs (when needed).

Without the change-control link, a version exists but its provenance is unaudited — which is a Part 11 finding in itself.

The system must answer, in seconds:

• Which version was Active on a given date?
• Which version produced lot X?
• What was the full content of version N?
• What changed between version N-1 and N?
• Who approved version N, when, with which e-signature meaning?
• Which deviations / CAPAs / supplements triggered each version?
• What is the current Active version and what's in the pipeline?

If any of these requires PDF archaeology or a manual reconstruction across multiple systems, the versioning architecture is inadequate for regulated manufacturing.

• Editing in place "because it's just a typo" — Part 11 violation.
• Storing versions as PDF attachments — no structured query, no diff capability.
• Sequential numbering by author rather than by system — clashes when two authors edit in parallel.
• No date-of-Active capture — cannot answer "which version was live on date X".
• No diff capability — cannot answer "what changed between N-1 and N".
• Versions stored separately from BMR snapshots — version lookup requires cross-system join.
• Backups discard non-current versions — historical reconstruction destroyed.
• Admin permission to delete version history — Part 11 §11.10(e) violation.