Work Order QMS Module — CAPA Workflow Specification

Classification: Internal — Compliance Engineering
Date: 2026-02-13
Artifact: 74 of WO System Series
Status: Proposed
Source Artifacts: 58-gap-closure-prompts.md (G16), 16-prisma-data-model.md, 20-regulatory-compliance-matrix.md, 70-validation-protocol-templates.md §6

1. CAPA Overview

Corrective and Preventive Action (CAPA) is a core QMS process required by FDA 21 CFR Part 820 (Quality System Regulation), ISO 13485, and ICH Q10. In the WO system, CAPA connects non-conformances discovered during work order execution to systematic root cause analysis, corrective actions, preventive actions, and effectiveness verification.

1.1 CAPA vs. Deviation vs. Change Control

Concept	Scope	Trigger	Output
Deviation	Single event anomaly during validation	IQ/OQ/PQ test failure	Deviation report (70-validation-protocol-templates.md §6)
Change Control (WO)	Planned modification to validated system	Maintenance, upgrade, install	Work order lifecycle (12-sdd.md)
CAPA	Systemic issue requiring root cause + prevention	Recurring deviations, audit findings, complaints	CAPA record with corrective + preventive actions

A deviation may trigger a CAPA. A CAPA generates work orders for corrective and preventive actions. They are related but distinct processes.

1.2 Regulatory Requirements

Regulation	Section	CAPA Requirement
FDA 21 CFR 820	§820.90	Nonconforming product procedures
FDA 21 CFR 820	§820.198	Complaint files analysis
FDA 21 CFR 11	§11.10(e)	Audit trail for CAPA records
ISO 13485	§8.5.2	Corrective action
ISO 13485	§8.5.3	Preventive action
ICH Q10	§3.2	CAPA system as part of pharmaceutical quality system

2. CAPA Data Model

2.1 Prisma Schema Extension

model CAPARecord {
  id                  String          @id @default(cuid())
  tenantId            String          @map("tenant_id")
  capaNumber          String          @unique  // CAPA-YYYY-NNNN
  status              CAPAStatus      @default(INITIATED)
  classification      CAPAClass       // CORRECTIVE | PREVENTIVE | BOTH
  priority            Priority        // LOW | MEDIUM | HIGH | CRITICAL
  source              CAPASource      // DEVIATION | AUDIT_FINDING | COMPLAINT | TREND | AGENT_DETECTED
  
  // Problem description
  title               String
  description         String
  impactAssessment    String
  affectedSystems     String[]        // Asset IDs of affected validated systems
  affectedRegulations String[]        // FDA, HIPAA, SOC2, etc.
  
  // Root cause analysis
  rootCauseMethod     RootCauseMethod? // FIVE_WHY | FISHBONE | FAULT_TREE
  rootCauseAnalysis   String?
  rootCauseApprovedBy String?
  rootCauseApprovedAt DateTime?
  
  // Actions
  correctiveActions   CAPAAction[]    @relation("CorrectiveActions")
  preventiveActions   CAPAAction[]    @relation("PreventiveActions")
  
  // Effectiveness verification
  effectivenessMethod String?
  effectivenessDueDate DateTime?
  effectivenessResult String?
  effectivenessVerifiedBy String?
  effectivenessVerifiedAt DateTime?
  
  // Closure
  closedBy            String?
  closedAt            DateTime?
  closureJustification String?
  
  // Traceability
  sourceDeviationIds  String[]        // Deviation IDs that triggered this CAPA
  sourceWorkOrderIds  String[]        // WO IDs where issue was discovered
  sourceAuditFindingId String?        // External audit finding reference
  generatedWorkOrderIds String[]      // WO IDs created to implement CAPA actions
  
  // Metadata
  initiatedBy         String
  initiatedAt         DateTime        @default(now())
  updatedAt           DateTime        @updatedAt
  version             Int             @default(1)
  
  // Relations
  riskAssessment      RiskAssessment? @relation(fields: [riskAssessmentId], references: [id])
  riskAssessmentId    String?
  approvals           Approval[]
  auditTrail          AuditTrail[]

  @@index([tenantId, status])
  @@index([tenantId, capaNumber])
  @@index([tenantId, source])
  @@map("capa_records")
}

model CAPAAction {
  id                  String          @id @default(cuid())
  tenantId            String          @map("tenant_id")
  capaId              String
  type                CAPAActionType  // CORRECTIVE | PREVENTIVE
  sequence            Int
  description         String
  assigneeId          String
  dueDate             DateTime
  status              ActionStatus    @default(OPEN)  // OPEN | IN_PROGRESS | COMPLETED | VERIFIED
  completedAt         DateTime?
  workOrderId         String?         // Generated WO for this action
  evidenceAttached    Boolean         @default(false)
  verifiedBy          String?
  verifiedAt          DateTime?
  
  capa                CAPARecord      @relation(fields: [capaId], references: [id])

  @@index([tenantId, capaId])
  @@map("capa_actions")
}

model RiskAssessment {
  id                  String          @id @default(cuid())
  tenantId            String          @map("tenant_id")
  entityType          String          // "WorkOrder" | "CAPARecord"
  entityId            String
  assessedBy          String
  assessedAt          DateTime        @default(now())
  likelihood          Int             // 1-5
  impact              Int             // 1-5
  riskScore           Int             // likelihood × impact
  category            RiskCategory    // SAFETY | COMPLIANCE | OPERATIONAL | DATA_INTEGRITY
  mitigationPlan      String
  residualRisk        Int?
  signatureId         String?         // E-sig for high-risk assessments
  
  @@index([tenantId, entityType, entityId])
  @@map("risk_assessments")
}

enum CAPAStatus {
  INITIATED
  ROOT_CAUSE_ANALYSIS
  ACTION_PLANNING
  IN_PROGRESS
  EFFECTIVENESS_PENDING
  CLOSED
  CLOSED_INEFFECTIVE     // Effectiveness check failed — re-open
}

enum CAPAClass {
  CORRECTIVE
  PREVENTIVE
  BOTH
}

enum CAPASource {
  DEVIATION
  AUDIT_FINDING
  COMPLAINT
  TREND
  AGENT_DETECTED
}

enum RootCauseMethod {
  FIVE_WHY
  FISHBONE
  FAULT_TREE
}

enum RiskCategory {
  SAFETY
  COMPLIANCE
  OPERATIONAL
  DATA_INTEGRITY
}

3. CAPA State Machine

3.1 State Diagram

INITIATED
    │
    ▼  (risk assessment completed)
ROOT_CAUSE_ANALYSIS
    │
    ▼  (root cause approved by QA)
ACTION_PLANNING
    │
    ▼  (all actions assigned, WOs generated)
IN_PROGRESS
    │
    ▼  (all corrective + preventive actions completed)
EFFECTIVENESS_PENDING
    │
    ├──► CLOSED                 (effectiveness verified)
    │
    └──► CLOSED_INEFFECTIVE     (effectiveness check failed)
             │
             └──► INITIATED     (re-opened with reference to previous CAPA)

3.2 Transition Guards

Transition	Guard	Failure Action
INITIATED → ROOT_CAUSE_ANALYSIS	Risk assessment exists; severity ≥ threshold for CAPA	Block; request risk assessment
ROOT_CAUSE_ANALYSIS → ACTION_PLANNING	Root cause documented; root cause approved by QA (e-signature for regulatory)	Block; request QA approval
ACTION_PLANNING → IN_PROGRESS	≥ 1 corrective action defined; all actions have assignees and due dates; WOs generated for each action	Block; complete action planning
IN_PROGRESS → EFFECTIVENESS_PENDING	All corrective actions completed; all preventive actions completed	Block; show incomplete actions
EFFECTIVENESS_PENDING → CLOSED	Effectiveness verification documented; verified by QA (e-signature)	Block; request verification
EFFECTIVENESS_PENDING → CLOSED_INEFFECTIVE	Effectiveness check performed but failed	Auto-generates new CAPA referencing this one

3.3 Approval Requirements

CAPA Priority	Root Cause Approval	Closure Approval	Escalation
LOW	QA Manager	QA Manager	None
MEDIUM	QA Manager	QA Manager + System Owner	30-day overdue → QA Director
HIGH	QA Director	QA Director + System Owner	14-day overdue → VP Quality
CRITICAL	QA Director + VP Quality	VP Quality + Executive	7-day overdue → CEO

4. CAPA-to-Work-Order Integration

4.1 Automatic WO Generation

When CAPA transitions to IN_PROGRESS, the system generates work orders for each corrective and preventive action:

function generateCAPAWorkOrders(capa: CAPARecord): WorkOrder[] {
  const workOrders: WorkOrder[] = [];
  
  for (const action of [...capa.correctiveActions, ...capa.preventiveActions]) {
    workOrders.push({
      type: action.type === 'CORRECTIVE' ? 'CORRECTIVE' : 'PREVENTIVE',
      regulatory: true,                    // All CAPA-generated WOs are regulatory
      priority: capa.priority,
      title: `CAPA ${capa.capaNumber} - ${action.description.substring(0, 100)}`,
      description: action.description,
      masterId: null,                      // CAPA WOs are standalone unless explicitly linked
      metadata: {
        capaId: capa.id,
        capaNumber: capa.capaNumber,
        capaActionId: action.id,
        capaActionType: action.type,
      },
      scheduledEnd: action.dueDate,
    });
  }
  
  return workOrders;
}

4.2 Bidirectional Traceability

CAPA Record ──► generates ──► Work Order(s)
     ▲                              │
     │                              ▼
     └──── references ◄──── WO Audit Trail
     
Deviation Report ──► triggers ──► CAPA Record
     ▲                              │
     │                              ▼
     └── discovered in ◄──── Original Work Order

Every CAPA-generated WO carries metadata.capaId and metadata.capaActionId, enabling traceability from WO back to CAPA. The CAPA record maintains generatedWorkOrderIds[] for forward traceability.

4.3 CAPA Dashboard Metrics

Metric	Definition	Target	Regulatory Basis
CAPA open count	Total CAPAs not in CLOSED status	< 20 at any time	FDA expectation: manageable backlog
CAPA on-time closure rate	CAPAs closed by original due date / total closed	> 90%	FDA 483 trigger if consistently low
Average CAPA age	Mean days from INITIATED to CLOSED	< 60 days	Industry benchmark
Effectiveness rate	CAPAs closed as CLOSED (not CLOSED_INEFFECTIVE) / total closed	> 85%	ISO 13485 §8.5
CAPA recurrence rate	New CAPAs from same root cause as previous CAPA	< 5%	Measures preventive action effectiveness

5. Risk Assessment Integration

5.1 Risk Matrix

              Impact
        1    2    3    4    5
    ┌────┬────┬────┬────┬────┐
  5 │  5 │ 10 │ 15 │ 20 │ 25 │  ← Critical: Executive approval
    ├────┼────┼────┼────┼────┤
  4 │  4 │  8 │ 12 │ 16 │ 20 │
    ├────┼────┼────┼────┼────┤
L 3 │  3 │  6 │  9 │ 12 │ 15 │  ← High: QA Director required
    ├────┼────┼────┼────┼────┤
  2 │  2 │  4 │  6 │  8 │ 10 │
    ├────┼────┼────┼────┼────┤
  1 │  1 │  2 │  3 │  4 │  5 │  ← Low: Standard process
    └────┴────┴────┴────┴────┘

5.2 Risk-Based Routing

Risk Score	CAPA Required	Approval Level	Timeline
1–6 (Low)	Optional; deviation report may suffice	QA Manager	90 days
7–12 (Medium)	Required	QA Manager + System Owner	60 days
13–19 (High)	Required, priority escalation	QA Director + System Owner	30 days
20–25 (Critical)	Required, immediate action	VP Quality + Executive	14 days

5.3 Agent-Detected CAPAs

CODITECT agents can detect patterns that warrant CAPA initiation:

Pattern	Detection Method	Auto-Action
Same deviation type ≥ 3 times in 90 days	Agent trend analysis on deviation reports	Auto-initiate CAPA (source: TREND)
WO completion variance > 200% from estimate	Schedule tracking analysis	Flag for risk assessment
Compliance guard failure rate > 5% for an asset	Compliance engine metrics	Auto-initiate CAPA (source: AGENT_DETECTED)
Certification expiry affecting active WOs	Resource monitoring	Auto-generate preventive WO

Agent-initiated CAPAs require human approval before progressing past INITIATED status. The agent populates the initial risk assessment and suggests root cause categories, but a human (QA role minimum) must approve.

6. Root Cause Analysis Methods

6.1 Five Whys Template

## Five Whys Analysis — CAPA-2026-0042

Problem Statement: [Description of the non-conformance]

Why 1: [First-level cause]
  Evidence: [Data, observations, records]

Why 2: [Second-level cause]
  Evidence: [Data, observations, records]

Why 3: [Third-level cause]
  Evidence: [Data, observations, records]

Why 4: [Fourth-level cause]
  Evidence: [Data, observations, records]

Why 5: [Root cause identified]
  Evidence: [Data, observations, records]

Root Cause Statement: [Concise statement of the root cause]
Root Cause Category: [HUMAN_ERROR | PROCESS_GAP | EQUIPMENT_FAILURE | DESIGN_DEFICIENCY | TRAINING_GAP]

6.2 Fishbone (Ishikawa) Categories

For WO system context:

Category	Example Causes
People	Training gaps, certification expired, unfamiliar with SOP
Process	SOP outdated, approval chain misconfigured, guard logic incorrect
Technology	System bug, integration failure, model routing error
Equipment	Calibration drift, tool failure, environment misconfigured
Materials	Wrong version of reagent, expired supplies
Measurement	Incorrect test criteria, monitoring gap, metric miscalculation

7. CAPA Events

Events emitted per 73-event-catalog.md pattern:

Event	Trigger	Consumers
`capa.initiated`	CAPA record created	Audit Writer, Notification (QA alert), Metrics
`capa.root_cause_approved`	QA approves root cause analysis	Audit Writer, Notification (assignees)
`capa.action_assigned`	Individual action assigned to person	Notification (assignee), WO Generator
`capa.work_orders_generated`	WOs created for CAPA actions	Agent Orchestrator, Notification
`capa.effectiveness_verified`	Effectiveness check completed	Audit Writer, Notification (QA)
`capa.closed`	CAPA reaches CLOSED status	Audit Writer, Metrics, Webhook
`capa.closed_ineffective`	Effectiveness check failed	Audit Writer, Notification (escalation), Auto-reopen

8. API Endpoints

Per 71-api-endpoint-specification.md pattern:

POST   /v1/capas                           # Initiate CAPA
GET    /v1/capas/:id                        # Get CAPA record
GET    /v1/capas                            # List CAPAs (filtered)
PATCH  /v1/capas/:id/status                 # Transition CAPA status
PUT    /v1/capas/:id/root-cause             # Submit root cause analysis
POST   /v1/capas/:id/actions                # Add corrective/preventive action
PATCH  /v1/capas/:id/actions/:actionId      # Update action status
PUT    /v1/capas/:id/effectiveness           # Submit effectiveness verification
GET    /v1/capas/:id/audit-trail            # CAPA audit trail
GET    /v1/capas/metrics                     # CAPA dashboard metrics

POST   /v1/work-orders/:id/risk-assessment  # Create risk assessment (from 71)
GET    /v1/work-orders/:id/risk-assessment  # Get risk assessment (from 71)

9. Compliance Traceability

FDA Requirement	CAPA Implementation	Evidence
§820.90(a) — Procedures for nonconforming product	CAPA state machine with mandatory guards	State machine specification, guard test results
§820.90(b) — Disposition of nonconforming product	Risk assessment determines CAPA classification and timeline	Risk assessment records, audit trail
§820.198 — Complaint investigation	CAPA source: COMPLAINT; traceability to original complaint	CAPA record with `sourceAuditFindingId`
§11.10(e) — Audit trail	All CAPA state changes, approvals, and actions audited	Append-only audit trail entries
§11.50 — Signature manifestations	QA approval of root cause and effectiveness via e-signature	ElectronicSignature records

10. Cross-Reference

Concern	Specification Source
Gap G16 (original identification)	58-gap-closure-prompts.md
Data model (base WO entities)	16-prisma-data-model.md
State machine pattern	19-state-machine-with-guards.md
E-signature for approvals	17-e-signature-architecture.md
Deviation handling (validation)	70-validation-protocol-templates.md §6
Risk assessment API	71-api-endpoint-specification.md §8
CAPA events	73-event-catalog.md
Compliance matrix	20-regulatory-compliance-matrix.md
Agent detection patterns	25-agent-orchestration-spec.md
RBAC for CAPA operations	22-rbac-permissions-matrix.md (extend for CAPA roles)

CAPA is not optional in FDA-regulated environments — it's the process that transforms individual failures into systemic improvements. An auditor's first question after finding a deviation is "where's the CAPA?" This specification ensures CODITECT can answer that question with full traceability, electronic signatures, and an immutable audit trail.

1. CAPA Overview​

1.1 CAPA vs. Deviation vs. Change Control​

1.2 Regulatory Requirements​

2. CAPA Data Model​

2.1 Prisma Schema Extension​

3. CAPA State Machine​

3.1 State Diagram​

3.2 Transition Guards​

3.3 Approval Requirements​

4. CAPA-to-Work-Order Integration​

4.1 Automatic WO Generation​

4.2 Bidirectional Traceability​

4.3 CAPA Dashboard Metrics​

5. Risk Assessment Integration​

5.1 Risk Matrix​

5.2 Risk-Based Routing​

5.3 Agent-Detected CAPAs​

6. Root Cause Analysis Methods​

6.1 Five Whys Template​

6.2 Fishbone (Ishikawa) Categories​

7. CAPA Events​

8. API Endpoints​

9. Compliance Traceability​

10. Cross-Reference​