Table of Contents
1. Change Control Process Summary
This log records every formal change against Project Catalyst's program baseline since kickoff on August 17, 2026. Changes affecting scope, budget (>$500K), schedule (>2 weeks), model governance standards, or resource allocation (>5 FTEs) require formal approval per the tiering defined in the Program Governance Model §18 and PMP §21. Each change entry documents: what changed, why, what alternatives were considered, what the impact is, and who approved it.
The change control process follows five steps:
- Submission: Requestor documents the change using the standard form (what, why, impact, alternatives, recommendation).
- Impact Assessment (5 business days): Program Director assesses impact on scope, schedule, budget, quality, and risk.
- Routing: Based on impact, the request is routed to the correct approval tier: Program Director (Tier 1), relevant Board (Tier 2), or Executive Sponsor (Tier 3).
- Decision (within 10 business days): Approval authority reviews and decides: Approve, Approve with Conditions, Defer, or Reject.
- Implementation: Approved changes logged here, baselines updated, affected artifacts revised within 5 business days.
Change Log
Showing all 7 changes
Description
Pre-approve contingency utilization of up to $1.2M for extended data remediation if Phase 0 data profiling identifies legacy claims data quality gaps beyond the initial estimate. Activation requires Program Director + CFO joint approval with documented root cause — the pre-approval removes decision latency, not accountability.
Business Justification
RAIDD R-01 (Legacy Claims Data Fragmentation) is scored 9/9 — the highest-rated risk in the program. ACME's claims data spans 4 legacy systems with different formats, identifiers, and coding standards. If Phase 0 profiling reveals >15% of records require manual remediation, the remediation effort could add 4–8 weeks and $800K–$1.2M. Pre-approval ensures remediation starts immediately upon profiling results rather than waiting 2–3 weeks for a standard change request cycle.
Alternatives Considered
- Wait for profiling results, then submit standard change request: Rejected — adds 2–3 weeks to remediation timeline, potentially delaying Phase 0 gate.
- Reduce BRD-01 training data scope to avoid remediation: Rejected — lower-quality training data produces lower-accuracy models, which may fail Independent Model Validation.
- Pre-approve a larger amount ($2M): Rejected — $1.2M covers the maximum estimated remediation scope; $2M would reduce contingency reserve unnecessarily.
Impact Assessment
Budget: Up to $1.2M from contingency reserve (reduces reserve from $9.0M to $7.8M if fully utilized). Schedule: Averts potential 2–3 week delay in Phase 0 remediation start. Scope: No scope change. Quality: Preserves training data quality for BRD-01.
Description
Formalize the two-line-of-defense model risk structure as the program's mandatory governance framework for AI model risk: AI Governance & CoE as first line (embedded in delivery, advisory, standards-setting), Independent Model Validation (P. Okafor, 6 people) as second line (separate from delivery, reports to AI Governance Board, has non-overridable blocking authority for production releases). No model reaches production without clean validation sign-off — zero Critical, zero uncorrected High findings.
Business Justification
A single team that both designs and validates AI models has an inherent conflict of interest — schedule pressure incentivizes passing models that should be held. The two-line separation eliminates this conflict. The structure is modeled on OCC SR 11-7 (financial services model risk guidance, adapted for healthcare AI) and satisfies the NAIC Model AI Bulletin's requirement for independent testing and validation of AI models used in insurance decisions.
Alternatives Considered
- Single team handles both CoE and validation: Rejected — creates conflict of interest; does not satisfy NAIC bulletin independence requirement.
- External third-party validation: Considered for Year 2 as a supplemental measure but rejected as primary approach — too slow for sprint-cadence model iteration; ACME needs internal capability that persists after program closeout.
- Validation as a function within the BRD delivery teams: Rejected — same conflict-of-interest problem as single team; structurally cannot be independent if it reports to the delivery lead.
Impact Assessment
Budget: P. Okafor's team (6 people) already budgeted in the Resource Plan. No incremental cost. Schedule: Model validation adds 5–10 business days per model to the production release timeline — this is deliberate governance overhead, not waste. Scope: No scope change. Risk: Significantly reduces model risk (addresses RAIDD R-03, R-04, R-06).
Description
Adopt a multi-cloud architecture for the Data & Cloud AI Platform Foundation instead of single-vendor commitment. Workloads distributed across AWS/GCP/Azure based on cost and capability. Primary vendor selected for default workloads; secondary vendors available for cost optimization and contingency. Architecture designed to allow workload migration between providers within 4 weeks if needed.
Business Justification
The initial single-vendor hyperscaler quote came in at $31.4M — exceeding the $26.9M cloud/platform budget allocation by 17% (RAIDD I-02). Rather than negotiating from a position of lock-in or drawing contingency immediately, multi-cloud architecture enables competitive pricing pressure and reduces single-vendor risk (RAIDD R-05). Additionally, different cloud providers offer different strengths: one may have better GPU pricing for model training while another offers lower inference-endpoint costs.
Alternatives Considered
- Accept single-vendor quote at $31.4M: Rejected — exceeds budget by $4.5M; would require contingency draw before Phase 1 even begins.
- Negotiate harder with single vendor: Partially pursued — Vendor Manager L. Park is negotiating a volume discount, but multi-cloud provides structural leverage regardless of negotiation outcome.
- Reduce cloud scope (fewer environments, smaller instances): Rejected — would constrain model training capacity and slow delivery velocity.
- Defer cloud decision to Phase 1: Rejected — platform vendor selection is a Phase 0 deliverable; deferral delays Platform Foundation go-live.
Impact Assessment
Budget: Expected to bring cloud costs within the $26.9M allocation through competitive pricing. Additional ~$200K engineering effort for multi-cloud abstraction layer (absorbed within existing platform team capacity). Schedule: No schedule impact — multi-cloud architecture designed in Phase 0 alongside single-vendor architecture. Risk: Reduces vendor concentration risk (R-05); adds minor operational complexity (mitigated by Platform team expertise).
Description
Add the Program Management Plan, Program Governance Model, Kickoff Deck, Kickoff Summary, RAIDD Log, RACI Matrix, Communications Plan, and AI Governance & JAD Session Charter as explicit Phase 0 deliverables. These were originally covered implicitly by the Charter but not itemized as standalone deliverables with completion criteria.
Business Justification
With 262 people ramping across 25 teams, the onboarding documentation must be explicit, comprehensive, and accessible from Day 1. Relying on the Charter alone creates ambiguity about governance procedures, reporting cadences, and decision authorities that would generate confusion and inconsistent practices during the critical Phase 0 mobilization period.
Impact Assessment
Budget: No additional budget — artifacts produced by PMO and Program Director within existing capacity. Schedule: No schedule impact — artifacts produced in parallel with other Phase 0 activities. Scope: Additive (more deliverables, not changed deliverables).
Description
Approve gradient boosted ensemble (GBE, e.g., XGBoost/LightGBM) as the primary model architecture for BRD-03 (Underwriting & Risk AI) instead of deep learning. This is a deliberate, governance-driven architectural decision — not a technical limitation.
Business Justification
Four factors favor GBE over deep learning for underwriting risk scoring: (1) Explainability — GBE models produce native feature importance and support SHAP values, enabling the Top Risk Factors report required by NAIC bulletin transparency standards without post-hoc explanation layers; (2) Regulatory defensibility — state insurance examiners can understand GBE models more readily than neural networks; (3) Actuarial acceptance — ACME's actuaries are trained in statistical methods closer to GBE, increasing trust and adoption; (4) Data scale appropriateness — ACME's underwriting dataset (~1M cases over 5 years) is sufficient for GBE but modest for deep learning, which risks overfitting.
Alternatives Considered
- Deep learning (neural network): Rejected — lower explainability, harder to defend to regulators, overfitting risk at ACME's data scale.
- Hybrid (GBE primary + deep learning secondary for specific subtasks): Deferred to Year 3 optimization if GBE performance is inadequate. Not rejected outright.
- Pure rules-based (no ML): Rejected — does not improve on current actuarial process; misses predictive accuracy gains.
Impact Assessment
Budget: GBE requires less compute than deep learning — minor positive budget impact. Schedule: No schedule impact. Quality: GBE accuracy is expected to meet the ±6% loss-ratio deviation target at ACME's data scale. Risk: Reduces regulatory and explainability risk (BRD-03 §6.2).
Description
Add conversion of ACME's medical policy documents from PDF to machine-readable structured format as an explicit Phase 1 deliverable. RAIDD I-04 identified that medical policy documents — used by BRD-01 (clinical decision rules) and BRD-02 (RAG retrieval corpus) — are currently stored as unstructured PDFs. Both BRDs require these policies in structured format for NLP processing and factual grounding. This conversion was not originally scoped.
Business Justification
Without machine-readable medical policies: BRD-01 cannot apply clinical decision rules programmatically (requires manual rule coding instead of NLP-based extraction); BRD-02's RAG retrieval corpus will have gaps in coverage, increasing hallucination risk. The conversion enables both BRDs to reference the authoritative policy source directly rather than relying on manually coded approximations.
Alternatives Considered
- Manual rule coding (BRD-01) + manual Q&A development (BRD-02): Rejected — labor-intensive, error-prone, creates maintenance burden as policies change. Does not address the root cause.
- Automated PDF conversion using NLP: Selected as primary approach — faster and more scalable, with human review for accuracy verification.
- Hybrid (automated conversion + manual review for high-risk policies): Adopted — automated conversion for bulk policies; manual review by Medical Policy team for the 50 highest-impact policy documents.
- Defer to Year 2: Rejected — both BRD-01 (Year 1) and BRD-02 (Year 2) need the converted policies. Deferring creates a Year 1 gap.
Impact Assessment
Budget: Approximately $180K (2 data engineers × 6 weeks + Medical Policy team review time). Absorbed within existing Phase 1 labor budget without contingency draw. Schedule: Conversion runs in parallel with JAD sessions (Oct–Dec 2026); no impact to BRD-01 requirements timeline. Scope: Additive — new deliverable, not a change to existing deliverables.
Description
Two BRD-01 offshore ML engineer positions (RAIDD I-03) remain unfilled after candidates declined competing offers. Temporarily reallocate 2 platform engineers from the Data & Cloud Platform Foundation team to BRD-01 for Phase 0 activities (data profiling, environment setup) while Pulaski recruitment sources replacements. Target fill date: 01 Oct 2026. If positions remain unfilled by Phase 1 gate, escalate to Tier 2 for resource plan adjustment.
Impact Assessment
Budget: No impact — temporary reallocation within existing headcount. Schedule: Platform Foundation team absorbs minor velocity reduction during Phase 0 (acceptable since platform build hasn't started). Resource: 2 platform engineers temporarily assigned 50% to BRD-01; returns to 100% platform when ML engineers are hired. Risk: If recruitment extends beyond Oct 2026, escalation required.
Change Control Tiering
| Tier | Impact Criteria | Approval Authority | Turnaround |
|---|---|---|---|
| Tier 1 | Within Program Director's standing authority: schedule ≤2 weeks, resource <5 FTEs, budget reallocation <$500K, no scope change | Program Director (C. Tyrrell) | 5 business days |
| Tier 2 | Exceeds standing authority: scope change (any), schedule >2 weeks, budget >$500K, resource ≥5 FTEs or ≥2 leads, model governance change | Relevant Board: ESB (scope/budget/schedule), AI Gov Board (model governance), EARB (architecture/vendor) | 10 business days |
| Tier 3 | Exceeds board authority: contingency >$1M, program viability, regulatory escalation, Charter re-baseline | Executive Sponsor (M. Kavanagh) + CFO | 15 business days |
4. How to Submit a Change Request
Any program team member may submit a change request. The request must include:
- What is changing: Specific description of the proposed change.
- Why: Business justification — what problem does this solve or what opportunity does it create?
- Impact assessment: Effect on scope, schedule, budget, quality, and risk.
- Alternatives considered: At least two alternatives to the proposed change, with reasons for rejection.
- Recommendation: The requestor's recommended action.
Submit to the Program Director (C. Tyrrell) via the project portal change request form. The Program Director will assess impact, classify the tier, route to the appropriate authority, and communicate the decision within the defined turnaround. All decisions — including rejections — are logged in this Change Control Log.