AI Governance & JAD Session Charter

This charter establishes the AI Governance & Center of Excellence (CoE) mandate — what it does, who leads it, and what authority it holds — and defines the JAD (Joint Application Design) session structure used to develop requirements for each BRD. It is approved at the Phase 0 gate and referenced throughout the program by the Governance Model, PMP, and all three BRD specifications. Any change to the CoE mandate or JAD structure requires AI Governance Board approval.

1. Charter Purpose & Authority

This charter serves two distinct but interconnected purposes:

1. Establish the AI Governance & CoE as a permanent governance function within the program — not an advisory committee, not a working group, but a team with enterprise-wide authority over AI development standards, model lifecycle governance, and responsible AI practices. The CoE's authority is granted by the Program Charter and enforced through the Program Governance Model.
2. Define the JAD session structure that produces the requirements for each BRD. JAD sessions are not informal brainstorming — they are governed requirements-development processes with mandatory participants, structured agendas, formal sign-off, and documented exception handling. The quality of requirements directly determines the quality of the AI models built from them; governance at the requirements stage prevents problems that are far more expensive to fix during development or validation.

2. AI Governance & CoE Mandate

The AI Governance & Center of Excellence is the enterprise-wide first line of defense for AI model risk. It operates across four domains:

2.1 Standards & Policy

• Set enterprise AI development standards aligned to NIST AI RMF 1.0 (four functions: Govern, Map, Measure, Manage) and ISO/IEC 42001 (AI management system standard).
• Define and maintain model documentation requirements: every AI model in the program must have a model card (purpose, architecture, training data, performance metrics, limitations, fairness assessment), a data lineage record (source data, transformations, de-identification verification), and a training methodology document (algorithm selection rationale, hyperparameter choices, validation approach).
• Maintain the AI risk taxonomy used across all three BRDs: a structured classification of AI-specific risks (accuracy degradation, hallucination, bias/fairness, adversarial attack, privacy exposure, regulatory non-compliance, adoption failure) with definitions, severity criteria, and response playbooks.
• Publish and maintain the Enterprise AI Standards Guide — the reference document that all BRD delivery teams must follow for model development, testing, documentation, and production deployment. Updated annually or when regulatory landscape changes materially.

2.2 Model Lifecycle Governance

• Review model design concepts at JAD sessions before development begins (Section 10). The CoE evaluates: Is the proposed model type appropriate for the use case? Are the training data assumptions sound? Are fairness criteria defined? Is the human-override protocol adequate?
• Set fairness, explainability, and human-override requirements per model type — not one-size-fits-all. A prior-auth decision model (BRD-01) has different fairness requirements than a chatbot intent classifier (BRD-02) or an underwriting risk scorer (BRD-03). The CoE defines these requirements during Phase 1 for each BRD.
• Conduct interim reviews during model development (Phase 2): review training data quality, feature engineering decisions, preliminary accuracy metrics, and early fairness signals. The purpose is to catch problems during development that would otherwise be discovered at the formal validation gate — saving time and reducing rework.
• Coordinate with Independent Model Validation (second line) on validation criteria, test datasets, and acceptance thresholds. The CoE helps BRD teams build models that will pass validation; the Validation team independently tests whether they actually do.
• Define retraining triggers and monitoring standards for production models: accuracy drift thresholds, fairness drift thresholds, and data distribution shift indicators that signal when a model needs to be retrained and re-validated.

2.3 Regulatory Tracking

• Maintain a regulatory tracker updated quarterly: CMS regulations, NIST updates, ISO standards evolution, NAIC model bulletins, state AI-in-insurance legislation (current and proposed), and relevant court decisions (e.g., Moffatt v. Air Canada and successors).
• When a new regulatory development is identified, the CoE has 10 business days to produce an impact assessment: does this affect the program's compliance posture? If yes, what changes are needed (model design, governance process, documentation, testing methodology)?
• If changes are needed, they enter the change control process at the appropriate tier. The CoE is not a regulatory compliance function (that is VP Compliance, J. Martinez), but it is the function that translates regulatory requirements into AI-specific technical and governance standards.

3. CoE Organization & Reporting

3.1 Team Composition

The AI Governance & CoE consists of 12 people, led by S. Khurana (AI Governance Director, Pulaski Advisory). Full roster in Resource Plan, Team 5. Key roles:

3.2 Reporting Structure

• S. Khurana reports to: AI Governance Board (governance authority); Program Director C. Tyrrell (program coordination). Dual reporting ensures the CoE is both governmentally independent and operationally integrated.
• CoE relationship to BRD delivery teams: Advisory and standards-setting during development. The CoE does not approve models for production — that authority belongs to the AI Governance Board acting on Independent Model Validation results. The CoE helps teams build models that will pass validation.
• Transition at closeout: The CoE function transitions to permanent ACME operations at program closeout (August 2029). ACME FTE members (L. Whitfield, K. Novak) form the nucleus of the permanent function; Pulaski consultants conduct knowledge transfer and roll off.

4. CoE Relationship to Independent Model Validation

The distinction between the CoE (first line) and Independent Model Validation (second line) is structural and deliberate:

5. Shadow AI Prevention Authority

Shadow AI — AI or ML initiatives deployed outside the program's governance perimeter — is one of the program's highest-rated risks (RAIDD R-10, score 8/9). The CoE's authority to address shadow AI is defined here:

5.1 Detection Mechanisms

• Quarterly architecture review: CoE + EARB jointly review ACME's cloud environments and internal systems for AI/ML workloads not registered in the program's model inventory.
• IT Ops monitoring: H. Nakamura's team monitors cloud resource provisioning for GPU/ML instance types, AI/ML service activations, and LLM API calls not tagged to approved program projects.
• Open reporting: Any ACME employee may report suspected shadow AI to the CoE. Reports treated confidentially; assessed within 5 business days.

5.2 Disposition Authority

Identified shadow AI initiatives are evaluated by the CoE within 10 business days. The CoE recommends one of three dispositions to the AI Governance Board:

• Fold In: Initiative is valuable and should be governed. Brought under the program's governance perimeter, assigned to the appropriate workstream, and subjected to the standard model lifecycle governance. Resource and scope adjustments processed through change control.
• Defer: Initiative is potentially valuable but not a priority for this program's timeline. Documented, queued for post-program evaluation, and halted if it poses governance risk in its current uncontrolled state.
• Reject: Initiative is not aligned, creates unacceptable risk, or duplicates existing scope. Initiative owner notified with documented explanation. Owner may appeal to Executive Sponsor if they disagree.

5.3 Enforcement

The 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 Program Charter §9 and cannot be circumvented by individual department heads without Executive Steering Board override.

6. JAD Session Governance

Requirements for each BRD are developed through Joint Application Design (JAD) sessions — structured, facilitated workshops that bring together business, clinical, legal, compliance, security, architecture, AI governance, and delivery perspectives to define what the AI system must do, under what constraints, and to what standards.

JAD sessions are governed, not informal. They have mandatory participants (Section 7), a structured agenda (Section 8), formal sign-off requirements (Section 9), and explicit exception handling. This governance exists because requirements quality directly determines model quality — a model trained on poorly specified requirements will fail validation regardless of how well it is engineered.

6.1 JAD Series Cadence

Session count is a guideline, not a constraint. If requirements are not sufficiently developed after the planned sessions, additional sessions are scheduled. Rushing to meet a session count at the expense of requirements quality is explicitly prohibited — it creates technical debt that compounds through development and validation.

7. JAD Mandatory Roles & Responsibilities

7.1 Proxy Rules

• Each mandatory attendee may designate a proxy who attends when the primary is unavailable. The proxy must be pre-approved by the AI Governance Board and documented in the JAD roster.
• The proxy must have sufficient authority to make decisions on behalf of the primary — a proxy who says "I'll need to check with my boss" on every substantive question defeats the purpose of having the role in the room.
• The Business Sponsor (Role 1) may not be proxied without explicit AI Governance Board approval, because the sponsor's clinical/business judgment is not interchangeable with a delegate's.
• No attendee may serve as proxy for more than one mandatory role (prevents a single person "covering" for absent participants without actually representing their perspective).

8. JAD Session Structure & Agenda

8.1 Session Progression

The 6–8 sessions per BRD follow a deliberate progression from broad scope to detailed specifications:

8.2 Session Facilitation Rules

• Program Director (facilitator) manages the agenda strictly — sessions that run over produce fatigue and lower-quality decisions. If a topic cannot be resolved within its allocated time, it is parked as an action item with an owner and deadline, not debated until exhaustion.
• Every session produces written minutes (captured by PMO) within 24 hours. Minutes include: attendees present, topics covered, decisions made, action items assigned (with owner and deadline), and any exceptions or open questions.
• Decisions made in JAD sessions are final within the scope of that session's agenda — attendees cannot retroactively change positions outside the session without submitting a formal exception (Section 9.2).
• Side conversations between two attendees that resolve a requirements question must be reported back to the full group at the next session for ratification — requirements decisions are not made bilaterally.

9. JAD Output, Sign-Off & Exception Handling

9.1 Requirements Document

Each JAD series produces a BRD requirements document that becomes the authoritative specification for what the delivery team builds. The document uses a standard template:

• Each requirement has: unique ID (FR-XX.NNN), description, business justification, MoSCoW priority (Must/Should/Could/Won't this phase), acceptance criteria, and regulatory traceability (if applicable).
• For AI model requirements specifically, each requirement additionally includes: model type, expected inputs/outputs, performance threshold, fairness criteria, human-override protocol, and explainability standard.
• The requirements document is versioned. The version signed off at the end of the JAD series becomes the requirements baseline. Changes after baseline are treated as scope changes and processed through formal change control.

9.2 Sign-Off Process

1. At Session 8 (Final Review), each mandatory attendee (except the Program Director, who facilitates) reviews the complete requirements document.
2. Each attendee provides one of two responses: Sign Off ("I have reviewed these requirements and confirm they are acceptable from my governance perspective") or Submit Exception (written statement identifying specific requirements they cannot approve, with explanation and recommended resolution).
3. Sign-off is collected in a formal sign-off record, documented with name, role, date, and response. The record is archived in the project portal as part of the Phase 1 gate package.

9.3 Exception Handling

Exceptions are not failures — they are the governance system working correctly. A mandatory attendee who has a legitimate concern should raise it, not suppress it to avoid delaying the timeline.

• Each exception must identify: the specific requirement(s) in question, the specific governance concern (legal, compliance, security, technical, AI risk), and the attendee's recommended resolution.
• Exceptions are tracked by the PMO with owner and resolution deadline (typically 10 business days).
• Resolution options: (a) modify the requirement to address the concern — most common; (b) waive the exception with a documented risk note accepted by the relevant governance board — used when the concern is valid but the risk is accepted; (c) escalate to the Executive Steering Board — used when the exception is critical and cannot be resolved between the attendee and the Program Director.
• No BRD proceeds to Phase 1 architecture design without either full sign-off OR documented, board-accepted waiver of all outstanding exceptions.

10. AI Model Design Review at JAD

Session 4 of each JAD series is dedicated to AI model design review — the point where the CoE evaluates whether the proposed model approach is governable, fair, explainable, and safe. This is not a technical deep-dive into algorithm selection; it is a governance review of the model's design assumptions and risk profile.

10.1 What the CoE Reviews

10.2 Model Design Approval

The AI Governance Director (S. Khurana) provides a formal recommendation on each model design: Approved (proceed to development), Approved with Conditions (proceed with specified adjustments), or Not Approved (redesign required). The recommendation is documented in the JAD Session 4 minutes and reported to the AI Governance Board at its next meeting. The AI Governance Board ratifies or overrides the recommendation.

11. Escalation Path

Used when a JAD session cannot reach consensus on a requirement, a model design question, or a governance exception:

1. Within the session (immediate): Program Director (facilitator) attempts resolution by clarifying the positions, proposing a compromise, or reframing the question. Most disagreements resolve at this level.
2. Action item with deadline (24–48 hours): Unresolved item parked as a formal action item with a named owner, a clear statement of the disagreement, and a resolution deadline (typically next JAD session or within 10 business days).
3. Board review (5 business days): If the action item cannot be resolved bilaterally, escalated to the relevant board: AI Governance Board (model-risk or fairness questions), EARB (technical feasibility questions), or Executive Steering Board (scope, budget, or regulatory-risk questions).
4. Executive Sponsor (if board cannot resolve): Material disagreements that deadlock at board level are escalated to M. Kavanagh per the standard escalation framework in the Governance Model §6.

12. Charter Governance & Document Control

• This charter is reviewed annually and at the start of each program year (Year 1, Year 2, Year 3).
• Material changes — mandatory role changes, sign-off process modifications, CoE authority adjustments, shadow AI governance changes — require AI Governance Board approval with Executive Steering Board notification.
• Minor clarifications (correcting names, adding cross-references, updating dates) can be made by S. Khurana with Program Director notification.
• This charter operates under the authority defined in the Program Charter and the Program Governance Model. If this charter conflicts with either, the higher-authority document prevails.