Jira Event Management User Manual

1. Purpose & Scope

1.1 Purpose

The purpose of the Jira Event Management (QMS) process is to provide a controlled, consistent, and compliant mechanism for identifying, documenting, evaluating, escalating, and closing quality-related exception events that may impact:

Jira Event Management serves as the system of record for quality exceptions and Quality Assurance (QA) decision-making, including formal escalation to CAPA and Change Control when required.

This process ensures that:

1.2 Scope

1.2.1 In Scope

This process applies to all personnel and functions involved in GMP-related activities, including but not limited to:

The Jira Event Management process applies whenever an observable condition, signal, or finding indicates a potential deviation from expected controls, approved procedures, or regulatory requirements.

1.2.2 Out of Scope

2. System Boundary

2.1 Design Principle

The Jira Event Management system is intentionally designed to separate routine execution evidence from quality exception evaluation and decision-making.

Foundational Rule:
Jira captures exceptions and decisions. Execution systems capture routine work.

2.2 Routine Execution Logs (Outside Jira)

Routine Execution Logs document the performance of routine operational or oversight activities. These logs may be paper-based or electronic and may reside in systems such as:

Routine Execution Logs serve as evidence that work occurred. They are not used to document quality decisions.

2.3 Quality Events (Inside Jira)

A Quality Event is created in Jira when a Routine Execution Log or direct observation identifies an exception signal.

2.4 Escalation Boundary

Universal Escalation Principle:
If a Routine Execution Log identifies a condition outside expected controls, a Jira Quality Event must be created.

2.5 Explicit Exclusions

Inspection Narrative:
Routine work is documented where it is performed. Jira documents the response when something goes wrong.

3. Jira Work Types

(To be completed in next iteration)

Appendix A – Routine Execution Logs

(To be completed in later iterations)

Document Status: Draft – In Controlled Development

3. Jira Work Types

Jira Event Management uses three standardized work types to manage quality-related activities. These work types are intentionally limited to ensure clarity, consistency, and regulatory compliance.

Design Principle:
All quality-related activity in Jira begins with a Quality Event. CAPA and Change Control are controlled responses, not intake mechanisms.
---

3.1 Quality Event

A Quality Event represents an observable exception signal that may impact product quality, material status, data integrity, safety, or regulatory compliance.

A Quality Event answers the question:

“Something unexpected happened — should Quality Assurance review this?”

Who Creates a Quality Event

What a Quality Event Is

What a Quality Event Is NOT

Uncertainty Rule:
If you are unsure whether something matters, create a Quality Event.
---

3.2 CAPA (Corrective and Preventive Action)

A CAPA is used to address systemic, repeat, or high-risk issues identified through Quality Events.

Who Creates CAPA

When CAPA Is Used

CAPAs are always:

Key Rule:
CAPA is never created directly by Operations or as a first response.
---

3.3 Change Control

Change Control manages intentional changes that may affect quality, safety, or compliance.

Who Creates Change Control

When Change Control Is Used

Change Controls ensure that changes are:

Relationship Summary:
Quality Event → identifies the problem
CAPA → fixes the system
Change Control → implements controlled change

4. When to Create a Quality Event

A Quality Event must be created whenever an observable condition, signal, or finding indicates that activities, materials, systems, or data are not operating as expected.

This section defines objective decision rules to ensure that Quality Events are raised consistently and without reliance on individual judgment.

---

4.1 Mandatory Creation Criteria

A Quality Event must be created when any of the following occur:

---

4.2 Uncertainty Rule

Uncertainty Rule:
If you are unsure whether an issue matters, create a Quality Event.

Users are not expected to determine impact, root cause, or regulatory significance at intake.

That responsibility belongs to Quality Assurance.

---

4.3 What Does NOT Require a Quality Event

A Quality Event is not required for routine activities when:

Routine execution with no findings is documented in Routine Execution Logs, not Jira.
---

4.4 Walkthroughs, Inspections, and Reviews

Routine walkthroughs, inspections, and oversight activities are documented using Routine Execution Logs.

There is no requirement to create a Quality Event to document that a walkthrough or inspection occurred.

---

4.5 Multiple Observations

If multiple issues are observed during the same activity:

Quality Assurance will determine whether additional events are required during review.

---

4.6 User Responsibilities at Intake

When creating a Quality Event, users are responsible for:

Important:
Do not attempt to determine root cause or corrective actions when creating a Quality Event.
---

4.7 Summary Decision Statement

If something unexpected happened and QA may need to evaluate it, a Quality Event is required.

5. Quality Event Classification Model

Each Quality Event must be classified using a three-layer model to ensure consistent interpretation, trending, escalation, and regulatory reporting.

The classification model separates:

Key Principle:
Classification supports QA evaluation and trending. It does not determine severity or outcome.
---

5.1 Event Category (Required)

The Event Category defines the regulatory meaning of the issue.

Exactly one Event Category must be selected. QA may update the category during review.

Users should select the category that best fits the observation. QA will confirm or adjust as needed.
---

5.2 BPO Domain (Required)

The BPO Domain identifies the business process owner responsible for the area where the event occurred.

Exactly one BPO Domain must be selected.

The BPO Domain supports accountability and trending. It does not assign blame.
---

5.3 Quality Event Sub-Type (Required)

The Quality Event Sub-Type identifies the specific exception signal that triggered the Quality Event.

Only one Sub-Type may be selected. If multiple conditions are observed, select the primary signal and describe secondary observations in the Description.

Sub-Types are controlled lists aligned to process-family Operational Guides.

Sub-Type Rules:
---

5.4 Example Classification

Scenario: Returned product received with damaged packaging.

QA will determine disposition, escalation, and final classification.

---

5.5 Common Classification Mistakes to Avoid

Reminder:
Classification supports QA review. It does not drive outcome.

6. QA / QC Activities & Segregation of Duties

Quality Assurance (QA) and Quality Control (QC) play distinct but coordinated roles within the Jira Event Management process. This section defines how QA and QC activities are documented, escalated, and controlled to ensure independent oversight and regulatory compliance.

---

6.1 Role of Quality Control (QC)

Quality Control personnel perform routine testing, monitoring, and oversight activities as part of normal operations.

QC activities are documented through Routine Execution Logs, which may include:

QC is responsible for identifying and escalating any exception signal observed during routine activities.

QC does not determine final impact, root cause, or disposition. QC identifies and escalates signals.
---

6.2 Role of Quality Assurance (QA)

Quality Assurance is responsible for independent evaluation, decision-making, and disposition of Quality Events.

QA responsibilities include:

QA may identify Quality Events through routine oversight activities, walkthroughs, audits, or reviews.

---

6.3 QA and QC Findings

Findings identified by QA or QC during routine oversight are handled the same way as findings identified by Operations.

There is no exemption from Quality Event creation based on role. All exception signals require QA evaluation.
---

6.4 Segregation of Duties (SoD)

Segregation of Duties is enforced to ensure that no individual can identify, evaluate, and approve the same quality issue.

The following controls apply:

Segregation Rule:
QA personnel may not self-approve events they initiate.
---

6.5 Event Source vs. Jira Reporter

The Event Source identifies who observed or identified the exception signal.

This may differ from the Jira Reporter, who created the record.

This distinction supports:

---

6.6 QA Oversight Activities

Routine QA oversight activities (e.g., walkthroughs, audits, reviews) are documented using Routine Execution Logs.

Jira documents QA decisions, not the performance of oversight activities.
---

6.7 Summary Principles

7. What Happens After Submission

Once a Quality Event is submitted in Jira, it enters a QA-controlled workflow. This workflow ensures that all exception signals are consistently reviewed, evaluated, and appropriately dispositioned.

Users are not expected to manage events after submission. All post-submission actions are governed by Quality Assurance.

---

7.1 Standard Workflow Overview

All Quality Events, CAPAs, and Change Controls use a common QA-controlled workflow.

Status Purpose Primary Owner
Submitted Event formally logged and awaiting QA review QA
Under QA Review QA evaluation and impact assessment QA
QA Dispositioned QA decision documented QA
Closed Event completed and approved QA
All workflow transitions beyond Submitted are restricted to QA roles.
---

7.2 QA Review Activities

During Under QA Review, QA performs an independent evaluation, which may include:

QA may request additional information from the originator or subject matter experts as needed.

---

7.3 QA Disposition Options

Following evaluation, QA documents a disposition decision. Possible outcomes include:

Disposition decisions are documented by QA and form part of the permanent quality record.
---

7.4 Escalation to CAPA or Change Control

When escalation is required:

The original Quality Event remains open until escalation linkage and initial disposition are complete.

---

7.5 Closure Criteria

A Quality Event may be closed only when:

Only authorized QA personnel may close Quality Events.
---

7.6 User Notifications and Follow-Up

Users may receive notifications when:

Users are not required to take further action unless contacted by QA.

---

7.7 Key Principles

8. CAPA Lifecycle Overview

Corrective and Preventive Action (CAPA) records are used to address systemic, repeat, or high-risk issues identified through Quality Events. CAPA is not an intake mechanism; it is a controlled response initiated by Quality Assurance (QA).

Key Principle:
Quality Events identify problems. CAPAs correct and prevent recurrence.
---

8.1 When a CAPA Is Required

A CAPA may be initiated by QA when one or more of the following conditions exist:

CAPA initiation is a QA decision based on evaluation of one or more Quality Events.

---

8.2 CAPA Initiation

CAPAs are created only by authorized QA personnel.

CAPA records must not be created directly by Operations or as a first response to an issue.
---

8.3 Investigation and Root Cause

When required, a formal investigation is conducted to identify the true root cause of the issue.

QA determines:

Root cause analysis focuses on system failures, not individual error.

---

8.4 Corrective and Preventive Actions

Based on investigation outcomes, QA defines:

Actions must be:

---

8.5 Effectiveness Verification

CAPAs require verification that actions taken were effective.

Effectiveness checks may include:

CAPA closure is not permitted until effectiveness has been verified.
---

8.6 CAPA Closure

A CAPA may be closed only when:

CAPA closure represents QA confirmation that the system has been brought back into control.

---

8.7 Relationship to Change Control

If implementation of corrective or preventive actions requires a controlled change, a Change Control record is initiated and linked to the CAPA.

CAPA identifies what must change. Change Control governs how the change is implemented.

9. Change Control Lifecycle Overview

Change Control records are used to manage intentional, planned changes that may impact product quality, safety, data integrity, or regulatory compliance.

Change Control ensures that changes are evaluated, approved, implemented, and verified in a controlled and documented manner.

Key Principle:
Change Control governs intentional change.
It is not a mechanism for responding to unexpected events.
---

9.1 When Change Control Is Required

A Change Control record is required when a proposed change may affect:

Change Control may be initiated as:

---

9.2 Change Control Initiation

Change Controls are created only by authorized Quality Assurance / Quality Systems personnel.

Change Control must not be initiated after a change has already been implemented.
---

9.3 Risk Assessment

QA performs or coordinates a risk assessment to evaluate the potential impact of the proposed change.

Risk assessment may consider:

The outcome of the risk assessment determines the required level of control and verification.

---

9.4 Approval and Implementation

Changes must be approved by QA and other designated stakeholders prior to implementation.

Implementation activities may include:

No change may be implemented without documented approval.
---

9.5 Verification and Closure

After implementation, QA verifies that:

A Change Control may be closed only when QA confirms successful implementation and verification.

---

9.6 Relationship to Quality Events and CAPA

These three work types function together to maintain a controlled, compliant quality system.

Appendix A — Routine Execution Logs

Routine Execution Logs document the performance of routine operational or oversight activities. These logs may be paper-based or system-based and are maintained outside of Jira.

Universal Escalation Rule:
If any Routine Execution Log identifies a condition outside expected controls, a Jira Quality Event must be created.
---

Warehouse (WH)

WH-01 Receiving Inspection Log

Purpose:
Document verification that incoming materials meet identity, condition, and documentation requirements at receipt.

Scope:
All GMP materials received from suppliers or internal transfers.

Control Addressed:
Prevents introduction of damaged, incorrect, or undocumented materials into inventory.

Bare Minimum Fields:

---

WH-02 Returned Product Log

Purpose:
Document receipt, control, and segregation of returned finished goods.

Scope:
All finished goods returned after release or distribution.

Control Addressed:
Prevents reintroduction of potentially compromised product.

Bare Minimum Fields:

---

WH-03 Storage Condition Log

Purpose:
Verify that storage conditions remain within defined environmental limits.

Scope:
All temperature- or humidity-controlled warehouse storage areas.

Control Addressed:
Prevents material or product degradation due to environmental excursions.

Bare Minimum Fields:

---

WH-04 Material Status & Segregation Check Log

Purpose:
Confirm that materials are stored in locations consistent with their approved status.

Scope:
Quarantine, Released, Rejected, and Hold storage areas.

Control Addressed:
Prevents unintended use or distribution of non-released material.

Bare Minimum Fields:

---

WH-05 Inventory Reconciliation / Cycle Count Log

Purpose:
Verify that physical inventory matches system inventory records.

Scope:
Materials subject to periodic inventory reconciliation or cycle counting.

Control Addressed:
Detects loss, mislabeling, undocumented movement, or data discrepancies.

Bare Minimum Fields:

---

WH-06 Material Handling Equipment Inspection Log

Purpose:
Verify that material handling equipment is fit for use in GMP areas.

Scope:
Forklifts, pallet jacks, and other handling equipment used for GMP materials.

Control Addressed:
Prevents material damage and safety incidents during handling.

Bare Minimum Fields:

Manufacturing (MFG)

MFG-01 Batch Production Record Log

Purpose:
Document execution of manufacturing steps in accordance with approved batch records.

Scope:
All GMP manufacturing batches.

Control Addressed:
Ensures traceability and documented execution of approved manufacturing processes.

Bare Minimum Fields:

---

MFG-02 In-Process Control (IPC) Log

Purpose:
Verify critical process parameters meet defined acceptance criteria during manufacturing.

Scope:
Defined in-process control points for manufacturing operations.

Control Addressed:
Detects process drift or loss of control prior to batch completion.

Bare Minimum Fields:

---

MFG-03 Equipment Pre-Use / Post-Use Check Log

Purpose:
Confirm manufacturing equipment is suitable for use before and after production activities.

Scope:
All GMP manufacturing equipment.

Control Addressed:
Prevents cross-contamination and equipment-related deviations.

Bare Minimum Fields:

---

MFG-04 Line Clearance Log

Purpose:
Verify removal of materials, labels, and documents from previous operations.

Scope:
All manufacturing line changeovers.

Control Addressed:
Prevents product mix-ups and cross-contamination.

Bare Minimum Fields:

---

MFG-05 Shift / Process Observation Log

Purpose:
Document abnormal observations identified during manufacturing operations.

Scope:
All manufacturing shifts.

Control Addressed:
Ensures abnormal conditions are not overlooked.

Bare Minimum Fields:

---

Packaging (PKG)

PKG-01 Packaging Batch Record Log

Purpose:
Document execution of packaging operations in accordance with approved packaging records.

Scope:
All GMP packaging batches.

Control Addressed:
Ensures traceability and documented execution of approved packaging processes.

Bare Minimum Fields:

---

PKG-02 Packaging Line Clearance Log

Purpose:
Verify removal of prior materials, labels, and components from packaging lines.

Scope:
All packaging line changeovers.

Control Addressed:
Prevents labeling errors and product mix-ups.

Bare Minimum Fields:

---

PKG-03 Label Control / Reconciliation Log

Purpose:
Verify control and reconciliation of printed packaging materials.

Scope:
All printed labels and packaging components.

Control Addressed:
Prevents mislabeling and labeling discrepancies.

Bare Minimum Fields:

---

PKG-04 Packaging In-Process Check Log

Purpose:
Verify critical packaging parameters meet requirements during operations.

Scope:
Defined in-process checks during packaging.

Control Addressed:
Detects packaging errors prior to batch completion.

Bare Minimum Fields:

Laboratory / Quality Control (LAB)

LAB-01 Sample Receipt & Chain-of-Custody Log

Purpose:
Document receipt, identification, and custody of laboratory samples.

Scope:
All GMP samples received for testing.

Control Addressed:
Prevents sample mix-ups, loss, or undocumented handling.

Bare Minimum Fields:

---

LAB-02 Laboratory Test Execution Log

Purpose:
Document execution of laboratory testing per approved methods.

Scope:
All GMP analytical testing activities.

Control Addressed:
Ensures traceable and compliant execution of test methods.

Bare Minimum Fields:

---

LAB-03 Instrument Usage & Calibration Status Log

Purpose:
Verify laboratory instruments are qualified and within calibration.

Scope:
All laboratory instruments used for GMP testing.

Control Addressed:
Prevents generation of invalid analytical data.

Bare Minimum Fields:

---

LAB-04 Method Verification / Suitability Log

Purpose:
Confirm analytical methods perform as expected when used.

Scope:
Method verification, transfers, or suitability checks.

Control Addressed:
Ensures analytical methods produce reliable results.

Bare Minimum Fields:

---

LAB-05 Test Result Review Log

Purpose:
Document independent review of laboratory test results.

Scope:
All GMP analytical results.

Control Addressed:
Ensures accuracy, completeness, and independent oversight.

Bare Minimum Fields:

---

Environmental Monitoring (EM)

EM-01 EM Sampling Schedule Log

Purpose:
Document completion of scheduled environmental monitoring activities.

Scope:
All environmental monitoring programs and locations.

Control Addressed:
Ensures environmental monitoring is performed as required.

Bare Minimum Fields:

---

EM-02 EM Sample Collection Log

Purpose:
Document collection and identification of EM samples.

Scope:
All EM sample types (air, surface, personnel, utilities).

Control Addressed:
Ensures traceability and integrity of EM samples.

Bare Minimum Fields:

---

EM-03 EM Result Review & Trending Log

Purpose:
Document review and trending of environmental monitoring results.

Scope:
Periodic EM data review.

Control Addressed:
Detects loss of environmental control or adverse trends.

Bare Minimum Fields:

---

EM-04 EM Alert / Action Level Response Log

Purpose:
Document response to EM alert or action level excursions.

Scope:
All EM results exceeding defined limits.

Control Addressed:
Ensures timely response to contamination risk.

Bare Minimum Fields:

Facility (FAC)

FAC-01 Facility Walkthrough / Inspection Log

Purpose:
Document routine facility walkthroughs to identify conditions that may impact product quality, safety, or compliance.

Scope:
All GMP and GMP-adjacent facility areas.

Control Addressed:
Detects facility-related risks before they impact operations or product.

Bare Minimum Fields:

If a condition of concern is observed, a Jira Quality Event is required.
---

FAC-02 Utility Monitoring Log

Purpose:
Verify utilities supporting GMP operations remain within defined limits.

Scope:
Utilities such as HVAC, water, compressed air, and power.

Control Addressed:
Prevents utility failures from impacting product quality.

Bare Minimum Fields:

---

FAC-03 Facility Maintenance Execution Log

Purpose:
Document completion of planned or corrective facility maintenance.

Scope:
Facility maintenance activities affecting GMP areas.

Control Addressed:
Ensures maintenance activities are traceable and completed as required.

Bare Minimum Fields:

---

FAC-04 Pest Control Monitoring Log

Purpose:
Document pest control monitoring and inspection activities.

Scope:
All pest control devices and monitored areas.

Control Addressed:
Prevents pest-related contamination risks.

Bare Minimum Fields:

---

Sanitation (SAN)

SAN-01 Sanitation Execution Log

Purpose:
Document completion of routine sanitation activities.

Scope:
Cleaning and sanitation of GMP areas and equipment.

Control Addressed:
Prevents contamination through effective sanitation.

Bare Minimum Fields:

---

SAN-02 Sanitation Chemical Preparation Log

Purpose:
Verify correct preparation and use of sanitation chemicals.

Scope:
All sanitation chemical preparations.

Control Addressed:
Ensures effective and safe sanitation practices.

Bare Minimum Fields:

---

SAN-03 Sanitation Verification / Inspection Log

Purpose:
Verify effectiveness of sanitation activities.

Scope:
Post-cleaning inspections and verification checks.

Control Addressed:
Confirms sanitation meets acceptance criteria.

Bare Minimum Fields:

---

SAN-04 Sanitation Deviation / Observation Log

Purpose:
Document sanitation-related observations or deviations.

Scope:
All sanitation activities and inspections.

Control Addressed:
Ensures sanitation issues are identified and escalated.

Bare Minimum Fields:

Sanitation deviations or concerns require escalation to a Jira Quality Event.

IT / Data Integrity (IT)

IT-01 System Access Review Log

Purpose:
Document periodic review of user access to GMP-relevant computerized systems.

Scope:
All GMP-impacting systems (e.g., ERP, LIMS, EM, CMMS).

Control Addressed:
Prevents unauthorized access and supports data integrity controls.

Bare Minimum Fields:

---

IT-02 Audit Trail Review Log

Purpose:
Document review of audit trails for GMP-relevant systems.

Scope:
Defined audit trail review periods and systems.

Control Addressed:
Detects unauthorized or inappropriate data changes.

Bare Minimum Fields:

---

IT-03 System Backup & Recovery Verification Log

Purpose:
Verify successful backup and recovery controls for GMP systems.

Scope:
All GMP-impacting computerized systems.

Control Addressed:
Ensures data availability and integrity.

Bare Minimum Fields:

---

IT-04 System Incident / Outage Log

Purpose:
Document system incidents or outages affecting GMP activities.

Scope:
All GMP-impacting system interruptions.

Control Addressed:
Ensures system-related risks are identified and escalated.

Bare Minimum Fields:

System incidents impacting GMP activities require escalation to a Jira Quality Event.
---

Supplier Quality (SUP)

SUP-01 Supplier Receipt / Performance Review Log

Purpose:
Document ongoing review of supplier performance.

Scope:
Approved suppliers providing GMP materials or services.

Control Addressed:
Detects supplier-related quality risks.

Bare Minimum Fields:

---

SUP-02 Supplier Documentation Review Log

Purpose:
Verify supplier documentation remains current and approved.

Scope:
COAs, specifications, agreements, and quality documents.

Control Addressed:
Ensures supplier documentation supports material acceptance.

Bare Minimum Fields:

---

SUP-03 Supplier Change Notification Log

Purpose:
Document receipt and review of supplier change notifications.

Scope:
All supplier-initiated changes affecting GMP materials or services.

Control Addressed:
Ensures supplier changes are assessed prior to impact.

Bare Minimum Fields:

Supplier changes impacting quality require escalation to QA and may require Change Control.
---

SUP-04 Supplier Audit / Assessment Log

Purpose:
Document completion of supplier audits or assessments.

Scope:
All supplier qualification and monitoring activities.

Control Addressed:
Ensures suppliers meet quality requirements.

Bare Minimum Fields:

---

Safety (SAFE)

SAFE-01 Safety Walkthrough / Inspection Log

Purpose:
Document routine safety inspections and observations.

Scope:
All facility areas and activities.

Control Addressed:
Identifies safety risks before injury occurs.

Bare Minimum Fields:

---

SAFE-02 Safety Incident / Near Miss Log

Purpose:
Document safety incidents or near misses.

Scope:
All safety-related events.

Control Addressed:
Ensures safety risks are identified and addressed.

Bare Minimum Fields:

Safety incidents with GMP impact require escalation to a Jira Quality Event.
---

SAFE-03 Safety Training Verification Log

Purpose:
Verify completion of required safety training.

Scope:
All personnel subject to safety training requirements.

Control Addressed:
Ensures personnel are trained for safe operations.

Bare Minimum Fields:

---

Security (SEC)

SEC-01 Facility Access Control Log

Purpose:
Document control of access to GMP and restricted areas.

Scope:
All access-controlled facility areas.

Control Addressed:
Prevents unauthorized access to GMP operations.

Bare Minimum Fields:

---

SEC-02 Visitor / Contractor Log

Purpose:
Document visitor and contractor access to the facility.

Scope:
All visitors and contractors.

Control Addressed:
Ensures controlled and traceable access.

Bare Minimum Fields:

---

SEC-03 Security Incident Log

Purpose:
Document security-related incidents.

Scope:
All security events impacting the facility or systems.

Control Addressed:
Ensures security risks are identified and escalated.

Bare Minimum Fields:

Security incidents impacting GMP activities require escalation to a Jira Quality Event.
---

Quality Assurance / Quality Control (QA)

QA-01 QA Walkthrough / Oversight Log

Purpose:
Document routine QA oversight activities.

Scope:
All QA walkthroughs and oversight reviews.

Control Addressed:
Provides independent QA oversight of operations.

Bare Minimum Fields:

---

QA-02 Audit Finding Tracking Log

Purpose:
Document internal or external audit findings.

Scope:
All audit and inspection activities.

Control Addressed:
Ensures audit findings are captured and addressed.

Bare Minimum Fields:

---

QA-03 Quality Metrics / Trending Review Log

Purpose:
Document periodic review of quality metrics and trends.

Scope:
Quality data across all domains.

Control Addressed:
Detects emerging quality risks.

Bare Minimum Fields:

---

QA-04 Management Review Log

Purpose:
Document periodic management review of the quality system.

Scope:
Formal management review activities.

Control Addressed:
Ensures leadership oversight of quality performance.

Bare Minimum Fields:

---

QA-05 CAPA Effectiveness Review Log

Purpose:
Document verification of CAPA effectiveness.

Scope:
All CAPAs requiring effectiveness checks.

Control Addressed:
Ensures corrective and preventive actions are effective.

Bare Minimum Fields:

10. Summary, Governance, and Final Principles

This Jira Event Management process is designed to provide a clear, scalable, and compliant framework for managing quality-related exception events while preserving the integrity of routine execution systems.

---

10.1 System Summary

Layer Purpose System
Routine Execution Document that work occurred Logs (paper or electronic)
Exception Management Evaluate and decide on issues Jira – Quality Events
Systemic Response Correct and prevent recurrence Jira – CAPA & Change Control
Routine Execution Logs prove work occurred.
Jira proves decisions were made.
---

10.2 Governance Model

This process is governed by Quality Assurance.

Routine execution remains governed by existing operational procedures and systems.

---

10.3 Inspection Readiness Statement

During inspections, this system should be explained as follows:

Routine work is documented where it is performed. When an exception is identified, it is escalated into Jira for independent QA evaluation and decision-making.

This approach ensures:

---

10.4 Final Principles to Remember

---

10.5 Future Enhancements (Non-Blocking)

The following enhancements may be implemented without changing the core design:

These enhancements do not change the fundamental system boundary or governance model.
---

Document Status: Final — Ready for Implementation, Training, and Inspection