Program Governance Model — Version 1.0

Project Catalyst — This document defines the complete governance framework for the $99M AI Transformation Program: who has authority over what, how decisions are made, how they are enforced, and what happens when they fail. It is deliberately heavier than a conventional IT project governance model, in proportion to the regulatory and reputational stakes of deploying AI at scale in healthcare insurance. Governance here is not administrative overhead — it is the mechanism that makes AI deployment defensible.

1. Governance Philosophy & Principles

1.1 Why This Governance Model Exists

Enterprise AI in healthcare insurance carries a specific category of risk that conventional IT governance is not designed to manage. A misconfigured server causes downtime; a misconfigured AI model can deny medical care to thousands of people, create legal liability (precedent: Moffatt v. Air Canada, 2024), trigger regulatory enforcement, and erode member trust permanently. The governance overhead in this document reflects that difference.

This governance model is designed to achieve three outcomes simultaneously:

1. Defensible decision-making: Every material decision (scope, budget, schedule, model release, regulatory interpretation) is traceable to a named authority who reviewed evidence and signed off. If a regulator, auditor, or court asks "Who approved this?", the answer is documented.
2. Proactive risk management: Risks are identified, assessed, and mitigated before they materialize — not responded to after they cause damage. The two-line-of-defense model risk structure, the mandatory JAD session roster, and the quarterly risk review exist to catch problems early.
3. Delivery velocity without compromised standards: Governance that blocks everything is as harmful as governance that blocks nothing. This model is designed to enable agile sprint-level execution within a governed framework — the phase gates and validation gates are the checkpoints, not every sprint decision.

1.2 Governance Principles

• Separation of delivery and validation: The team that builds a model is never the same team that validates it for production. This is structural, not procedural — the Independent Model Validation team reports to a different authority chain than the BRD delivery teams.
• Concurrent multi-board sign-off: No phase gate is passed without all three governance boards (Executive Steering, AI Governance, Enterprise Architecture) signing off independently. One board cannot override another; if they disagree, the escalation process (Section 6) resolves the conflict.
• Named accountability: Every decision authority in this model is assigned to a named individual, not a committee. Committees deliberate; individuals are accountable. The RACI Matrix makes this explicit.
• Governance survives personnel changes: If the Executive Sponsor, Program Director, or any board chair departs, the governance structure persists. Authority transfers to the successor; processes do not change. This is documented explicitly because sponsor turnover is an identified risk (RAIDD R-09).
• Proportional governance: Sprint-level decisions do not require board approval. Board-level decisions are not made in sprint planning. The decision authority matrix (Section 4) defines which decisions require which level of authority. Governance applied at the wrong level creates either bottlenecks or abdication.

2. Authority Hierarchy

2.1 Four-Level Authority Structure

Program authority operates at four distinct levels, each with defined decision scope and escalation triggers:

2.2 Reporting Lines

• Solid-line authority: ACME Board → Executive Sponsor (M. Kavanagh) → Program Director (C. Tyrrell). This is the contractual authority chain. Christian has delegated authority from the Executive Sponsor to run the program within the parameters defined in the Charter.
• Dotted-line coordination: Program Director ↔ all 25 team leads. The Program Director coordinates; he does not directly manage. Each team lead has a solid-line boss in their home organization (ACME department head or Pulaski engagement manager). Matrix coordination works because the governance structure defines decision rights clearly enough that "Who decides?" is never ambiguous.
• PMO coordination: T. Valdez (PMO Lead, ACME FTE) operates as the administrative backbone — schedule tracking, status reporting, document management, meeting coordination. The PMO Lead does not hold decision authority over delivery; the PMO is a service function, not a gatekeeping function.

3. Three Governance Boards — Composition, Authority & Meeting Cadence

Three standing boards operate as the governance layer between the Executive Sponsor and the Program Director. Each board has a distinct mandate, composition, and meeting cadence. No single board can approve a phase gate alone; all three must concur. This concurrent structure is deliberate: it prevents any one perspective (business, AI risk, or technical) from dominating decisions that affect all three.

4. Decision Authority Matrix

This matrix defines who has authority over each category of program decision. The goal is to eliminate ambiguity: for any decision that arises during program execution, this matrix identifies the decision-maker without requiring interpretation or negotiation. Decisions not explicitly listed default to Program Director authority if they are within the program's scope, or to the Executive Sponsor if they are not.

5. Escalation Framework

Escalation is expected and healthy. It means a decision has reached the limit of one level's authority and needs the next level's input. Effective escalation is fast (time-boxed), documented (in the RAIDD Log), and resolved (not deferred indefinitely).

5.1 Standard Escalation Path (Non-Emergency)

1. Level 4 → Level 3 (0–24 hours): Team Lead or Scrum Master cannot resolve an issue within their team. Notifies Program Director with issue description, impact assessment, and recommended resolution. Most issues resolve at this level.
2. Level 3 → Level 2 (24–48 hours): Program Director convenes a working group (affected team leads, relevant board chair, functional manager). If the working group resolves, the resolution is documented in the RAIDD Log and communicated to affected parties.
3. Level 2 → Full Board (48 hours–5 business days): Working group cannot resolve, or the issue exceeds Program Director authority. Escalated to the relevant board: AI Governance Board (model-risk issues), EARB (technical issues), Executive Steering Board (scope/budget/schedule issues). Board provides direction at its next meeting or schedules an ad-hoc session within 5 business days.
4. Level 2 → Level 1 (5+ business days): Board deadlocks, or the issue exceeds board authority (e.g., >$1M contingency drawdown, regulatory escalation, program viability question). Escalated to Executive Sponsor. Sponsor makes final decision or escalates to CFO/CIO as needed.

5.2 Emergency Escalation (Bypasses Standard Path)

The following events trigger immediate escalation to the named authority, bypassing the standard path. These are not invoked lightly; they exist for situations where the standard 24–48 hour cycle is too slow.

6. Conflict Resolution Between Boards

Because all three boards must sign off on phase gates, the possibility of board disagreement is structurally inherent. This section defines the resolution process.

• Step 1 — Joint Session (within 5 business days): If two or more boards disagree at a phase gate, the Program Director convenes a joint session with all three board chairs. Each chair presents their position with evidence. The goal is consensus, not voting.
• Step 2 — Compromise Proposal (within 3 business days after joint session): If consensus is not reached, the Program Director drafts a compromise proposal (e.g., conditional approval with remediation items, partial advancement with ring-fenced risk). Proposal circulated to all three chairs for written comment.
• Step 3 — Executive Sponsor Resolution (within 5 business days): If compromise fails, the matter is escalated to the Executive Sponsor (M. Kavanagh). The Sponsor reviews all positions, consults with the CFO and CIO as needed, and makes a binding decision. The decision is documented in the Phase-Gate Record with dissenting positions noted.

7. Phase-Gate Structure & Criteria

Five phase gates govern program progression for each BRD cycle. Year 2 (BRD-02/03) and Year 3 (Optimization) follow the same gate rhythm. Each gate has defined entry criteria (what must be complete before the gate meeting) and exit criteria (what the gate sign-off authorizes).

8. Phase-Gate Sign-Off Procedure

This procedure is invariant. Every phase gate follows these steps without exception.

1. T minus 10 business days — Pre-Gate Review: Program Director conducts an internal pre-gate review with PMO Lead and affected BRD Leads. Purpose: verify that all entry criteria are met before investing board time. If any criterion is at risk, the Program Director decides: proceed with the gate (noting the risk), or defer the gate (with a new target date and remediation plan). Deferral requires Executive Steering Board notification within 24 hours.
2. T minus 7 business days — Package Submission: Program Director submits the phase-gate package to all three board chairs and the PMO archive. Package contents: executive summary (2 pages), deliverable completion matrix with evidence links, risk assessment update (RAIDD Log delta since last gate), quality metrics summary, resource plan for next phase, budget forecast vs. actual, recommended gate decision.
3. T minus 5 to T minus 2 — Board Review Period: Each board reviews the package independently. Board chairs submit written questions or concerns to Program Director no later than T minus 2. Program Director responds in writing; responses appended to the gate package.
4. T minus 1 — Pre-Read Distribution: Final gate package (including Q&A) distributed to all board members with a reminder of the gate meeting logistics.
5. Gate Day — Gate Meeting (2 hours): All three boards present (minimum quorum: chair + 1 member per board). Agenda: Program Director presentation (30 min) → Q&A from each board (15 min each, 45 min total) → board deliberation (30 min, boards may caucus separately) → gate decision (15 min). Each board votes independently: Approve, Approve with Conditions, or Reject.
6. T plus 1 — Sign-Off Record: PMO Lead documents the gate decision in the Phase-Gate Record (immutable, archived in project portal): deliverables accepted (enumerated), risks re-assessed (RAIDD Log update references), next-phase budget approved (amount), next-phase team leads confirmed (names), any conditions attached to approval (with owner and deadline). Distribution to all 25 team leads within 24 hours.

8.1 "Approve with Conditions" Protocol

If a board approves with conditions, the following rules apply:

• Each condition is documented with: description, owner, deadline, and verification method.
• The phase advances (work on the next phase begins), but the conditions must be satisfied by their deadline.
• If any condition is not satisfied by its deadline, the relevant board is notified and may convene an ad-hoc review. If the board determines the condition failure is material, it may revoke the conditional approval and require a re-gate.
• Conditions are tracked by the PMO Lead and reported in the next Program Status Sync.

9. Gate Rejection & Remediation Protocol

Gate rejection is rare but structurally possible. The protocol ensures that rejection is constructive (leads to resolution) rather than punitive (causes blame or organizational friction).

1. Within 24 hours of rejection: Rejecting board provides written, specific objections to Program Director. Objections must reference specific entry criteria that were not met, specific evidence that was insufficient, or specific risks that were unacceptable.
2. Within 5 business days: Program Director produces a remediation plan addressing each objection. Plan includes: specific actions, owners, timeline, and verification method for each objection.
3. Within 10 business days: Reconvened gate meeting (1 hour, rejecting board + Program Director). Board reviews remediation plan and either: (a) approves it (work proceeds per the plan, with a re-gate date), or (b) sustains the rejection with additional guidance.
4. If rejection sustained twice: Escalated to Executive Sponsor for resolution (Section 5.1, Level 1).

10. AI Governance & Center of Excellence Mandate

The AI Governance & Center of Excellence (CoE) is the enterprise-wide first line of defense for AI model risk. It is embedded in delivery, not separate from it. The CoE's mandate spans three domains:

• Standards & Policy: Set enterprise AI development standards aligned to NIST AI RMF 1.0 (Govern, Map, Measure, Manage) and ISO/IEC 42001. Define model documentation requirements (model cards, data lineage records, training methodology documents). Maintain the AI risk taxonomy used across all three BRDs.
• Model Lifecycle Governance: Review model design at JAD sessions before development begins. Set fairness, explainability, and human-override requirements per model type. Coordinate with Independent Model Validation on validation criteria. Define retraining triggers and ongoing monitoring standards for production models.
• Shadow AI Prevention: Conduct quarterly architecture reviews to identify AI initiatives operating outside governance (RAIDD R-10). Authority to fold non-compliant projects into the CoE structure, require deferral, or recommend suspension. Escalation path to Executive Sponsor for persistent non-compliance.

11. Two-Line-of-Defense Model Risk Structure

This structure is modeled on financial services model risk management practice (OCC SR 11-7 guidance, adapted for healthcare AI) and is the core governance innovation of this program.

12. Model Lifecycle Governance Gates

Every AI model follows a governed lifecycle with six defined checkpoints. Each checkpoint has a named authority, specific deliverables, and explicit pass/fail criteria.

13. Responsible AI Standards & Enforcement

• Transparency: Every model decision must be explainable in human-readable terms. For PA decisions: plain-language explanation of approval/denial factors. For underwriting: top 5 risk factors with relative weights. For member chatbot: confidence score visible to human reviewers; low-confidence responses flagged for human review before delivery.
• Human-in-the-Loop: Mandatory human review for all adverse PA determinations (BRD-01). Mandatory human review for underwriting decisions within defined edge-case bands (BRD-03). Mandatory human escalation path for member chatbot when confidence score falls below defined threshold (BRD-02). The human-in-the-loop is not optional, even for fully automated workflows — it is an override protocol that must always be reachable.
• Fairness: Model outputs tested for disparate impact across demographic groups (age, gender, geography, plan type). No demographic group's approval/denial rate may deviate >5% from the population mean without documented clinical justification reviewed by the CMO (Dr. N. Patel). Fairness testing is conducted pre-production and monitored continuously post-production.
• Audit Trail: Every model decision is logged with: timestamp, input data hash (not raw PHI), model version, output decision, confidence score, and whether human review was triggered. Logs retained per ACME's data retention policy (minimum 7 years for healthcare records). Logs must be queryable for regulatory audit within 48 hours of request.
• Regulatory Anchors: CMS-0057-F (prior-auth interoperability), NIST AI RMF 1.0, ISO/IEC 42001, NAIC Model AI Bulletin, applicable state AI-in-insurance statutes. The AI CoE maintains a regulatory tracker updated quarterly; new regulatory developments assessed for program impact within 10 business days of identification.

14. NIST AI RMF Function Mapping

The NIST AI Risk Management Framework organizes AI risk management around four core functions. This section maps each function to the specific governance mechanisms in this program.

15. JAD Session Structure & Mandatory Roles

Requirements for each BRD are developed through JAD (Joint Application Design) sessions. The JAD process is governed here because requirements quality directly determines model quality — a model trained on poorly specified requirements will fail validation regardless of how well it is built. Full JAD charter is in the AI Governance & JAD Session Charter; this section summarizes the governance controls.

15.1 Mandatory JAD Attendees (Non-Negotiable)

No JAD session proceeds without all 8 roles present or a documented proxy. If a mandatory attendee is unavailable and no qualified proxy is available, the session is rescheduled. This is non-negotiable because the governance value of JAD sessions comes from having all perspectives in the room simultaneously — a session missing Legal or Compliance is requirements development without governance.

16. JAD Output, Sign-Off & Exception Handling

16.1 JAD Sign-Off Process

• Each JAD session series (6–8 sessions per BRD) concludes with a written BRD requirements document.
• Every mandatory attendee (except the Program Director, who facilitates) must either sign off on the requirements or submit a written exception.
• Sign-off means: "I have reviewed these requirements and confirm they are acceptable from my governance perspective (legal, compliance, technical, security, AI governance, or clinical)."

16.2 Exception Handling

• Exceptions are written statements that a mandatory attendee cannot sign off on specific requirements. Each exception must identify: the requirement(s) in question, the specific concern, and the attendee's recommended resolution.
• Exceptions are logged in the JAD Session Minutes and tracked by the PMO.
• Resolution options: (a) modify the requirement to address the concern, (b) waive the exception with a documented risk note accepted by the relevant board, or (c) escalate to the Executive Steering Board if the exception is critical and cannot be resolved between the attendee and the Program Director.
• No BRD proceeds to Phase 1 architecture design without full JAD sign-off or documented, board-accepted waiver of all outstanding exceptions.

17. Financial Governance & Contingency Authority

17.1 Budget Authority

Total authorized budget: $99,000,000 across three SOWs (Year 1: $27.72M, Year 2: $41.58M, Year 3: $29.70M). Budget authority is tiered:

17.2 Contingency Reserve Rules

The $9.0M contingency reserve (approximately 10% of total budget) exists to absorb identified risks that materialize. It is governed by four rules:

1. Documented root cause required. Every drawdown must identify which RAIDD risk or issue materialized and why the existing budget could not absorb it. "We need more money" is not a root cause.
2. Alternatives analysis required. Before drawing contingency, the requestor must document at least two alternatives considered (descope, delay, reallocate from another category) and explain why they are inferior to the contingency drawdown.
3. Low-watermark escalation. If the contingency reserve drops below $2.0M remaining (regardless of how many individually-approved drawdowns caused this), the Program Director issues a formal risk escalation to the CFO and Executive Sponsor. This triggers a program-level risk review to assess whether remaining contingency is adequate for the remaining program duration.
4. No contingency for scope growth. Contingency exists to absorb risk, not to fund features. If a new capability is desired, it enters the change control process as a scope change with its own funding source identified.

17.3 Financial Reporting Governance

• Program Finance (A. Rodriguez) delivers a monthly financial report to the Program Director by the 10th business day of each month. Report includes: actual spend vs. budget by category, cumulative variance, CPI, EAC, and contingency balance.
• Financial report is reviewed in the monthly Program Status Report (distributed to Executive Steering Board).
• Quarterly financial review includes a forward-looking forecast against the SOW payment schedule. If forecast indicates a milestone payment will not be met on time, Program Director negotiates timing adjustment with ACME procurement.

18. Change Control Governance

18.1 Change Control Tiering

Changes are classified into three tiers based on impact. Tier determines the approval authority and turnaround time.

18.2 Change Control Process

1. Change request submitted using standard form in the Change Control Log. Requestor documents: what is changing, why, impact on all dimensions (scope, schedule, budget, quality, risk), alternatives considered, and recommended action.
2. Program Director conducts impact assessment (5 business days), consulting affected team leads, Program Finance, and relevant board chairs.
3. Based on tier classification, request is routed to the appropriate authority.
4. Authority reviews and decides: Approve, Approve with Conditions, Defer, or Reject.
5. Approved changes are logged in the Change Control Log with effective date, baseline adjustment, and owner. All affected program artifacts updated within 5 business days.

19. Regulatory & Compliance Governance

19.1 Regulatory Oversight Structure

Regulatory compliance is not owned by a single team — it operates through a shared-responsibility model with clear primary and secondary owners:

19.2 Regulatory Change Response Process

• Regulatory developments that could impact the program are identified through: regulatory tracker (maintained by Compliance, updated quarterly), industry intelligence (General Counsel monitors enforcement actions and peer-company responses), and NIST/ISO updates (monitored by AI CoE).
• When a potentially impactful development is identified, the primary owner has 10 business days to produce an impact assessment: does this affect the program's compliance posture? If yes, what changes are needed (scope, model design, governance process)?
• If changes are needed, they enter the change control process at the appropriate tier. Regulatory-driven changes are never deferred without Executive Steering Board awareness and acceptance of the risk.

19.3 Proactive Regulatory Engagement

The program's regulatory posture is proactive, not reactive. Quarterly briefings to state regulators and CMS liaisons (led by R. Thorne) are designed to build trust and demonstrate governance maturity before any regulatory inquiry. These briefings cover: governance framework summary, model validation methodology, audit trail capabilities, and fairness testing results. The intent is that when regulators ask "How do you govern your AI?", the answer is already documented and transparent — not produced under pressure after an inquiry.

20. Shadow AI Governance

Shadow AI — AI or ML initiatives deployed outside the program's governance perimeter by individual departments, business units, or IT teams — is one of the program's highest-rated risks (RAIDD R-10, score 8/9). It is governed here because uncontrolled AI deployment creates regulatory exposure, data governance gaps, and architectural fragmentation that undermine the program's objectives.

20.1 Detection

• The AI CoE conducts quarterly architecture reviews to identify AI initiatives not registered in the program's model inventory.
• IT Operations (H. Nakamura) monitors cloud resource provisioning for AI/ML workloads not tagged to approved program projects.
• Any ACME employee may report suspected shadow AI to the AI CoE; reports are treated confidentially and assessed within 5 business days.

20.2 Disposition

Identified shadow AI initiatives are evaluated by the AI CoE within 10 business days. Disposition options:

• Fold In: Initiative is valuable and should be governed. It is brought under the program's governance perimeter, assigned to the appropriate BRD or CoE workstream, and subjected to the standard model lifecycle governance (Section 12). Resource and scope adjustments made through change control.
• Defer: Initiative is potentially valuable but not a priority for this program's timeline. Documented and queued for post-program evaluation. Initiative is halted if it poses governance risk.
• Reject: Initiative is not aligned with program objectives, creates unacceptable risk, or duplicates existing program scope. Initiative owner notified with explanation. If the owner disagrees, escalation to Executive Sponsor.

20.3 Enforcement

The AI CoE has authority to recommend suspension of non-compliant AI initiatives to the Executive Sponsor. Persistent non-compliance after notification and escalation is treated as a governance violation and reported to the Executive Steering Board. The program's governance authority over enterprise AI is defined in the Charter and cannot be circumvented by individual department heads without Steering Board override.

21. Documentation & Audit Trail

Every governance decision on this program is documented in the project portal with version control and immutable archiving. The documentation standard exists for two reasons: internal accountability (knowing who decided what) and external defensibility (demonstrating to regulators and auditors that governance was not performative).

21.1 Governance Artifacts & Retention

22. Governance Performance Monitoring

Governance itself is monitored for effectiveness. A governance framework that is not enforced, or that creates bottlenecks without adding value, should be adjusted.

22.1 Governance Health Metrics

If governance processes consistently miss targets (3+ consecutive periods), the Program Director initiates a governance retrospective to identify root causes and propose adjustments. Adjustments to governance processes require Executive Steering Board approval and are documented as formal changes (Section 18).

23. Governance of This Framework

• This Governance Model is reviewed at each Phase 0 gate (start of each program year) and updated as needed.
• Material changes (board composition changes, decision authority shifts, new blocking gates, removal of governance requirements) require Executive Steering Board approval and a corresponding entry in the Change Control Log.
• Minor clarifications (correcting a name, adding a cross-reference, updating a date) can be made by the Program Director with notification to all board chairs.
• This document operates under the authority of the Program Charter. If this Governance Model and the Charter conflict, the Charter prevails until both are reconciled through formal change control.

24. Approval Signatures