Review Agenda The AI Governance Lead convenes quarterly PMM review meetings examining a structured agenda: monitoring metric trends across all five dimensions (performance, fairness, drift, operational, human oversight), alert history and resolution statistics, deployer feedback summary and cross-deployer pattern analysis, complaint volumes and patterns, non-conformity register status (PMM-related entries), threshold review and recalibration decisions, the feedback loop operation (are findings producing actions?), and the PMM budget and resource status. The review produces documented minutes with action items, owners, and deadlines. Each action item is tracked to completion. The quarterly review minutes are retained as Module 12 evidence, demonstrating that the PMM system is governed, not merely running. The review should also assess the PMM system’s own health: are metrics being computed on schedule? Are dashboards accessible? Is the alerting layer delivering alerts reliably? A PMM system that fails silently provides false assurance. Key outputs

• Eight-item structured review agenda
• Documented minutes with tracked action items
• PMM system health self-assessment
• Module 12 AISDP evidence

Decision Authority by Impact Tier A PMM finding that warrants action must pass through a decision process with defined authority tiers. Threshold adjustments (tuning warning thresholds based on operational experience) can be authorised by the Technical SME, recorded in the PMM review minutes. Model retraining on updated data, where the pipeline follows the documented methodology and the retrained model passes all validation gates, is authorised by the Technical Owner with notice to the AI Governance Lead. Model architecture changes, hyperparameter shifts, or changes to the feature set require AI Governance Lead approval and a substantial modification assessment. System suspension or withdrawal requires AI Governance Lead sign-off with immediate notice to the Legal and Regulatory Advisor and affected deployers. Without defined decision authority, findings accumulate in dashboards and reports without translating into system improvements. The tiered authority structure ensures that routine adjustments proceed quickly, while higher-impact changes receive appropriate governance scrutiny. Key outputs

• Four-tier decision authority (Technical SME, Technical Owner, AI Governance Lead, AI Governance Lead + Legal)
• Routine adjustments proceed quickly; high-impact changes receive scrutiny
• Authority documented in QMS
• Module 12 AISDP documentation

Prioritisation Against Development Workload PMM-triggered remediation competes with feature development, bug fixes, and other engineering priorities. Without a defined prioritisation mechanism, PMM actions are perpetually deprioritised and the feedback loop stalls. A separate PMM action backlog with its own prioritisation criteria addresses this risk. Critical PMM actions (compliance threshold breaches, serious incident corrective actions) override all other engineering work. Warning-level PMM actions are scheduled by the Technical Owner within the next development sprint. Informational PMM findings are reviewed by the AI Governance Lead at the quarterly meeting and scheduled as capacity permits. The AI Governance Lead has authority to elevate PMM action priority when engineering prioritisation is inconsistent with compliance risk. This authority is documented in the QMS and understood by engineering leadership. A PMM action that sits in the backlog for months because it was deprioritised by the engineering team represents a compliance risk that the AI Governance Lead must own. Key outputs

• Separate PMM action backlog with compliance-first prioritisation
• Critical PMM actions override all other work
• AI Governance Lead authority to elevate priority
• Authority documented in QMS

Traceable Documentation per Cycle Every completed feedback loop cycle, from PMM finding through decision, action, validation, and AISDP update, is documented as a single traceable record. The record captures the originating PMM finding (alert, report, or deployer feedback), the decision taken (including authorising person and date), the action implemented (code change, retrain, configuration update, threshold adjustment), the validation result (retrained model performance against validation gates), and the AISDP update (modules modified, new version number). This documentation demonstrates to a competent authority that the PMM system functions as a closed loop: findings produce actions, actions produce improvements, improvements are documented. It also provides version control traceability, linking each AISDP version change to the PMM finding that motivated it. The traceable record is retained as Module 12 evidence within the evidence register, cross-referenced to the relevant Non-Conformity Register entry where applicable. Key outputs

• Per-cycle traceable record (finding, decision, action, validation, AISDP update)
• Closed-loop demonstration for competent authority
• Version control traceability from AISDP change to PMM finding
• Module 12 AISDP evidence