Hybrid Delivery Methodology Guide

This guide defines how Project Catalyst delivers work — not what it delivers (that is the BRDs) or who governs it (that is the Governance Model), but how the program moves from requirements to production AI at scale across 36.5 months. The methodology integrates three layers that conventional project management treats separately: phase-gated program governance (waterfall structure for regulatory compliance and executive sign-off), agile sprint execution (iterative development within each BRD delivery team), and governed MLOps lifecycle (AI-specific model development, validation, deployment, and monitoring). This integration is the program's central methodological innovation — and the reason it works in regulated healthcare where pure agile cannot and pure waterfall should not.

1. Why Hybrid: The Case Against Pure Methodologies

Every delivery methodology encodes a bet about where risk lives. Waterfall bets that the largest risk is building the wrong thing, so it front-loads requirements, design, and sign-off to eliminate ambiguity before a line of code is written. Agile bets that the largest risk is discovering too late that the plan was wrong, so it defers commitment, ships in small increments, and lets feedback rewrite the plan continuously. Both bets are correct — for different parts of the same program. Project Catalyst delivers regulated healthcare AI for a national insurer with roughly four million members; the cost of building the wrong prior-authorization model and the cost of discovering a fairness defect too late are both unacceptable. A methodology that optimizes for only one risk leaves the other unmanaged. That is the whole argument for hybrid delivery, and it is worth making precisely rather than as a slogan.

1.1 Where Pure Waterfall Fails for AI

Waterfall assumes requirements can be fully specified up front and that a correct design, faithfully built, produces a correct system. Neither assumption survives contact with machine learning. A prior-authorization model's behavior is not designed — it is learned from data, and its real characteristics (accuracy on rare procedure codes, disparate impact across member cohorts, calibration under distribution shift) are unknowable until the model is trained on production-representative data and measured. You cannot write "the model shall achieve 94% precision on adverse determinations" into a requirements document and treat it as a design constraint the way you would treat "the API shall respond in under 200ms." The number is an outcome to be discovered and validated, not an input to be specified. A pure-waterfall program discovers its model's true behavior at the end, in the test phase, when the schedule and budget are already committed and the only options are ship-anyway or blow the plan. For AI in a regulated domain, both options are failures.

1.2 Where Pure Agile Fails for Regulated Healthcare

Pure agile assumes the team can deploy the increment it just built, gather real feedback, and adjust. In regulated healthcare AI, it cannot. A model that influences claims payment or prior-authorization decisions cannot be shipped to production because a sprint ended and the demo went well. It requires independent model validation, documented fairness testing, a security threat assessment, an explainability record a regulator can read, and formal sign-off from bodies that do not sit on the sprint team and do not operate on a two-week cadence. Industry commentary in 2026 is blunt about what happens when organizations skip this: firms adopt a responsible-AI framework, write the governance policy and produce an AI inventory, then quietly drop the measurement discipline because nobody built the infrastructure to benchmark risk consistently — the result is paperwork without practice, a framework that exists on the intranet while operational reality is unchanged. Pure agile has no structural place to put the phase-gated, auditable sign-offs that a regulated program is legally required to produce. Bolting them on after the fact is how programs end up with governance theater.

1.3 The "Water-Scrum-Fall" Trap and How Catalyst Avoids It

The naïve hybrid — often called "water-scrum-fall" — is well documented and widely criticized. It puts a waterfall requirements phase in front, a scrum build phase in the middle, and a waterfall deployment phase at the end. The critique, sharpened in recent practitioner writing, is that this frequently degrades into a fiction: if all the meaningful decisions are made in the upfront framing phase and every deployment is sequential and gated, the sprints in the middle are illusions — internal mini-waterfalls wearing agile ceremonies. Teams hold standups and burndown charts, but they have no real authority to change scope, so the "agile" layer produces motion without adaptation.

Catalyst is designed specifically to avoid this failure mode, and the design choices are explicit:

• Requirements are locked at the level of intent, not solution. The JAD series and BRD sign-off fix what a model must achieve and what it must never do (the human-review requirement for adverse determinations, the fairness threshold, the escalation protocol). They do not pre-decide model architecture, feature sets, or thresholds. Those are genuine open questions the sprint teams resolve through experimentation. There is real design work left inside the sprints — which is what makes the sprints real.
• Product Owners hold delegated authority to reprioritize within the locked scope. A Product Manager can re-sequence the backlog, split or merge stories, kill an approach that experimentation disproved, and pull work forward — without a change request — as long as the BRD's committed outcomes and guardrails are unaffected. Change control governs the baseline, not the day-to-day.
• Deployment is progressive, not a single sequential "fall." The end of the pipeline is not one big-bang cutover after a documentation phase. It is a governed progressive rollout — shadow mode, canary, gradual traffic shift — described in Section 20. The "fall" is replaced by a controlled release ramp that keeps failure recoverable.

The distinction matters because an evaluator who knows this literature will look for exactly these tells. A hybrid that cannot point to real decision authority inside its sprints is water-scrum-fall with better branding. Catalyst can.

2. Design Principles

Seven principles govern every methodological choice in this guide. When two practices conflict, these principles are the tie-breaker, in roughly this priority order.

3. The Three-Layer Model

Catalyst runs three delivery layers concurrently. They are not sequential phases of one process; they are three simultaneous systems operating on different cadences, connected at defined handoff points. Understanding the methodology means understanding what each layer owns, what cadence it runs on, and where it hands off to the others.

3.1 How the Layers Relate

The relationship is best understood as nesting and interlock, not stacking:

• Layer 2 runs inside Layer 1. Sprints execute within a phase. A phase gate does not interrupt a sprint mid-flight; the program sequences gates to fall on sprint boundaries, and the pre-gate freeze (Section 21) is when sprint teams finish documentation and defect work rather than starting new build.
• Layer 3 runs inside Layer 2. Model development work is sprint work — experiments, pipelines, and evaluations are stories on the sprint backlog with story points and acceptance criteria. But the model lifecycle has its own state machine (experiment → validation queue → registry → staged deployment → production → monitoring) that spans multiple sprints and does not reset at sprint boundaries. A model in the validation queue does not "un-validate" because a sprint ended.
• The three layers connect at four named handoffs: JAD-to-Sprint (Layer 1→2), Sprint-to-Validation (Layer 2→3), Validation-to-Gate (Layer 3→1), and the Monitoring feedback loop (Layer 3→2, and on material context change, Layer 3→1). Parts V and VII describe each handoff as an operational procedure with entry criteria, artifacts, and owners.

3.2 A Worked Example: One Requirement Through All Three Layers

Consider a single BRD-01 requirement: "The system shall auto-approve prior-authorization requests that meet clinical criteria, and shall route all adverse or ambiguous determinations to a licensed clinical reviewer." Trace it through the layers:

• Layer 1 locks this requirement at JAD sign-off with Legal, Compliance, and clinical SMEs in the room. The human-review guardrail is now a baseline commitment; removing or weakening it requires a change request and board approval. This is the requirement's governance anchor.
• Layer 2 decomposes it into epics and stories: the criteria-matching service, the routing engine, the reviewer work queue UI, the audit logging, the fallback path when the model is unavailable. The Product Manager sequences these across sprints; the team estimates and builds them iteratively, demoing each increment.
• Layer 3 owns the model at the center: the auto-approval classifier is trained, evaluated for accuracy and disparate impact, submitted to Independent Model Validation, registered, deployed in shadow mode against live traffic, promoted through canary, and then monitored for drift — with the human-review path as the always-on safety net that makes the staged rollout safe.

The requirement is one thing to the business. It is three streams of work to the program, each on its own cadence, reconnecting at the gates. That is the methodology in miniature.

4. Five-Phase Structure

Layer 1 organizes each BRD delivery cycle into five formal phases, Phase 0 through Phase 4. The phases provide the waterfall backbone: predictable checkpoints where scope is baselined, risk is re-assessed, budget is authorized for the next tranche, and the program earns the right to proceed. The full phase definitions, durations, and gate criteria are maintained in the Program Management Plan Section 4; this section explains the logic of the structure and how it interlocks with the sprint and model layers.

4.1 Why Five Phases and Not a Continuous Flow

A pure-agile purist would ask why the program does not simply flow continuously from idea to production. The answer is that four distinct constituencies need a defined moment to accept risk on the record, and those moments are the phase gates:

• The Executive Steering Board needs a moment to authorize the next tranche of the $99M budget against demonstrated progress, rather than signing an open-ended check.
• The AI Governance Board needs a moment to confirm that no model has advanced toward production without the responsible-AI controls that make ACME defensible to a regulator.
• The Enterprise Architecture Review Board needs a moment to confirm the technical design and security posture before build is committed at scale.
• Compliance and SOX need a moment, on claims-payment and financial-reporting items, to confirm the controls that keep ACME's financial reporting defensible.

These are not agile-vs-waterfall preferences. They are the points at which named executives put their name on a risk decision. The phase structure exists to give those decisions a defined, documented, auditable home.

4.2 How Phases Map Across the Three BRD Legs

The five-phase cycle repeats across the program's three delivery legs, but not identically. BRD-01 (Year 1) runs the full five-phase cycle as the flagship, establishing the platform and the governance muscle memory. BRD-02 and BRD-03 (Year 2) run concurrently and reuse the Phase 0 foundation — the platform, the CoE, the validation function already exist — so their cycles begin at a lighter Phase 0 (a scoped readiness confirmation rather than a full stand-up) and move faster through Phase 1 because the JAD machinery and architectural patterns are proven. Year 3 (Optimization & Sustain) does not run a delivery phase cycle; it runs continuous-improvement and transition-to-operations work under a lighter governance cadence. The phase structure is a template applied with proportionality, not a rigid stamp.

5. Phase-Gate Process & Criteria

The phase-gate sign-off procedure is mandatory and invariant across all gates. It is specified in full in the Program Management Plan Section 4.2 and the Program Governance Model; this section states the criteria logic — what a gate actually tests, and what distinguishes a real gate from a rubber stamp.

5.1 The Gate Timeline

5.2 What a Gate Actually Tests

A gate is not a status meeting. It tests four things, and a package that cannot answer all four is not ready to be tabled:

• Completion with evidence. Not "the model is done" but "here is the validation report, the test results, and the sign-off." Every claimed deliverable carries a pointer to the artifact that proves it. A completion matrix with unbacked green cells is a rejected package.
• Risk re-assessment. The RAIDD delta since the last gate is mandatory. New risks, changed severities, closed items, and — critically — any risk the previous gate accepted that has since materialized. A gate that shows no risk movement across a 12-week phase is not credible and invites scrutiny rather than avoiding it.
• Forward viability. The next-phase resource plan and budget forecast must show the program can actually execute the phase it is asking to enter. Approving Phase 2 without a confirmed build team is approving a wish.
• Guardrail integrity. On any gate touching a model that affects claims, coverage, or pricing, the AI Governance Board confirms the locked guardrails (human review of adverse determinations, fairness thresholds, escalation protocols) are intact and evidenced. This is the check that keeps the program defensible.

5.3 Gate Outcomes and the Rejection Protocol

6. Governance Board Integration

Three standing boards hold phase-gate authority, with Compliance and SOX as a standing reviewer on financial and claims-payment items. Their full composition, charters, and decision rights are in the Program Governance Model. This section describes how the boards integrate with the delivery cadence — the part most methodologies leave implicit and therefore break.

6.1 The Integration Problem Boards Usually Create

The standard failure of board governance over agile teams is cadence mismatch: sprint teams operate on two-week cycles and need decisions in days, while boards meet monthly and deliberate over weeks. If every model decision waits for the next board meeting, the sprint teams stall, and the program either grinds to board speed or the teams route around the boards — which is how shadow AI and ungoverned models appear. Catalyst resolves this with three mechanisms:

• Delegated authority with thresholds. The Program Director and named leads hold documented authority to make decisions below defined risk and budget thresholds without convening a board. Boards set the guardrails; teams operate freely inside them. Only decisions that cross a threshold — a new high-materiality model, a scope change to a baseline, a budget draw on contingency — escalate.
• Standing between-gate cadence. The AI Governance Board and EARB meet bi-weekly during active development precisely so that model and architecture decisions do not wait for a phase gate. The gate is where the phase is accepted; the bi-weekly cadence is where the phase is steered.
• An always-available validation queue. Independent Model Validation (P. Okafor's function) runs continuously, not on a board cadence — models enter the queue as they are ready and are reviewed in 5–10 business days, decoupling model progress from the board calendar. The board reviews the validation function's output; it does not perform the validation.

6.2 How a Model Decision Actually Flows

To make the integration concrete, here is the path of a single production-authorization decision for a BRD-01 model:

• The delivery team completes model development and internal evaluation within its sprints (Layer 2/3). This needs no board.
• The model enters the Independent Model Validation queue. Validation performs effective challenge and issues a report (Layer 3). This needs no board — it is the second line of defense doing its job.
• The validation report, with any findings, goes to the AI Governance Board at its bi-weekly cadence. If validation is clean and the model is within its tier's authority, the board authorizes production. If findings are open, the board withholds authorization until they close.
• At the next phase gate, the AI Governance Board confirms — as part of guardrail integrity — that every model advanced to production carries a clean validation record and a board authorization. The gate does not re-litigate the model; it confirms the process was followed.

Notice that the board makes exactly one binary decision (authorize production, yes/no) at the point where risk is actually accepted, and confirms process integrity at the gate. It does not sit in the sprint. That separation — boards own risk acceptance, teams own execution, validation owns challenge — is the whole architecture of Layer 1.

7. Sprint Framework

Within each phase, the delivery teams execute in two-week sprints. This is where the program's iterative engine lives — the layer that lets a model's true behavior be discovered and refined rather than specified and hoped for. The sprint framework is deliberately conventional Scrum in its mechanics; the sophistication is in how it interlocks with the model lifecycle (Part IV) and the phase gates (Part II), not in reinventing ceremonies.

7.1 Sprint Cadence and Structure

7.2 What Is and Is Not a Sprint Deliverable

A subtlety unique to AI programs: not everything valuable a team produces in a sprint is a shippable increment. A sprint might deliver a trained candidate model that then sits in the validation queue for 5–10 days before it can advance — the sprint's "done" is "model trained, evaluated, and submitted to validation with a complete model card," not "model in production." Conflating these is exactly the water-scrum-fall trap in miniature. The sprint framework therefore recognizes two kinds of sprint output:

• Shippable increments — conventional software (APIs, UIs, pipelines, integrations) that meet the Definition of Done and can move toward release through normal deployment.
• Validation-gated artifacts — trained models and model changes that meet the sprint's DoD but require independent validation and board authorization before they can reach production. These are "done" as sprint work while still being "not yet in production" as program artifacts.

The sprint is complete when both kinds of output meet their respective definitions of done. A team is not blocked from closing a sprint because a model is in the validation queue — that is expected, planned-for latency, accounted for in the model's own state machine (Part IV).

8. Scrum Roles Adapted for AI Programs

Standard Scrum defines three roles: Product Owner, Scrum Master, Development Team. In a 262-person, 25-team regulated AI program, these roles need adaptation — not abandonment. The adaptations are precise and each solves a specific problem that vanilla Scrum does not anticipate.

8.1 The Deliberate Non-Membership of Validation

The single most important role decision in the methodology is what is excluded from the sprint team. Independent Model Validation (P. Okafor's function) is the program's second line of defense, and it is deliberately not a member of any delivery team. This is not an oversight; it is a control. Model-risk guidance is explicit that organizational separation on paper does not satisfy independence if validators report to the same manager as developers or if the business line sets their agenda — "nominal independence" is one of the most common examination findings. If validation sat inside the sprint team, its challenge would be captured by the team's delivery pressure and its independence would be fictional. So validation reports through a separate line, runs its own queue, and has standing to fail a model regardless of the sprint's schedule. The sprint team plans around validation as an external dependency; it does not contain it. Part VIII (§32) details the model-specific roles; this section flags the structural boundary because it is a methodology decision, not just an org-chart line.

8.2 The Product Manager / Program Director Boundary

A recurring source of confusion in hybrid programs is the relationship between the agile Product Manager and the program-governance Program Director. The boundary is clean once stated: the Program Director owns the program (scope baselines, gates, budget, cross-team coordination, board relationships); the Product Manager owns the product backlog within one BRD (what gets built next, decomposition, day-to-day trade-offs inside the baseline). The Program Director does not set sprint priorities; the Product Manager does not authorize scope changes or accept program risk. When a sprint-level trade-off implies a baseline change — dropping a committed requirement, missing a milestone, exceeding a budget line — it stops being a Product Manager decision and becomes a change request the Program Director carries to the appropriate board. That escalation trigger is the seam between Layer 2 and Layer 1.

9. Sprint Ceremonies

Each delivery team runs the standard ceremony set, timeboxed and consistent across teams so that cross-BRD synchronization holds. The ceremonies are conventional; what matters for this methodology is the two AI-specific additions and how the model lifecycle threads through the standard events.

9.1 The Model Risk Triage Ceremony — Why It Exists

The weekly Model Risk Triage is the one ceremony a conventional agile program would not have, and it earns its place by economics. Independent validation is a finite, expensive resource on a 5–10 day cadence; a model rejected from the validation queue for a fixable gap (an incomplete model card, an unimplemented guardrail, a missing bias test) wastes a full validation cycle and a sprint. The triage catches those gaps a week early, inside the team, with a governance liaison present. It is a cheap check that protects an expensive one — pure proportionality (design principle 5). It also keeps governance felt by the team weekly rather than experienced only as an external gate, which is how governance culture actually forms.

10. Backlog Management & Prioritization

The backlog is the bridge between the JAD-locked requirements (Layer 1) and the sprint work (Layer 2). Its discipline is what keeps the "agile" layer honest — a well-managed backlog with real prioritization authority is the difference between genuine iteration and water-scrum-fall's illusory sprints.

10.1 Backlog Hierarchy

Every item traces upward to a BRD requirement. This is not bureaucracy — it is the requirements traceability that regulated delivery requires (design principle 6). At any moment, the program can answer "which requirement does this work satisfy?" and, in reverse, "which stories, models, and tests satisfy this requirement?" That bidirectional trace is a phase-gate artifact and an audit necessity.

10.2 Prioritization Method

The Product Manager prioritizes using a weighted model that balances four factors, with governance-critical work protected from being deprioritized by delivery pressure:

• Regulatory / guardrail criticality — work that implements a locked guardrail (human review, fairness testing, audit logging) is prioritized ahead of feature richness. A guardrail is never traded for a feature.
• Dependency unblocking — work that unblocks other teams or the shared platform is pulled forward (managed via Scrum-of-Scrums).
• Risk reduction — spikes that retire a major unknown early (the agile risk curve: reduce uncertainty fastest) are favored when uncertainty threatens estimation.
• Business value — the MoSCoW prioritization from the BRD (Must / Should / Could / Won't) sets the base value ranking within the locked scope.

11. Definition of Ready & Definition of Done

DoR and DoD are the quality gates inside the sprint — the agile-layer analog to the phase gates. They are ratified per BRD in Sprint 0 and are especially consequential for AI work, where "ready" and "done" mean more than they do for conventional software.

11.1 Definition of Ready (DoR)

A backlog item is Ready to be pulled into a sprint only when:

11.2 Definition of Done (DoD)

An item is Done only when it meets every applicable criterion. The DoD is layered — a story's DoD and a model's DoD differ, and a model's "done" explicitly does not mean "in production."

12. Velocity, Burndown & Forecasting

Velocity and burndown are the agile layer's instruments — they make the sprint teams' progress legible to Layer 1 without forcing Layer 1 to watch sprints. Their reporting rolls up into the monthly status report and the phase-gate package.

12.1 Velocity

Each team tracks velocity (story points completed per sprint) to forecast capacity and detect trouble. Two AI-specific cautions apply:

• Model work has lumpier velocity than software work. An experiment sprint may deliver few points while a model is being tuned, then a burst when it clears. Velocity is read as a trend over several sprints, never as a single-sprint verdict — a low-point sprint spent reducing a major model unknown can be the highest-value sprint in a phase.
• Validation latency is not team velocity. Time a model spends in the independent validation queue is not counted against or for the team's velocity — it is a separate lifecycle state (Part IV). Blending them corrupts both the velocity signal and the validation timeline.

12.2 Burndown and Burnup

Sprint burndown tracks remaining work within a sprint; release burnup tracks cumulative scope completed toward a phase or BRD milestone. The burnup is the more useful instrument at the program level because it shows scope and scope change — a rising total line signals scope growth that should be flowing through change control, making the burnup an early-warning device for uncontrolled scope creep as well as a progress report.

12.3 Forecasting Into the Phase-Gate Structure

The forecasting obligation is where Layer 2 and Layer 1 meet on the calendar. Each team's velocity trend and burnup feed a projection: will the committed Phase-N deliverables complete before the Phase-N gate? The Program Director aggregates these into the gate's forward-viability assessment (§5.2). A forecast miss surfaced three sprints out is a manageable conversation about scope, resourcing, or a change request; the same miss discovered at the gate is a crisis. The entire point of instrumenting the sprints is to convert late surprises into early, governable decisions.

13. Cross-BRD Coordination

Three BRD delivery teams, plus two cross-cutting workstreams (AI Governance & CoE, Data & Cloud Platform), share one platform, one validation function, and one set of governance boards. Coordinating them without collapsing back into central command is the scaling problem of Layer 2.

13.1 The Scrum-of-Scrums

The primary coordination mechanism is the twice-weekly Scrum-of-Scrums: the Program Director, each team's Scrum Master, and the Platform Lead, in a 15-minute standing sync focused exclusively on cross-team dependencies and shared-resource contention. It is not a status meeting (status flows through the tools); it is a blocker-resolution meeting. Typical items: BRD-02 needs a platform capability BRD-01's team is building; two teams' models are queued for validation the same week and the sequence must be set; a shared data pipeline change affects three teams' features.

13.2 Shared-Resource Contention and Its Rules

13.3 The Two Cross-Cutting Workstreams as Services, Not Gatekeepers

The AI Governance & CoE workstream and the Data & Cloud Platform workstream are cross-cutting — every BRD depends on them. The methodology's stance is that both operate as enabling services to the delivery teams, not as gatekeepers that delivery must petition. The CoE provides standards, patterns, reusable governance tooling, and the governance liaisons who sit in Model Risk Triage; the Platform provides the MLOps pipelines, feature store, model registry, and monitoring that make Layer 3 possible. When a cross-cutting workstream becomes a bottleneck — delivery waiting on a CoE approval or a platform capability — that is a coordination failure surfaced at Scrum-of-Scrums and resolved by re-prioritization, not by teams routing around the service (which is how shadow AI and ungoverned pipelines are born). The health of these two workstreams as services rather than blockers is a leading indicator of the whole program's methodological health.

14. MLOps Within the Sprint Cadence

Layer 3 is the layer that makes this an AI program rather than a software program with models bolted on. It governs the model's whole life — data in, model out, monitored in production, retrained when it decays. It runs continuously and event-driven, spanning many sprints, with its own state machine that does not reset at sprint boundaries. This part specifies that lifecycle and the governance welded into every stage of it.

14.1 The Model State Machine

Every model in the program moves through a defined set of states. The states are program-level facts (tracked in the model registry), independent of which sprint is running:

15. Model Experimentation & Training

Experimentation is where a model's real behavior is discovered — the reason the whole program needs an iterative layer. It is also where the most consequential governance decisions are quietly made, because the choices made in experimentation (what data, what features, what objective) determine what the model can and cannot become.

15.1 Reproducibility as a Hard Requirement

Every experiment and training run must be reproducible: the same versioned data, code commit, feature set, and hyperparameters must reproduce the same model. This is not a research nicety; it is an audit and incident-response necessity. When a regulator asks "how was the model that denied this claim built?" or an incident requires reconstructing a past prediction, the program must be able to reconstruct exactly why a model produced a given prediction at a given time, using the data version, feature values, and model version active at that moment. Non-reproducible experiments are not permitted to produce candidate models — a model that cannot be rebuilt cannot be validated or defended.

15.2 The Experiment-Tracking Discipline

• Every run is logged — parameters, metrics, datasets, and artifacts captured in an experiment-tracking system (the MLflow-class tooling standard in 2026 MLOps stacks), so results are comparable and the path from experiment to candidate is a record, not a memory.
• Evaluation is multi-dimensional from the first run — accuracy is necessary but never sufficient. Fairness/disparate-impact, calibration, and robustness are measured from early experiments, so a model that is accurate-but-unfair is caught in experimentation rather than at validation. Discovering a fairness defect at validation is a wasted cycle; discovering it in experimentation is a normal Tuesday.
• Negative results are retained — approaches that failed are recorded with why, both to prevent re-treading them and because "we tried X and it produced disparate impact, so we chose Y" is exactly the design rationale a validation report and a regulator want to see.

15.3 The Objective-Function Governance Point

16. Data Pipeline Governance

Models are downstream of data; ungoverned data guarantees ungovernable models. The data-pipeline layer is where a great deal of the program's real risk lives, and where the most common silent failures originate.

16.1 Data Validation as a Control Boundary

Most systems treat data ingestion as a background process; a governed MLOps program treats it as a control boundary. Data schemas, feature transformations, and model outputs are all validated through automated checks, and any change in code or configuration automatically triggers validation in the pipeline. Data that fails validation — schema drift, out-of-range values, unexpected nulls, distribution anomalies — is quarantined before it can enter training or serving. The principle is that bad data should fail loudly at the boundary, not silently corrupt a model that then behaves strangely in production for weeks before anyone notices.

16.2 Data Lineage and PHI Governance

16.3 Feature Staleness and Drift at the Data Layer

The feature store is monitored not just for availability but for staleness and drift — a feature whose real-world distribution has shifted will silently degrade every model that consumes it. Catching drift at the feature layer is more powerful than catching it per-model, because one drifting feature can be the root cause of several models decaying at once; fixing it at the source fixes them all. Feature-level drift monitoring is therefore a first-class part of the data-pipeline governance, feeding the same alerting that model-level monitoring feeds (§27).

17. Model Registry & Version Control

The model registry is the system of record for Layer 3 — the model's equivalent of the change control log. If it is not in the registry with a clean lineage and a governance state, it does not exist as far as the program is concerned, and it certainly does not reach production.

17.1 What the Registry Governs

• Versioned model artifacts — every model and every version, immutable once registered, each carrying its full lineage (data version, feature set, code commit, hyperparameters, training run).
• Governance state — the registry records each model's state in the state machine (§14.1): candidate, in validation, validated, authorized, shadow, canary, production, retiring. Stage transitions are gated by automated compliance checks. Automated compliance checking validates models against policy requirements before stage transitions — verifying documentation completeness, bias-testing completion, and security-scanning results.
• Model cards — the human-readable record: purpose, intended use, training data, evaluation results, fairness testing, limitations, known risks, and the accountable owner. The model card is the artifact a validator, a board, and a regulator all read.
• Approval and audit trail — who submitted, who validated, who authorized, when each transition happened, and on what evidence. The registry is the immutable answer to "who approved this model for production and on what basis?"

17.2 The Model Inventory Obligation

17.3 Risk-Based Model Tiering

Not every model carries the same governance burden — that would be disproportionate and would starve the high-risk models of the scrutiny they need. Every registered model is assigned a risk tier that scales its validation depth, monitoring intensity, and re-validation frequency (design principle 5, proportionality):

Tiering is assigned at registration and reviewed if a model's use changes — the repurposing risk (§17.2) means a Tier 3 model quietly put to a Tier 1 use is a governance failure, so use-change triggers re-tiering.

18. Continuous Integration for ML

CI/CD for ML applies DevOps discipline to the model lifecycle, and it is where "governance by default" (design principle 3) becomes literal: the compliant path is automated so thoroughly that it is the only path.

18.1 The ML CI/CD Pipeline

18.2 Automated vs. Independent Validation — Not the Same Thing

18.3 Governance By Default

The payoff of this automation is cultural as much as technical: when every stage transition runs the same checks every time, the team gets governance by default rather than governance by effort. No one has to remember to run the bias test — the model cannot advance without it. No one has to police documentation — an incomplete model card blocks promotion. The compliant path is the path of least resistance, which is the only kind of governance that survives schedule pressure over a 36.5-month program. Governance that depends on heroics fails the first time a deadline and a shortcut meet; governance welded into the pipeline does not.

The three layers are only a methodology if they connect cleanly. Most hybrid programs fail not within a layer but at the seams — the handoffs where waterfall governance, agile execution, and the model lifecycle must exchange work without dropping it or deadlocking. This part specifies each seam as an operational procedure: entry criteria, artifacts exchanged, owners, and the failure mode it prevents.

19. JAD-to-Sprint Handoff (Layer 1 → Layer 2)

The seam: locked requirements become executable backlog.

Joint Application Design sessions (specified in the AI Governance & JAD Charter) run in Phase 1 with mandatory Legal, Compliance, Enterprise Architecture, Cybersecurity, and business-SME seats. They produce a signed BRD — the locked scope and guardrails. The handoff turns that document into a seeded Product Backlog without losing the guardrails in translation.

20. Sprint-to-Validation Handoff & Progressive Deployment (Layer 2 → Layer 3 → Production)

The seam: a model that is "done" as sprint work becomes a governed production deployment.

This is the most important seam in the program, because it is where the temptation to ship-because-the-demo-passed is strongest and the consequences of yielding are gravest. It has two parts: the handoff into validation, and the progressive deployment that follows authorization.

20.1 Into Validation

When a model meets its DoD (§11.2) — trained, evaluated, fairness-tested, model card complete — it enters the Independent Model Validation queue as a Candidate (state 2→3). It has passed Model Risk Triage (§9.1), so the submission is complete. Validation performs effective challenge on its own 5–10 day cadence and issues a report. The sprint team does not wait idle: it continues other backlog work while the model is in validation, because validation latency is a planned lifecycle state, not a team blocker (§12.1).

20.2 Progressive Deployment After Authorization

Once validated and board-authorized (states 4→5), the model does not go straight to full production. It moves through a governed progressive rollout — the modern standard precisely because pushing a new model to 100% of traffic at once is the highest-risk deployment approach, and progressive methods — feature flags, champion/challenger, gradual rollouts — are the 2026 standard because they make failure recoverable:

21. Phase-Gate Freeze Protocol (Layer 2 ⇄ Layer 1)

The seam: the agile layer pauses new commitment so the governance layer can assess a stable picture.

In the 7 business days before a phase gate, the delivery teams enter a freeze: no new sprint work is started that would change the gate package. Teams use the window for documentation, test completion, and defect remediation — hardening what exists rather than adding to it. This prevents the gate from assessing a moving target and gives the boards a stable, evidenced snapshot to judge.

22. Change Control Within Sprints (Layer 2 → Layer 1)

The seam: distinguishing day-to-day agile adaptation from a baseline change that governance must approve.

The Product Manager reprioritizes freely within the baseline; that is agile working as intended and needs no change request. But some sprint-level realities imply a baseline change, and those must flow to the Change Control Log and the appropriate board. The methodology draws the line precisely so teams neither over-escalate (drowning boards in trivia) nor under-escalate (quietly eroding the baseline).

23. Escalation Across Layers

The seam: a fast, unambiguous path for a problem in any layer to reach the level that can resolve it.

Escalation is the safety valve of the whole methodology. Its rule is simple: escalate to the layer that owns the decision, not up a management chain. A model-risk problem goes to the AI Governance Board even if it surfaced in a sprint; a resource conflict goes to Scrum-of-Scrums even if it looks like a model problem; a scope pressure goes to the Executive Steering Board even if it arrived as a technical constraint.

24. Testing Pyramid

Quality in a hybrid AI program has two distinct halves: conventional software testing (deterministic — a function either returns the right value or it does not) and AI testing (statistical — a model is right often enough, fair enough, calibrated enough). Both halves run through the layers, and confusing them is a category error that produces either untested models or misapplied determinism.

24.1 The Software Testing Pyramid

Most testing effort lives at the base (many fast unit tests, fewer slow system tests) — the conventional pyramid. The QA & Testing team (a billable onshore/offshore blend) owns system-level quality; developers own unit and integration within their sprints.

25. AI-Specific Testing

The AI half of quality has no analog in conventional software testing, and it is where a program that only knows software QA fails silently. A model can pass every unit and integration test — the code works perfectly — while the model itself is unfair, miscalibrated, or brittle. AI-specific testing is a separate, mandatory discipline.

26. User Acceptance Testing

UAT confirms the system meets real business need with real users before full production. In this program it carries a specific structural feature: the UAT team is independent of delivery.

26.1 The Independence of UAT

The User Acceptance Testing team (11 people, non-billable, on loan from Operations) reports to its own Operational Testing Manager, independent of the delivery teams. This mirrors the independence logic of model validation (§8.1): acceptance testing performed by the people who built the system is not acceptance testing — it is a demo with a friendly audience. By staffing UAT from Operations (the people who will actually live with the system) and keeping its reporting line separate from delivery, the program gets an honest signal about whether the system works for the humans who must use it. The UAT team's independence is a deliberate control, documented in the Resource Plan, not an org-chart accident.

26.2 UAT in the Phase Structure

• Phase 3 pilot UAT — a controlled user group exercises the system on real scenarios; the >95% pass rate is a phase-gate criterion. A failing UAT blocks production readiness.
• Model-in-the-loop UAT — for decisional models, UAT includes the human-review workflow: reviewers exercise the escalation path, confirm the model routes adverse determinations correctly, and validate that the human override actually works. Testing the guardrail is as important as testing the model.
• Accessibility acceptance — member-facing components meet WCAG 2.1 AA (per the BRD-02 requirements); accessibility is an acceptance criterion, not an afterthought.

Deployment is not the finish line — for an AI system it is the starting line of the longest phase. A model degrades the moment the world it learned from starts to change, and in healthcare the world changes constantly (new procedure codes, shifting utilization, new member populations, regulatory updates). Production operations is where the methodology proves it understands that a model is a living asset requiring continuous care, not a delivered artifact.

27. Production Model Monitoring

Every production model is continuously monitored across four dimensions. Monitoring is not observability-for-its-own-sake; each signal has a threshold, an owner, and a defined action when breached — the NIST AI RMF Measure function's core activity is exactly this: monitoring for bias, drift, and performance degradation and tracking compliance continuously so systems stay reliable and fair as data and context evolve.

28. Retraining Triggers & Process

When monitoring detects decay, the model must be refreshed — but retraining is a governed act, not an automatic overwrite. A model that silently retrains itself into production is an ungoverned model, no matter how good the automation.

28.1 Retraining Triggers

• Performance decay — accuracy/error crosses its threshold (the most common trigger).
• Drift — data or concept drift exceeds tolerance, signaling the model's world has moved.
• Fairness breach — a live disparate-impact signal (highest-priority trigger; may pair with rollback).
• Scheduled review — tier-based cadence (Tier 1 most frequent) catches slow decay before a threshold breach.
• External change — a new regulation, a new procedure-code set, a major population shift, or a policy change that invalidates prior assumptions.

28.2 The Governed Retraining Loop

A retraining event is not a shortcut back to production — it re-enters the lifecycle:

29. Retrospectives & Process Improvement

The methodology improves itself through two feedback cadences operating at different altitudes.

Sprint retrospectives roll patterns up to the program level via the PMO-level agile coach: when three teams hit the same blocker, that is not three team problems but one program problem, and it is fixed at the program level. The phase-gate lessons-learned is where the methodology is deliberately allowed to evolve — a hybrid model that cannot learn from its own execution over 36.5 months will calcify into the very rigidity it was designed to avoid. This guide is a living document; the lessons-learned cadence is how it stays alive.

A hybrid methodology asks people to work in two paradigms at once, and roles designed for one paradigm break in the seam. This part specifies how each family of role adapts — what changes, what does not, and where the genuine difficulty lives. The full named roster and reporting structure are in the Resource Plan and Org Chart; this part is about the behavior each role must adopt for the hybrid to work.

30. How Traditional PM Roles Adapt

31. How Agile Roles Adapt

The recurring theme: agile roles keep their autonomy inside the baseline and gain a new obligation to interface cleanly with the governance and model-lifecycle layers. The autonomy is real (that is what keeps the sprints real); the interfaces are mandatory (that is what keeps the program governed).

32. AI-Specific Roles

Three role families have no equivalent in a conventional program and are the reason Layer 3 can function.

33. The Program Director's Dual-Method Challenge

The role that carries the entire hybrid on its back is the Program Director's, because it is the only role that must live fully in both paradigms simultaneously — accountable to boards for waterfall predictability and to teams for agile autonomy, at the same time, about the same work.

33.1 The Four Tensions the Director Holds

33.2 What Makes This Role Hard, Stated Honestly

The difficulty is not any single decision — it is that the Director must be fluent in both languages and loyal to neither exclusively. A Director who is fundamentally a waterfall PM will strangle the agile layer into water-scrum-fall's fake sprints. A Director who is fundamentally an agile coach will let governance become the theater the program cannot afford in a regulated domain. The role demands someone who can sit in a board gate defending a phase package with waterfall rigor in the morning, run a Scrum-of-Scrums unblocking teams with agile fluency in the afternoon, and — this is the hard part — know which mode each situation actually calls for. That judgment, exercised hundreds of times across 36.5 months, is what the methodology cannot script and what ultimately makes the hybrid work or fail. The structures in this guide reduce how often that judgment is needed and make the easy calls automatic; they do not eliminate the need for it. A hybrid methodology is finally only as good as the person holding its center.