Work Order QMS Module — Validation Protocol Templates (IQ/OQ/PQ)
Classification: Compliance — Validation Engineering
Date: 2026-02-13
Artifact: 70 of WO System Series
Status: Proposed
Regulatory Alignment: FDA 21 CFR Part 11, GAMP 5, ISPE Baseline Guide Vol. 5
Source Artifacts: 20-regulatory-compliance-matrix.md, 65-testing-strategy.md §5, 17-e-signature-architecture.md, 69-versioning-evolution-strategy.md §6
1. Validation Lifecycle Overview
1.1 V-Model Mapping
REQUIREMENTS ──────────────────── PQ (Performance Qualification)
↓ ↑
FUNCTIONAL SPEC ─────────────── OQ (Operational Qualification)
↓ ↑
DESIGN SPEC ────────────── IQ (Installation Qualification)
↓ ↑
BUILD ─────── Unit/Integration Tests
Each qualification level validates against a different specification level, forming a traceable chain from requirements through evidence.
1.2 Qualification Matrix
| Qualification | Validates Against | Question Answered | Automation Target | Evidence Owner |
|---|---|---|---|---|
| IQ | Design Specification + TDD §3 | "Is the system installed correctly?" | 100% automated | SRE / DevOps |
| OQ | Functional Specification + SDD | "Does the system operate correctly?" | 95% automated | QA Engineering |
| PQ | User Requirements + Business Case | "Does the system perform as needed in the real world?" | 80% automated | QA + Compliance |
1.3 Execution Triggers
| Trigger | Qualification Required | Scope |
|---|---|---|
| Initial deployment (new tenant) | Full IQ + OQ + PQ | All components |
| Major release (API version bump) | Full IQ + OQ + PQ | All affected components |
| Minor release (feature behind flag) | IQ + targeted OQ | Changed components only |
| Patch release (bug fix) | IQ + regression OQ | Fix scope + regression |
| Infrastructure change (GKE upgrade, DB migration) | IQ | Infrastructure only |
| Configuration change (tenant config) | Targeted OQ | Changed configuration scope |
| Disaster recovery event | IQ + targeted OQ | Restored components |
2. IQ Protocol Template
2.1 Protocol Header
# Installation Qualification Protocol
# CODITECT WO System — [Tenant Name]
Document ID: IQ-WO-[TENANT]-[VERSION]-[DATE]
Version: 1.0
Status: ☐ Draft ☐ Approved for Execution ☐ Executed ☐ Approved
System: CODITECT Work Order QMS Module v[VERSION]
Environment: ☐ Staging ☐ Production
Prepared by: [Name, Role, Date]
Reviewed by: [Name, Role, Date]
Approved by: [Name, Role, Date]
Change History:
| Version | Date | Author | Description |
|---------|------|--------|-------------|
| 1.0 | [Date] | [Author] | Initial protocol |
2.2 IQ Test Catalog
| Test ID | Category | Verification | Method | Pass Criteria | Regulatory Trace |
|---|---|---|---|---|---|
| IQ-001 | Schema | Database schema matches expected hash | prisma migrate status + schema hash comparison | Zero pending migrations, hash matches release manifest | §11.10(h) data input validation |
| IQ-002 | RLS | All 22+ tables have active RLS policies | SELECT * FROM pg_policies cross-referenced against entity list | 100% coverage, zero missing policies | §11.10(d) access control |
| IQ-003 | Audit | Audit trail trigger prevents UPDATE/DELETE | Attempt UPDATE on audit_trail → expect rejection | UPDATE fails with trigger error | §11.10(e) audit trails |
| IQ-004 | Audit | Audit trail trigger prevents DELETE | Attempt DELETE on audit_trail → expect rejection | DELETE fails with trigger error | §11.10(c) record protection |
| IQ-005 | Connectivity | All service health checks pass | GET /api/health on each service | All dependencies report "connected" | System availability |
| IQ-006 | TLS | TLS 1.3 enforced on all public endpoints | testssl.sh scan against API gateway | No protocol < TLS 1.3 accepted | §164.312(e)(1) transmission security |
| IQ-007 | Vault | Service retrieves test secret from Vault | Vault health check + test secret retrieval | Secret retrieved, latency < 500ms | §11.10(d) access control |
| IQ-008 | Events | NATS publish/subscribe functional | Publish test event, verify receipt by subscriber | Round-trip < 100ms | System connectivity |
| IQ-009 | Versions | Application version matches release manifest | GET /api/version compared to deployment config | Exact version match | Configuration control |
| IQ-010 | Config | Tenant configuration loaded correctly | Verify tenant-specific config against expected values | All config keys match | §11.10(a) system validation |
| IQ-011 | Signatures | E-signature service reachable and key available | Sign test payload, verify signature | Signature verifies correctly | §11.50, §11.70 |
| IQ-012 | Time | Server time synchronized via NTP | Compare server timestamp to NTP reference | Drift < 1 second | §11.10(e) timestamps |
| IQ-013 | Backups | Backup job configured and last run successful | Check backup job status and last completion | Last backup < 24 hours old | §11.10(c) data protection |
| IQ-014 | Monitoring | Observability stack receiving metrics | Verify Prometheus scrape targets, Grafana data sources | All targets up, data flowing | Operational readiness |
2.3 IQ Execution Record
## IQ Execution Record
Execution Date: [Date]
Executed by: [Name, Role]
Environment: [URL, Region, Instance ID]
Release Version: [Semantic version + commit hash]
| Test ID | Result | Evidence Reference | Deviation? | Notes |
|---------|--------|-------------------|-----------|-------|
| IQ-001 | ☐ Pass ☐ Fail | [Link to schema diff output] | ☐ Yes ☐ No | |
| IQ-002 | ☐ Pass ☐ Fail | [Link to pg_policies query result] | ☐ Yes ☐ No | |
| ... | | | | |
Summary:
Total tests: 14
Passed: [N]
Failed: [N]
Deviations: [N] (see Deviation Log §2.5)
Overall Result: ☐ PASS ☐ PASS WITH DEVIATIONS ☐ FAIL
Signatures:
Executed by: _________________________ Date: _________
Reviewed by: _________________________ Date: _________
Approved by: _________________________ Date: _________
2.4 IQ Automation Script
#!/bin/bash
# iq-runner.sh — Automated IQ execution
# Generates evidence package in /evidence/iq-[date]/
set -euo pipefail
EVIDENCE_DIR="./evidence/iq-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$EVIDENCE_DIR"
echo "=== IQ-001: Schema Verification ==="
npx prisma migrate status > "$EVIDENCE_DIR/iq-001-schema-status.txt" 2>&1
SCHEMA_HASH=$(npx prisma migrate diff --from-schema-datamodel prisma/schema.prisma --to-schema-datasource prisma/schema.prisma --script | sha256sum | cut -d' ' -f1)
echo "Schema hash: $SCHEMA_HASH" >> "$EVIDENCE_DIR/iq-001-schema-hash.txt"
echo "$SCHEMA_HASH" | diff - expected-schema-hash.txt > "$EVIDENCE_DIR/iq-001-hash-diff.txt" && echo "PASS" || echo "FAIL"
echo "=== IQ-002: RLS Policy Verification ==="
psql "$DATABASE_URL" -c "SELECT schemaname, tablename, policyname FROM pg_policies ORDER BY tablename;" > "$EVIDENCE_DIR/iq-002-rls-policies.txt"
POLICY_COUNT=$(psql "$DATABASE_URL" -t -c "SELECT COUNT(DISTINCT tablename) FROM pg_policies;")
echo "Tables with RLS: $POLICY_COUNT" >> "$EVIDENCE_DIR/iq-002-rls-count.txt"
echo "=== IQ-003: Audit Trail Immutability ==="
psql "$DATABASE_URL" -c "UPDATE audit_trail SET action='TAMPER_TEST' WHERE id='nonexistent';" > "$EVIDENCE_DIR/iq-003-update-test.txt" 2>&1 || echo "PASS: UPDATE blocked" >> "$EVIDENCE_DIR/iq-003-result.txt"
echo "=== IQ-005: Health Check ==="
curl -s "$API_URL/api/health" | jq '.' > "$EVIDENCE_DIR/iq-005-health.json"
echo "=== IQ-006: TLS Scan ==="
testssl.sh --json "$API_URL" > "$EVIDENCE_DIR/iq-006-tls-scan.json" 2>/dev/null
echo "=== IQ-012: Time Sync ==="
SERVER_TIME=$(curl -s "$API_URL/api/health" | jq -r '.timestamp')
NTP_TIME=$(ntpdate -q pool.ntp.org 2>/dev/null | tail -1)
echo "Server: $SERVER_TIME, NTP: $NTP_TIME" > "$EVIDENCE_DIR/iq-012-time-sync.txt"
# Generate evidence package manifest
echo "=== Evidence Package Manifest ===" > "$EVIDENCE_DIR/MANIFEST.txt"
ls -la "$EVIDENCE_DIR" >> "$EVIDENCE_DIR/MANIFEST.txt"
sha256sum "$EVIDENCE_DIR"/* >> "$EVIDENCE_DIR/MANIFEST.txt"
echo "Evidence package: $EVIDENCE_DIR"
3. OQ Protocol Template
3.1 Protocol Header
# Operational Qualification Protocol
# CODITECT WO System — [Tenant Name]
Document ID: OQ-WO-[TENANT]-[VERSION]-[DATE]
Version: 1.0
Status: ☐ Draft ☐ Approved for Execution ☐ Executed ☐ Approved
System: CODITECT Work Order QMS Module v[VERSION]
Prerequisite: IQ-WO-[TENANT]-[VERSION]-[DATE] APPROVED
Prepared by: [Name, Role, Date]
Reviewed by: [Name, Role, Date]
Approved by: [Name, Role, Date]
3.2 OQ Test Catalog
3.2.1 State Machine Verification
| Test ID | Scenario | Steps | Expected Result | Regulatory Trace |
|---|---|---|---|---|
| OQ-SM-001 | Happy path: DRAFT → CLOSED | Create WO → Plan → Approve (SO + QA) → Assign → Start → Complete → Close | All transitions succeed, audit trail complete | §11.10(f) sequencing |
| OQ-SM-002 | Invalid transition rejection | Attempt DRAFT → COMPLETED (skipping intermediate states) | 422 error with valid transitions listed | §11.10(f) sequencing |
| OQ-SM-003 | Blocked/unblocked cycle | IN_PROGRESS → BLOCKED (with reason) → IN_PROGRESS (with resolution) | Both transitions succeed, reason/resolution in audit trail | §11.10(e) audit |
| OQ-SM-004 | Cancellation from any cancelable state | Cancel from DRAFT, PLANNED, APPROVED, ASSIGNED | All succeed; states BLOCKED, IN_PROGRESS, COMPLETED reject cancel | §11.10(f) sequencing |
| OQ-SM-005 | Regulatory WO requires dual approval | Create regulatory WO → submit → only SO approves → attempt assign | Blocked: QA approval still required | §11.10(g) authority checks |
| OQ-SM-006 | Non-regulatory WO with SO-only approval | Create non-regulatory WO → submit → SO approves → assign | Succeeds with single approval | Business rule |
3.2.2 RBAC Verification
| Test ID | Scenario | Actor | Expected Result | Regulatory Trace |
|---|---|---|---|---|
| OQ-RBAC-001 | Originator creates WO | ORIGINATOR role | WO created in DRAFT | §11.10(d) access |
| OQ-RBAC-002 | Assignee cannot create WO | ASSIGNEE role | 403 Forbidden | §11.10(d) access |
| OQ-RBAC-003 | Vendor sees only assigned WOs | VENDOR role | List returns only WOs assigned to this vendor | §11.10(d) access |
| OQ-RBAC-004 | Auditor has read-only access | AUDITOR role | Can view all WOs and audit trails; all write operations return 403 | §11.10(d) access |
| OQ-RBAC-005 | SOD: originator cannot approve own WO | ORIGINATOR who is also SYSTEM_OWNER | Approval rejected on own WO | SOC 2 CC6.1 |
| OQ-RBAC-006 | Cross-tenant isolation | Tenant A user | Cannot see/access Tenant B WOs, even by direct ID | §11.10(d) access, multi-tenancy |
3.2.3 E-Signature Verification
| Test ID | Scenario | Expected Result | Regulatory Trace |
|---|---|---|---|
| OQ-SIG-001 | Valid signature with re-authentication | Signature created with signer ID, timestamp, meaning, hash | §11.50, §11.70 |
| OQ-SIG-002 | Signature without re-auth rejected | 401 Unauthorized — re-authentication required | §11.100(b) identity verification |
| OQ-SIG-003 | Signature bound to specific WO version | Modify WO after signature → verify original signature still references original content | §11.70 signature linking |
| OQ-SIG-004 | Signature immutability | Attempt to modify existing signature record → reject | §11.70 no excision |
| OQ-SIG-005 | Delegation with audit trail | Delegated approval succeeds; delegation chain visible in audit | §11.10(e) audit |
3.2.4 Audit Trail Verification
| Test ID | Scenario | Expected Result | Regulatory Trace |
|---|---|---|---|
| OQ-AUDIT-001 | Every transition generates entry | Execute all valid transitions → verify 1:1 audit entry mapping | §11.10(e) |
| OQ-AUDIT-002 | Audit entry captures required fields | Verify: entity type, entity ID, action, performed_by, timestamp, previous_value, new_value | §11.10(e) |
| OQ-AUDIT-003 | Server-side timestamps | Verify audit timestamp is server-generated, not client-supplied | §11.10(e) secure timestamps |
| OQ-AUDIT-004 | Audit entries immutable | Verify UPDATE/DELETE blocked by trigger | §11.10(c) record protection |
| OQ-AUDIT-005 | Audit trail searchable and exportable | Query by date range, entity, actor → export as JSON/CSV | §11.10(b) retrieval |
| OQ-AUDIT-006 | Hash chain integrity | Verify each entry's hash includes previous entry's hash | §11.70 (extended) |
3.2.5 Agent Orchestration Verification
| Test ID | Scenario | Expected Result | Regulatory Trace |
|---|---|---|---|
| OQ-AGENT-001 | Agent creates WO with audit trail | Agent-created WO has agent_session_id in audit | Agent accountability |
| OQ-AGENT-002 | Agent respects RBAC boundaries | Agent cannot approve (requires human e-signature) | §11.100 human signatures |
| OQ-AGENT-003 | Agent token budget enforcement | Agent exceeding budget → circuit breaker activates | Cost control |
| OQ-AGENT-004 | Agent checkpoint escalation | Agent reaches architecture decision → pauses for human review | Checkpoint framework |
| OQ-AGENT-005 | Agent failure isolation | Kill agent worker → WO transitions to BLOCKED, not corrupted | Fault tolerance |
3.3 OQ Execution Record
## OQ Execution Record
Execution Date: [Date]
IQ Prerequisite: IQ-WO-[TENANT]-[VERSION]-[DATE] — APPROVED
Executed by: [Name, Role]
Environment: [URL, Version]
| Test ID | Result | Evidence File | Deviation? | Notes |
|---------|--------|--------------|-----------|-------|
| OQ-SM-001 | ☐ Pass ☐ Fail | oq-sm-001-happy-path.json | ☐ Yes ☐ No | |
| OQ-SM-002 | ☐ Pass ☐ Fail | oq-sm-002-invalid-transition.json | ☐ Yes ☐ No | |
| ... | | | | |
Summary:
Total tests: [N] | Passed: [N] | Failed: [N] | Deviations: [N]
Overall Result: ☐ PASS ☐ PASS WITH DEVIATIONS ☐ FAIL
4. PQ Protocol Template
4.1 Protocol Header
# Performance Qualification Protocol
# CODITECT WO System — [Tenant Name]
Document ID: PQ-WO-[TENANT]-[VERSION]-[DATE]
Prerequisite: OQ-WO-[TENANT]-[VERSION]-[DATE] APPROVED
4.2 PQ Test Catalog
| Test ID | Category | Scenario | Load Profile | Pass Criteria | Evidence |
|---|---|---|---|---|---|
| PQ-PERF-001 | API Throughput | Sustained WO operations | 100 concurrent users, 50 WO transitions/sec for 30 min | P95 < 500ms, 0% errors | k6 report |
| PQ-PERF-002 | Audit Write | Sustained audit trail writes | 200 writes/sec for 30 min | P95 < 50ms, 0% lost entries | k6 report + audit count verification |
| PQ-PERF-003 | Agent Dispatch | Agent orchestration under load | 20 concurrent agent sessions, 5 WOs each | All agents complete, no deadlocks | Agent execution report |
| PQ-PERF-004 | Database Capacity | Query performance at data volume | 500K WOs, 5M audit entries pre-seeded | Query P95 < 100ms | pg_stat_statements |
| PQ-PERF-005 | Multi-Tenant Isolation | Cross-tenant query isolation | 10 tenants, concurrent operations | Zero cross-tenant data leakage | RLS verification + query logs |
| PQ-PERF-006 | Failover Recovery | Database failover under load | Active transactions during failover | Recovery < 120s, zero data loss, audit chain intact | Failover log + audit verification |
| PQ-SLA-001 | 24-hour Soak | Normal operation over extended period | Realistic traffic profile for 24 hours | SLA targets met, no memory leaks, no connection leaks | Grafana snapshots |
| PQ-SLA-002 | Peak Load | Black Friday-equivalent spike | 5× normal traffic for 1 hour | Graceful degradation, no data loss | k6 report + error rate |
| PQ-USER-001 | End-to-End Journey | Full WO lifecycle with real user timing | 5 users complete Sam's Journey (68-user-experience-journeys.md §1.2) | TTFV targets met per persona | Journey timing report |
| PQ-USER-002 | Compliance Workflow | FDA-ready WO with all checkpoints | Regulatory WO with dual approval, evidence, audit package | All compliance artifacts generated correctly | Evidence package review |
5. Traceability Matrix
The traceability matrix connects requirements → tests → evidence, providing auditors a single document to verify coverage.
5.1 Matrix Structure
| Requirement ID | Requirement Source | Requirement Description | IQ Tests | OQ Tests | PQ Tests | Evidence | Status |
|---|---|---|---|---|---|---|---|
| FDA-11.10(c) | 20-regulatory-compliance-matrix §1 | Protection of records for accuracy and integrity | IQ-003, IQ-004 | OQ-AUDIT-004 | — | Trigger test log, UPDATE rejection log | ✅ |
| FDA-11.10(d) | 20-regulatory-compliance-matrix §1 | System access limited to authorized individuals | IQ-002 | OQ-RBAC-001 through OQ-RBAC-006 | PQ-PERF-005 | RLS policy dump, RBAC test results, isolation test | ✅ |
| FDA-11.10(e) | 20-regulatory-compliance-matrix §1 | Audit trail documentation | IQ-003, IQ-012 | OQ-AUDIT-001 through OQ-AUDIT-006 | PQ-PERF-002 | Audit entry samples, timestamp verification, hash chain | ✅ |
| FDA-11.10(f) | 20-regulatory-compliance-matrix §1 | Operational checks for sequencing | — | OQ-SM-001 through OQ-SM-006 | PQ-USER-002 | Transition test results, rejection evidence | ✅ |
| FDA-11.10(g) | 20-regulatory-compliance-matrix §1 | Authority checks | — | OQ-SM-005, OQ-RBAC-005 | — | Dual approval test, SOD rejection log | ✅ |
| FDA-11.10(h) | 20-regulatory-compliance-matrix §1 | Device checks for data input validity | IQ-001, IQ-010 | OQ-SM-002 | — | Schema validation evidence, invalid input rejection | ✅ |
| FDA-11.50 | 20-regulatory-compliance-matrix §1 | Signature manifestations | IQ-011 | OQ-SIG-001 | PQ-USER-002 | Signature record samples | ✅ |
| FDA-11.70 | 20-regulatory-compliance-matrix §1 | Signature/record linking | — | OQ-SIG-003, OQ-SIG-004 | — | Hash binding evidence, immutability test | ⚠️ G02 |
| FDA-11.100 | 20-regulatory-compliance-matrix §1 | Electronic signature requirements | — | OQ-SIG-001, OQ-SIG-002 | — | Re-auth test, signature creation evidence | ✅ |
| HIPAA-312(a) | 20-regulatory-compliance-matrix §2 | Access controls | IQ-002, IQ-007 | OQ-RBAC-001 through -006 | PQ-PERF-005 | RLS policies, RBAC tests, isolation tests | ✅ |
| HIPAA-312(e) | 20-regulatory-compliance-matrix §2 | Transmission security | IQ-006 | — | — | TLS scan report | ✅ |
| SOC2-CC6.1 | 20-regulatory-compliance-matrix §3 | Logical access security | IQ-002 | OQ-RBAC-001 through -006, OQ-RBAC-005 (SOD) | PQ-PERF-005 | RBAC + SOD + isolation tests | ✅ |
5.2 Coverage Summary
Requirement Coverage:
FDA 21 CFR Part 11: 9 requirements → 9 covered (100%)
HIPAA §164.312: 5 requirements → 5 covered (100%)
SOC 2 Trust Services: 4 requirements → 4 covered (100%)
Total: 18 requirements → 18 covered → 0 gaps
Test Coverage:
IQ tests: 14 (100% automated)
OQ tests: 22 (95% automated, 1 manual: OQ-SIG-001 re-auth UX)
PQ tests: 10 (80% automated, 2 manual: PQ-USER-001 journey, PQ-USER-002 compliance review)
Total: 46 test cases
6. Deviation Handling
6.1 Deviation Classification
| Class | Definition | Impact | Required Action | Approval |
|---|---|---|---|---|
| Critical | Test failure in compliance-critical function (audit trail, signatures, access control) | Cannot release | Root cause analysis → fix → re-test → re-approve | QA + Compliance Director |
| Major | Test failure in core functionality (state machine, RBAC) | Cannot release for affected function | Root cause → fix or workaround with compensating control → document → re-test | QA Manager |
| Minor | Test failure in non-critical function (reporting, notifications, UI) | Can release with documented limitation | Document → track in backlog → fix in next release | QA Manager |
| Observation | Test passed but revealed improvement opportunity | No impact | Document → add to backlog | Tester |
6.2 Deviation Record Template
## Deviation Report
Deviation ID: DEV-[PROTOCOL]-[TEST_ID]-[SEQ]
Test ID: [e.g., OQ-SIG-003]
Classification: ☐ Critical ☐ Major ☐ Minor ☐ Observation
Date Identified: [Date]
Identified by: [Name, Role]
Description:
[What happened, what was expected, what was observed]
Root Cause:
[Analysis of why the deviation occurred]
Impact Assessment:
Compliance impact: [Which regulatory requirements affected]
Functional impact: [What user-facing behavior is affected]
Data integrity: [Any risk to data accuracy or completeness]
Resolution:
☐ Fix applied (version: [X.Y.Z], commit: [hash])
☐ Compensating control implemented: [description]
☐ Accepted with documented limitation
☐ Deferred to release [X.Y.Z]
Re-test Results:
Re-test date: [Date]
Re-test result: ☐ Pass ☐ Fail (→ new deviation)
Evidence: [Link to re-test evidence]
Signatures:
Identified by: _________________________ Date: _________
Resolved by: _________________________ Date: _________
Approved by: _________________________ Date: _________
7. Evidence Package Format
7.1 Package Structure
evidence/
├── iq-[date]/
│ ├── MANIFEST.txt # File listing with SHA-256 hashes
│ ├── PROTOCOL.pdf # Signed IQ protocol (this template, filled)
│ ├── EXECUTION-RECORD.pdf # Signed execution record
│ ├── test-results/
│ │ ├── iq-001-schema-status.txt
│ │ ├── iq-002-rls-policies.txt
│ │ ├── iq-003-audit-immutability.txt
│ │ └── ...
│ └── TRACEABILITY-MATRIX.pdf # Requirement → test → evidence mapping
│
├── oq-[date]/
│ ├── MANIFEST.txt
│ ├── PROTOCOL.pdf
│ ├── EXECUTION-RECORD.pdf
│ ├── test-results/
│ │ ├── oq-sm-001-happy-path.json # API response captures
│ │ ├── oq-rbac-006-isolation.json # Cross-tenant isolation proof
│ │ └── ...
│ ├── screenshots/ # UI evidence (if applicable)
│ └── DEVIATION-LOG.pdf # Any deviations encountered
│
├── pq-[date]/
│ ├── MANIFEST.txt
│ ├── PROTOCOL.pdf
│ ├── EXECUTION-RECORD.pdf
│ ├── test-results/
│ │ ├── pq-perf-001-k6-report.html
│ │ ├── pq-perf-004-pg-stats.json
│ │ └── ...
│ ├── grafana-snapshots/ # Performance dashboard screenshots
│ └── DEVIATION-LOG.pdf
│
└── VALIDATION-SUMMARY.pdf # Overall validation summary + recommendation
7.2 Evidence Integrity
Every file in the evidence package:
- Has a SHA-256 hash recorded in MANIFEST.txt
- Is generated by automated tooling (not manually created) where possible
- Is timestamped with server time (not local time)
- Is immutable after generation (stored in write-once storage)
- Is associated with the specific system version under test
7.3 Evidence Retention
| Evidence Type | Retention Period | Storage | Access |
|---|---|---|---|
| IQ/OQ/PQ protocols | Life of system + 2 years | GCS (encrypted, write-once) | Compliance + Auditors |
| Test result files | Life of system + 2 years | GCS (encrypted, write-once) | Engineering + Compliance |
| Deviation reports | Life of system + 2 years | GCS (encrypted, write-once) | Compliance + Auditors |
| Validation summaries | Life of system + 5 years | GCS (encrypted, write-once) | All authorized roles |
8. Validation as a Customer Deliverable
8.1 Customer-Facing Validation Kit
Each customer's subscription includes access to a validation toolkit:
| Component | Starter | Professional | Enterprise |
|---|---|---|---|
| Pre-executed IQ evidence (CODITECT platform) | ✅ | ✅ | ✅ |
| OQ protocol template (pre-filled for tenant) | ✅ | ✅ | ✅ |
| Automated OQ execution (one-click) | ❌ | ✅ | ✅ |
| PQ protocol template | ❌ | ✅ | ✅ |
| Automated PQ execution | ❌ | ❌ | ✅ |
| Custom validation requirements mapping | ❌ | ❌ | ✅ |
| Validation consulting (hours) | 0 | 4 | 16 |
| Evidence package export (audit-ready PDF) | ❌ | ✅ | ✅ |
8.2 Revenue Impact
Validation capabilities are a key differentiator and revenue driver:
- Sales acceleration: Pre-validated platform reduces customer's validation effort by 80–85% (per 10-roi-quantification.md)
- Competitive moat: MasterControl and Veeva require customers to build their own IQ/OQ/PQ — CODITECT provides it as a service
- Upsell path: Starter → Professional (add automated OQ) → Enterprise (add automated PQ + custom validation)
- Evidence package export: $500/audit package (per 60-business-model.md §1.1)
9. Cross-Reference
| Topic | Primary Artifact | This Document Section |
|---|---|---|
| Regulatory requirement definitions | 20-regulatory-compliance-matrix.md | §5 traceability matrix (maps requirements → tests) |
| Test cases and automation | 65-testing-strategy.md §5 | §2–4 (formal protocol wrappers around test cases) |
| E-signature binding | 17-e-signature-architecture.md | §3.2.3 OQ-SIG tests |
| State machine transitions | 19-state-machine-with-guards.md | §3.2.1 OQ-SM tests |
| RBAC matrix | 22-rbac-permissions-matrix.md | §3.2.2 OQ-RBAC tests |
| Performance budgets | 65-testing-strategy.md §3, 66-operational-readiness.md §8 | §4.2 PQ-PERF tests |
| User journey timing | 68-user-experience-journeys.md §1.2 | §4.2 PQ-USER tests |
| Revenue impact | 60-business-model.md | §8.2 validation as revenue driver |
| Release management | 69-versioning-evolution-strategy.md §6 | §1.3 execution triggers |
In FDA-regulated environments, validation protocols are not optional documentation — they are the legal evidence that the system is fit for purpose. An auditor does not read your source code; they read your IQ/OQ/PQ protocols and evidence packages. This document is the most customer-visible technical artifact in the entire WO system corpus.
Copyright 2026 AZ1.AI Inc. All rights reserved. Developer: Hal Casteel, CEO/CTO Product: CODITECT-BIO-QMS | Part of the CODITECT Product Suite Classification: Internal - Confidential