GAMP5 Category 5 Validation Strategy — Git-Based Quality System
This document defines the validation strategy for GatherSystemTech's FDA 21 CFR Part 11 compliant software, using Git + GitHub + Linear as the core quality management tools.
1. Scope
| Item | Description |
|---|---|
| Applicable Projects | Jope-SMB (Simulated Moving Bed Control System) and all software projects requiring FDA 21 CFR Part 11 compliance |
| GAMP5 Classification | Category 5 — Custom/Bespoke Software |
| Regulatory Basis | FDA 21 CFR Part 11 — Electronic Records; Electronic Signatures |
2. Quality Management Tool Suite
2.1 Tool Mapping
| Quality Activity | Tool | Description |
|---|---|---|
| Requirements Management | Linear Issue | Each requirement maps to an Issue with description, priority, and status tracking |
| Change Management | Git + GitHub PR | All code changes go through the PR workflow with review and approval |
| Version Control | Git | Complete change history, tamper-proof (with Branch Protection) |
| Code Review | GitHub PR Review | Reviewer approve = formal review record |
| Test Management | Git commit + Test Agent | Test results recorded in commits and PRs |
| Traceability Chain | Linear → Git → GitHub → Test | End-to-end traceability |
| Document Version Control | Git repo (markdown) | Validation documents managed in version control as markdown |
| Document Review | GitHub PR Review | Document changes also go through the PR review workflow |
2.2 FDA Part 11 Requirements Already Met by Git
| FDA Part 11 Requirement | Git/GitHub Equivalent | Coverage |
|---|---|---|
| Audit Trail | git log, git blame — records who, when, and what changed | Fully met |
| Change Control | PR review + approve workflow | Fully met |
| Code Review | PR review comments, approve records permanently retained | Fully met |
| Traceability | Commit → PR → Linear Issue complete traceability chain | Fully met |
| Attributable | Each commit includes author + timestamp | Fully met |
2.3 Areas Requiring Reinforcement
| FDA Part 11 Requirement | Gap | Solution | Complexity |
|---|---|---|---|
| Electronic Signature | Git commit does not equal a regulatory-defined electronic signature | GPG signed commits + Branch Protection requiring signatures | Medium |
| System Validation | Git/GitHub itself is not a validated system | Write IQ/OQ/PQ validation documents | Medium |
| Access Control | Need to demonstrate that permission management is controlled | GitHub Branch Protection Rules + documented permission matrix | Low |
| Prevent Record Deletion | git push --force can tamper with history | Disable force push + Branch Protection | Low |
| Reason for Change | "Why changed" is not always recorded | Require commit messages to include Issue ID | Low |
| Closed System | GitHub is a cloud service | Write security control documentation defining access scope | Low |
3. Git Workflow (Compliant Version)
3.1 Merge Strategy
Squash Merge is the standard strategy used when merging all feature branches into master/develop.
| Advantage | Description |
|---|---|
| 1:1 Mapping | One commit on master = one PR = one Linear Issue |
| Easy Revert | Rolling back a feature only requires reverting one commit |
| Clean History | git log --oneline master serves directly as the version changelog |
| Audit-Friendly | Each commit is a complete, traceable change unit |
3.2 Branch Lifecycle
Feature branch created → Development → PR created → Review + Approve → Squash Merge → Delete branch
- Feature branches must be deleted after merging to avoid branch clutter
- Development history is preserved in the GitHub PR (all original commits, diff, and review discussions are permanently retained)
- Branch deletion does not affect any historical records
3.3 Traceability Chain
git log → View "what changed" (each commit includes PR number)
GitHub PR (#N) → View "how it was developed" (original commits, diff, review)
Linear Issue (JOP-XXX) → View "why it was done" (requirements, development instructions, discussion)
3.4 Branch Protection Rules (Must Be Enabled)
| Rule | Setting |
|---|---|
| Require pull request reviews | At least 1 reviewer approve |
| Require signed commits | GPG signing (electronic signature substitute) |
| Do not allow force pushes | Prevent history tampering |
| Do not allow deletions | Prevent deletion of protected branches |
4. Validation Document Architecture
4.1 Document List
| Document ID | Document Name | Description | Status |
|---|---|---|---|
| VP-001 | Validation Plan | Validation strategy, scope, tools, role definitions | Pending |
| SOP-001 | Software Development SOP | Software development lifecycle procedure (including Git workflow) | Pending |
| SOP-002 | Change Control SOP | Change control procedure (including PR review workflow) | Pending |
| SOP-003 | Testing SOP | Testing strategy and procedures | Pending |
| RA-001 | Risk Assessment | Risk assessment (FMEA method) | Pending |
| RTM-001 | Requirements Traceability Matrix | Requirements traceability matrix | Pending |
| IQ-001 | Installation Qualification | Installation qualification report | Pending |
| OQ-001 | Operational Qualification | Operational qualification report | Pending |
| PQ-001 | Performance Qualification | Performance qualification report | Pending |
| VSR-001 | Validation Summary Report | Validation summary report | Pending |
4.2 Document Storage Location
{validation-repo}/
├── sop/
│ ├── SOP-001-software-development.md
│ ├── SOP-002-change-control.md
│ └── SOP-003-testing.md
├── validation/
│ ├── VP-001-validation-plan.md
│ ├── RA-001-risk-assessment.md
│ ├── RTM-001-traceability-matrix.md
│ └── reports/
│ ├── IQ-001-installation-qualification.md
│ ├── OQ-001-operational-qualification.md
│ ├── PQ-001-performance-qualification.md
│ └── VSR-001-validation-summary.md
├── templates/
│ └── (document templates)
└── .github/
└── workflows/
└── pdf-export.yml ← markdown → PDF automation (for audit submission)
4.3 Document Management Workflow
1. Write/modify document (markdown in Git)
↓
2. Create PR → Reviewer approve (= formal document sign-off)
↓
3. Squash Merge (signed commit = electronic signature)
↓
4. CI auto-generates PDF (for audit submission)
5. RTM (Requirements Traceability Matrix)
5.1 Purpose
The RTM proves that each requirement has corresponding implementation and tests. Auditors can use it to confirm nothing is missing.
5.2 Format
| Requirement (Linear Issue) | Design Spec | Implementation (PR) | Test Method | Test Result | Status |
|---|---|---|---|---|---|
| JOP-99: Recipe Version Control | Recipe Version Control Design | PR #14 | Unit test + Integration test | Passed | ✅ |
| JOP-101: Alarm/Interlock | Alarm Classification Design | PR #12 | Unit test + Integration test | Passed | ✅ |
| JOP-102: Backup/Recovery | Backup System Design | PR #13 | Unit test + Integration test | Passed | ✅ |
5.3 Automation Plan
The existing toolchain has the prerequisites for automated RTM generation:
Linear Issue (Requirements)
↓ Issue ID recorded in commit message
Git commit / PR (Implementation)
↓ PR contains test results
Test Report (Testing)
↓
Script auto-matches → generates RTM table
The automation script can collect data from the following sources:
- Linear API — Fetch all Issues (requirements list)
- Git log — Match which Issues have corresponding commits/PRs
- Test report — Match test results
- Auto-generate RTM — Flag requirements missing implementation or tests
6. Electronic Signature Strategy
6.1 GPG Signed Commits
| Item | Description |
|---|---|
| Purpose | Prove that a commit comes from a specific developer and cannot be forged |
| Mechanism | Each developer generates a GPG key pair; commits are automatically signed |
| Verification | GitHub displays a "Verified" badge |
| SOP Definition | Define in SOP-001 that "GPG signed commit = electronic signature" |
6.2 PR Approve as Sign-Off
| Role | Action | Equivalent To |
|---|---|---|
| Developer | GPG signed commit | Developer signature |
| Reviewer | PR approve | Reviewer sign-off |
| Merger | Squash merge (signed) | Approval for release |
7. Current Project Compliance Status
Jope-SMB (Primary Compliance Project)
| Compliance Item | Implementation Status | Description |
|---|---|---|
| User Management | ✅ Done | GST.Plugin.UserManagement (GST-14) |
| Audit Trail | ✅ Done | GST.Plugin.AuditTrail |
| Electronic Signature | ✅ Done (Application Layer) | In-app electronic signature mechanism |
| Session Idle Timeout | ✅ Done | SessionIdleService (GST-11) |
| NTP Time Sync | ✅ Done | NTP time synchronization (GST-10) |
| Recipe Version Control | ✅ Done | JOP-99 |
| Backup/Recovery | ✅ Done | JOP-102 |
| Alarm/Interlock | ✅ Done | JOP-101 |
| Data Export | ⬜ Backlog | JOP-100 |
| Device Validation | ⬜ Backlog | JOP-103 |
| Validation Documents | ⬜ Not Started | Document architecture defined in this document |
8. Next Steps
| Priority | Item | Description |
|---|---|---|
| 1 | Enable Branch Protection | Disable force push, require PR review, require signed commits |
| 2 | Set Up GPG Signed Commits | All developers generate GPG keys and configure auto-signing |
| 3 | Write SOP-001 ~ SOP-003 | Formally document the current Git workflow |
| 4 | Write VP-001 Validation Plan | Define validation strategy and scope |
| 5 | Create RTM-001 | Generate initial traceability matrix from existing Linear Issues |
| 6 | Write RA-001 Risk Assessment | FMEA risk assessment |
| 7 | Execute IQ/OQ/PQ | Installation/Operational/Performance Qualification |
| 8 | Write VSR-001 | Validation summary report compiling all evidence |
| 9 | Build PDF Export Pipeline | CI/CD markdown → PDF automation |
| 10 | RTM Automation Script | Linear + Git → auto-generate traceability matrix |
Document Version: v1.0 Created: 2026-03-16 Last Updated: 2026-03-16 Owner: PM Agent