Enrollment & Claims Platform Modernization

Build, test and production environments for the program. Consumption-priced. Issued under the governing master agreement.

SOW-005 · Infrastructure and Hosting Services

1 · Parties and Instrument

2 · Scope

Every other workstream on this program depends on environments existing, being stable, and resembling production closely enough that a test result means something. The Vendor provides them. This is the least visible Statement of Work in the suite and the one whose failure stops the most work: an offshore test team with no environment is idle capacity being paid for, and a performance test against an under-provisioned environment produces a number nobody can act on.

The engagement covers build, test and production environments through go-live and into the warranty period. Environment configuration is the Client's; the platform on which it runs is the Vendor's. That line matters when something breaks at three in the morning, so it is drawn here rather than during the incident.

In scope. Provision and operation of the build, test and production environments; capacity to the agreed specification per environment; backup and restore to the agreed objectives; environment availability monitoring and incident response to the service levels below; and access management to the Client's directory.

Out of scope. Application configuration and deployment, which are the Client's. Application-level defects, whatever they look like from the infrastructure side. Test data creation or masking. Any change to the Client's security policy. Capacity beyond the agreed specification without a variation.

Anything not described in this section is out of scope. The boundary between an infrastructure incident and an application defect is stated in Terminology precisely because that is the argument this kind of engagement usually has.

3 · Approach

Environments are provisioned in the order the program needs them — build first, then test, then production — so that no environment sits paid-for and unused, and none is needed before it exists. Each is built from the same definition, and any deliberate difference between them is recorded rather than discovered later during a failed deployment.

Pricing follows consumption rather than a fixed monthly fee. The program's environment demand is genuinely uneven — the test environments carry load during cycles and almost none between them — and a flat fee would either overcharge the quiet periods or force the program to keep capacity it does not need. The committed environment budget is a ceiling for planning, not a floor for billing.

Incident response is measured from detection rather than from the Client's report, because an outage the Vendor's monitoring sees first should not wait for someone on the Client side to notice. Availability is reported monthly against the service levels, and a service level that is not reported is not being managed.

Restore is proven rather than promised. A backup that has never been restored is an assumption, and the restore test is a deliverable of this engagement for that reason.

4 · Delivery Phases

Phase 1 — Build and test environments

The environments the program needs first, provisioned and proven.

Phase 2 — Production environment and resilience

Production provisioned, and backup and restore proven rather than assumed.

Phase 3 — Steady-state operation

Environments operated to the service levels, with monthly reporting the Client can act on.

5 · Acceptance

Each Deliverable is submitted with the evidence its acceptance criteria call for. The Client has the stated Review Period to accept, or to reject in writing with specific, criterion-by-criterion reasons. Silence for the whole Review Period is acceptance — deemed acceptance — because a program cannot hold a supplier to a date while leaving its own review open-ended.

A rejection must identify which criterion failed and how. An objection that the Deliverable is not what was expected, where it meets every stated criterion, is a variation rather than a rejection. The Vendor re-submits within ten Business Days and a second Review Period of five Business Days runs. A Deliverable rejected twice on the same criterion is escalated rather than looped.

The Review Period is deliberately short and deliberately symmetrical. The Client gains a fixed window in which to find defects; the Vendor gains certainty that the window closes.

6 · Timeline and Resourcing

Environments are needed in program order, so Phase 1 is the critical path for every other workstream and Phase 2 must complete before the first production deployment. Phase 3 runs to warranty exit at program closeout on Nov 2, 2027.

The table below shows who is involved on each side. ⚠ The $601,500 Infrastructure/DevOps & Security Labor line in the Project Budget is the Client's own staffing and is not charged under this SOW; it is shown so that the two lines are not read as one.

7 · Fees and Payment

Charged monthly in arrears on measured consumption, against a committed environment budget of $480,000. The budget is a ceiling for planning rather than a floor for billing: the Client pays for what the environments actually consume.

• Consumption is evidenced by the monthly service report. Consumption not shown in a service report is not payable.
• The Vendor notifies the Client in writing on reaching 80% of the committed budget. Consumption beyond it requires a variation.
• Time an environment is unavailable below its service level is credited against the following month.

Invoices are payable thirty days from receipt of a correct invoice. The Client may withhold the disputed portion, and only that portion.

8 · Assumptions

The dates and the price in this Statement of Work rest on the following. Each is stated so that its failure is visible rather than argued about later; where one fails, the consequence is handled under Project Variations.

• Environment specifications are agreed in writing before provisioning. An environment provisioned against a verbal specification is not acceptable to either party.
• The Client's directory is available for access-management integration during Phase 1.
• Consumption stays within the committed environment budget of $480,000. The Vendor notifies the Client in writing at 80% of the budget.
• Capacity requirements do not change materially after Phase 2. A material change is a variation, priced before it is provisioned.
• Application deployment and configuration remain the Client's throughout. The Vendor does not deploy the application.
• Test data creation and masking remain the Client's. The Vendor provides the environment, never its contents.

9 · Project Variations

Either party may propose a variation. The Vendor prices it within five Business Days, stating the effect on fees, on dates, and on any other Deliverable. No variation takes effect until both parties sign, and work performed in anticipation of one is at the Vendor's own cost — the clause exists so that goodwill work does not arrive later as an invoice.

Where an assumption in the preceding section fails, the consequence is handled here rather than absorbed silently. A failed dependency moves the affected dates by the period of delay and no more; it does not reopen scope or price unless the parties agree that it should.

A variation that alters the program baseline set at the Nov 3, 2026 milestone is additionally subject to program change control and the Change Control Board, not to this SOW alone. A change within the SOW is a commercial matter between the parties; a change to the baseline is a program matter that other work packages depend on.

10 · Terminology

11 · Governing Agreement

This Statement of Work is issued under the Master Services Agreement between the parties and creates no rights independent of it. Warranty, limitation of liability, intellectual property, confidentiality, data protection, insurance, termination and dispute resolution are governed by the MSA and are not restated here. Restating them invites the two documents to disagree, and a Statement of Work that contradicts its own master agreement is worse than one that is silent.

Where the Vendor handles protected health information, the parties' Business Associate Agreement governs and prevails over both this SOW and the MSA to the extent of any conflict. On any other matter the order is: the BAA, the MSA, this SOW, then an executed variation, which prevails over this SOW only on the matter it changes. The Vendor's standard terms — in a portal click-through, an invoice footer or an order acknowledgement — are excluded.

12 · Execution

Executed following the approval convention this suite uses in SOW-001: the Vendor / Procurement Manager signs for the Client, the Vendor signs through its own authorized representative, and the internal approvals below are recorded separately. ⚠ The Program Manager approves but does not sign — program authority is not signing authority, and the separation is deliberate.

⚠ The Vendor is deliberately unnamed throughout this suite, so the vendor signature line carries a role rather than a person. That is the convention, not an omission — and an unexecuted Statement of Work does show a blank signature line on both sides. The Client side names individuals because they are the program's own people, who appear by name across the rest of the suite.