7571TE26Q00036_Draft SOO.pdf

Draft Statement of Objectives (SOO) - HHS AI Power User Advanced Models and Features Pilot

Draft Statement of Objectives (SOO)

DRAFT STATEMENT OF OBJECTIVES

HHS AI Power User Advanced Models and Features Pilot

Industry Feedback Draft

This draft SOO is provided for public and industry feedback. It is not a request for quotations or proposals, does not obligate HHS to issue a solicitation or make an award, and may be revised based on feedback, market conditions, legal review, security review, and acquisition strategy decisions.

1. Purpose The purpose of this acquisition is to obtain short-duration, firm-fixed-price pilot awards that function as inclusive, all-you-can-eat-style access bundles, within a stated usage envelope, for up to [1,000] authorized portable HHS power users per resultant award, with potential priced options to increase the authorized portable-user quantity up to 10,000. The objective is to let power users exercise advanced models, advanced features, integration paths, native apps, reporting functions, administrative controls, and security-boundary options in a forward-leaning enterprise environment before HHS finalizes its broader enterprise AI solution.

The pilot shall enable the Government to baseline actual power-user usage, determine enterprise-feasible operational methodology, identify and roadmap which models and features require configuration or customization, identify levels and timing of customization, establish security and authorization logic, and formulate a common enterprise logical and operational model for AI use at HHS.

HHS requires the pilot to establish a practical operating model for commercial-parity access to advanced AI models and features in a forward-leaning enterprise environment. The contractor shall support HHS in determining how new commercial model releases, advanced features, agentic capabilities, native apps, coding and data tools, APIs, and administrative controls can be made available to Government users with minimal lag relative to commercial release, while satisfying HHS security, privacy, authorization, logging, identity, data-handling, statutory AI governance, and records requirements.

The contractor shall provide a FedRAMP 20x-aligned certification pathway where applicable, including Key Security Indicator mapping, machine-readable or automation-supporting evidence, persistent-validation approach, continuous monitoring evidence, significant-change logic, and agency ATO support artifacts. Where a feature or model cannot be made available to HHS at commercial parity, the contractor shall disclose the gap, cause, authorization dependency, security-boundary issue, required customization, and target availability date to close the parity gap.

HHS's desired end state is to establish a sustainable operational model that maintains or exceeds commercial parity at enterprise scale – continually operationalizing frontier AI innovation into the enterprise, advanced models, advanced features, agentic capabilities, coding capabilities, research capabilities, scientific capabilities, APIs, administrative capabilities, and other newly released commercial capabilities become available to HHS users at or before the time they become available to commercial enterprise customers, except where a documented security, privacy, legal, authorization, compliance, or technical dependency prevents such availability.

2. Background HHS is preparing for broader enterprise acquisition of LLM and related AI capabilities, including potential multiple-award BPA and enterprise license or enterprise agreement task orders. Market research indicates that advanced LLM offerings differ materially in buying channel, security boundary, model and feature availability, release cadence, administrative controls, reporting, API and gateway compatibility, and pricing or consumption meters.

The pilot is intended to generate operational evidence that cannot be obtained from paper market research alone.

HHS needs to observe how power users utilize advanced AI capabilities, how those capabilities map to HHS mission workflows, what guardrails and administrative controls are necessary, what can be enabled immediately, what requires configuration or integration, and what requires additional security, privacy, records, accessibility, or authorization work before enterprise scaling.

Market research supports the following major objective themes: advanced reasoning and chat, coding assistants, data analysis, secure API access, automation and agents, management reporting, OAuth/OIDC and SSO, audit retention and exportable telemetry, a FedRAMP 20x-ready commercial enterprise tenant or equivalent, usage analytics delegated at multiple organizational scopes, and transparent native usage constructs such as tokens, credits, AMUs, requests, messages, searches, tool use, capacity, or equivalent provider-defined units.

3. Scope or Mission The contractor shall provide one integrated pilot bundle for the applicable individual LLM. The bundle shall include access, configuration, onboarding, enablement, usage and adoption reporting, feature-readiness analysis, integration-readiness analysis, security and authorization pathway analysis, statutory AI governance collaboration, use-case inventory support, release-alignment planning, and closeout recommendations.

• Provide inclusive access to all offered advanced models, modes, tools, integrations, and advanced features available in the proposed channel and within the ordered usage envelope for up to [X] authorized portable users.

• Enable HHS to try, compare, and baseline advanced capabilities beyond baseline chat, including premium reasoning, long-context work, document and file workflows, web-grounded research where permitted, code and data analysis where permitted, connectors, memory or personalization where permitted, projects or workspaces, agentic or delegated-work features, API or gateway integration paths, and release-preview or newly released model and feature evaluation paths.

• Document which capabilities are native and ready, native with configuration, API or gateway interoperable, available only in a different security boundary, preview-only, roadmap or future, or requiring customization before enterprise use.

• Provide a customization matrix showing level of customization, owner, dependencies, expected effort band, schedule implications, and whether customization is required before HHS enterprise scaling.

• Provide security-enablement and authorization-pathway logic for each model and feature category, including boundary, data flow, logging, retention, identity, DLP/PII/PHI handling, FedRAMP/cloud posture, BAA/HIPAA posture if applicable, rollback, release approval, and user controls.

• Provide usage baselining sufficient for HHS to understand which features power users use, how often they use them, what workflows they support, what level of administrative support they require, and what future pricing/order structure is most appropriate.

• Provide collaboration with HHS CAIO, OCIO, privacy, cybersecurity, acquisition, legal, records, Section 508, Operating Division, and program stakeholders to support AI use-case inventory, compliance planning, issue reporting, governance operating model formulation, and future acquisition terms.

• Provide a release-alignment and rapid-implementation roadmap for newly released models and features, including the steps needed to make eligible releases available to Government users with minimal lag relative to commercial release.

• Provide final recommendations for HHS's anticipated AI BPA and ELA task orders, including CLIN structures, evaluation factors, reporting terms, integration expectations, security terms, option or surge structures, governance artifacts, and product/channel segmentation.

4. Definitions

Term Meaning

Individual LLM or model family

A specific provider model family, platform, or AI service grouping identified by HHS for separate evaluation and potential separate award, such as OpenAI or equal, Anthropic or equal, or another LLM/model family identified in the solicitation.

Frontier AI Capabilities Artificial intelligence models, features, tools, services, agents, APIs, and related capabilities that are among the most advanced, innovative, or operationally valuable capabilities available at a given point in time and that materially expand the operational value available to HHS users, missions, and operations, regardless of provider size, market position, or organizational maturity.

Advanced models The highest-capability generally available or approved-preview model tiers offered for the applicable individual LLM, including premium reasoning, long-context, fast-response, tool-enabled, or agentic-capable modes.

Advanced features End-user, administrative, tool, model, integration, or developer capabilities beyond baseline chat, including but not limited to files, projects/workspaces, connectors, memory, web use, code/data analysis, agent/delegation tools, API/gateway access, analytics, custom roles, and release-preview paths where offered.

Portable users Authorized HHS users whose access can be assigned, deassigned, or reassigned during the period of performance subject to the ordered usage envelope and vendor administration rules.

Inclusive access bundle An FFP pilot bundle that includes the offered model and feature access, setup, enablement, reporting, advisory, governance, release-alignment, and closeout work. The bundle is not unlimited in a mathematical sense; it is inclusive within the stated usage envelope and fair-use controls disclosed in the offer.

Direct relationship class The documented relationship between the offeror and the LLM provider/publisher for the proposed individual LLM, used for award-sequence eligibility.

Native consumption units Provider-defined units used to meter or allocate AI usage, including AMUs, credits, tokens, requests, messages, searches, tool calls, code-execution units, capacity units, or equivalent commercial constructs.

Standard/non-advanced AI native consumption unit pool

An optional, separately priced FFP entitlement for baseline or non-premium AI usage outside the advanced power-user pilot bundle. It is not the unit of purchase for the advanced pilot bundle and shall not be used to cap, diminish, suspend, or meter the advanced pilot bundle unless expressly stated and accepted by the Contracting Officer.

Commercial parity Access to the same or substantially equivalent model families, features, administrative controls, APIs, reporting, and release cadence that the provider makes available to similarly situated commercial enterprise customers, subject only to documented Government security, privacy, legal, authorization, or boundary constraints.

FedRAMP 20x-aligned pathway

A security and authorization support approach that uses FedRAMP 20x concepts where applicable, including Key Security Indicators, machine-readable or automation-supporting evidence, persistent validation, continuous monitoring, significant-change logic, and agency ATO support artifacts.

5. Period of Performance

Period Duration Principal objective

Base Period 6 months from date of award or other date stated in the order

Initial access, onboarding, baseline usage, reporting, integration/security/governance formulation, release-alignment roadmap, and closeout report.

Option Period 1 3 months Continuation of access, additional release testing, refinement of usage baselines, customization/security pathway maturation, and interim enterprise formulation.

Option Period 2 3 months Continuation of access, final release-path validation, final enterprise operating-model recommendations, and transition into BPA/ELA planning.

Total if all options exercised

12 months No option is exercised unless the Contracting Officer provides written notice in accordance with the order.

6. Draft Contract Line Item Concept The following draft structure is intended to preserve the core firm-fixed-price advanced pilot while allowing HHS to separately exercise a standard/non-advanced native consumption unit pool and user-quantity expansion options if needed.

Draft CLIN Description Pricing treatment

0001 Base FFP Inclusive Advanced Power User Pilot Bundle for the applicable individual LLM. Includes advanced model and feature access for up to [1,000] authorized portable users, onboarding, enablement, reporting, integration analysis, security and authorization pathway support, AI governance support, release-alignment planning, and closeout recommendations.

FFP, 6-month base

0002 Option - Standard/Non-Advanced AI Native Consumption Unit Pool. Provides a fixed pool or entitlement of baseline/non-premium AI consumption capacity outside CLIN 0001, which may include AMUs, credits, tokens, messages, standard-model requests, API units, or equivalent provider-native units.

Separately priced FFP option

0003 Option - Quantity Expansion. If included and exercised, increases the authorized portable-user quantity from the base cohort up to a maximum of 10,000 authorized portable users for the applicable individual LLM.

Separately priced FFP option or option band

1001 Option Period 1 continuation of CLIN 0001 for the ordered user quantity and approved pilot scope.

FFP, 3-month option

1002 Option Period 1 continuation or refresh of CLIN 0002, if exercised. Separately priced FFP option

2001 Option Period 2 continuation of CLIN 0001 for the ordered user quantity and approved pilot scope.

FFP, 3-month option

2002 Option Period 2 continuation or refresh of CLIN 0002, if exercised. Separately priced FFP option

Clean package position: CLIN 0001 buys the all-you-can-eat-style advanced pilot outcome. CLIN 0002, if exercised, buys an optional fixed-price non-advanced native consumption pool for baseline usage, reporting, and future enterprise pricing analysis. AMUs, credits, tokens, and equivalent native units are relevant to disclosure and reconciliation, but they do not cap or define the CLIN 0001 advanced pilot bundle.

7. Objectives

Objective 1 – Maintain and/or Exceed Commercial Parity as the Foundation for Routine Frontier AI Operations

HHS's desired end state is to establish a sustainable enterprise operating model that maintains or exceeds commercial parity at enterprise scale.

The objective is to make frontier AI capabilities a routine operational asset for HHS users, missions, and operations by continually evaluating, operationalizing, governing, securing, authorizing, and scaling advanced models, advanced features, agentic capabilities, coding capabilities, research capabilities, scientific capabilities, APIs, administrative capabilities, and other newly released commercial AI capabilities as close as practicable to their commercial availability and, where available through public-sector, research, healthcare, cybersecurity, national security, or strategic-partner programs, prior to broad commercial release.

HHS seeks to embed repeatable processes through which newly released capabilities can be assessed, authorized, governed, and made available to HHS users so that frontier AI capabilities remain continuously available sources of operational value for HHS missions and operations while preserving security, privacy, legal, records, accessibility, compliance, and mission requirements.

Where commercial parity or earlier availability cannot be achieved, the contractor shall identify the specific dependency, limitation, authorization requirement, security requirement, compliance requirement, technical constraint, or other factor preventing such availability, together with recommended remediation pathways, timelines, and enterprise implementation approaches.

The contractor shall provide an inclusive, firm-fixed-price pilot bundle for the applicable individual LLM that enables up to [X] authorized portable HHS power users to access, test, and use the provider's advanced AI models, modes, tools, administrative controls, reporting functions, and integration paths within the stated usage envelope.

The objective is to give HHS power users practical access to capabilities beyond baseline chat, including advanced reasoning, long-context analysis, document and file workflows, coding assistance, data analysis, structured outputs, agentic or delegated-work features, connectors, projects or workspaces, web-grounded research where authorized, API/gateway access, usage analytics, and administrator-controlled feature enablement.

The contractor shall identify which advanced models and features are included natively in the proposed pilot bundle, which are available only through a different product surface or cloud boundary, which are available only through API or gateway access, which are preview/limited availability, and which require configuration, customization, or future release before HHS enterprise use.

Objective 2 - Measure, Validate and Sustain Commercial Parity The contractor shall establish and maintain a Commercial Parity Matrix that enables HHS to continuously identify, assess, track, and prioritize gaps between commercially available capabilities and those available to HHS users.

For each individual LLM, the contractor shall provide and maintain a Commercial Parity Matrix that compares the Government pilot offering against the provider's commercial offering. At minimum, the matrix shall identify:

Area Required comparison

Model families and versions Commercial availability vs. Government availability

Advanced reasoning / premium model access

Included, limited, preview, excluded, or roadmap

End-user advanced features Chat, files, projects/workspaces, connectors, web, data/code tools, agents, memory/personalization

API and gateway access Commercial endpoint vs. Government endpoint or approved boundary

Administrative controls SSO, SCIM, RBAC, groups, policies, feature controls

HIPAA / BAA availability Commercial vs. Government availability

PHI processing eligibility Available, restricted, boundary dependent, roadmap, unavailable

Data classifications supported Public, Internal, PII, PHI, CUI

Reporting and telemetry Commercial dashboards vs. Government reporting/export capability

Release cadence Same-day, delayed, preview-only, boundary-dependent, or unavailable

Security or authorization blocker FedRAMP, ATO, cloud boundary, BAA, logging, identity, data-flow, or other dependency

Target availability date Immediate, 30 days, 60 days, 90 days, option period, or future roadmap

The contractor shall provide a release-alignment process for new models and features, including advance notice, release notes, security-impact assessment, authorization-impact assessment, data-flow changes, rollback approach, known limitations, and an estimated Government availability date.

Objective 3 - Establish a FedRAMP 20x-aligned rapid authorization and security pathway The contractor shall support HHS in establishing a rapid security and authorization pathway for advanced AI models and features, including a FedRAMP 20x-aligned evidence model where applicable.

Context for this goal. OMB M-24-15 states that FedRAMP should not incentivize or require commercial cloud providers to create separate, dedicated offerings for Federal use, and explains that the Federal Government benefits from the investment, security maintenance, and rapid feature development that commercial cloud providers give to their core products. OMB M-24-15 also instructs FedRAMP continuous monitoring to avoid promoting a division between commercially focused and Government-focused instances, and generally encourages agencies to use the same infrastructure relied on by a CSP's commercial customer base to support both security and agility. OMB M-24-15 further directs GSA to produce a plan to structure FedRAMP to encourage transition of Federal agencies away from Government-specific cloud infrastructure, where appropriate.

Accordingly, the objective is not to force unnecessary Federal-only product forks. The objective is to make commercially current AI models and features usable by HHS as close to commercial release as practical, while preserving HHS security, privacy, authorization, logging, governance, records, and operational requirements.

For each proposed product surface, model endpoint, API, end-user application, agentic feature, code/data tool, connector, administrative console, and reporting surface, the contractor shall identify:

Required item Objective

FedRAMP status Current FedRAMP authorization, FedRAMP 20x participation/status, FedRAMP Rev. 5 status, agency ATO path, or other authorization posture

Government boundary Whether the capability operates in a FedRAMP-authorized, Government, GovCloud, Assured Workloads, or commercial boundary

FedRAMP 20x path Whether the product can support FedRAMP 20x authorization/certification materials or 20x-style evidence

KSI mapping Mapping to applicable Key Security Indicators or successor FedRAMP 20x requirements

Machine-readable evidence Evidence available in machine-readable and human-readable form

Persistent validation How security posture is continuously or persistently validated

Continuous monitoring How logs, vulnerabilities, changes, incidents, and configuration posture are reported

Significant change process How new models/features/releases are assessed before Government enablement

Agency ATO support Evidence, artifacts, and SMEs needed for HHS ATO or risk acceptance

Gaps and timing Any delta between commercial release and Government-authorized availability

This objective should not be read as requiring every proposed feature to already hold FedRAMP 20x authorization.

The contractor must support a FedRAMP 20x-aligned pathway, disclose what is already authorized, disclose what is not yet authorized, and provide the evidence, roadmap, and validation logic needed for HHS to decide whether and when each capability can be enabled.

Objective 4 - Preserve Government security boundary and data-handling requirements The contractor shall ensure that all proposed models, features, tools, APIs, integrations, logs, administrative consoles, and analytics surfaces are mapped to a clear security and data-handling boundary before use by HHS pilot users.

Area Required objective

Data flow Where prompts, files, outputs, metadata, logs, and telemetry flow

Processing boundary Whether processing occurs in commercial, Government, GovCloud, FedRAMP, cloud-provider, or contractor-operated environments

Data retention Default retention, configurable retention, deletion, and zero-retention options where available

Training policy Whether HHS data is excluded from model training or improvement by default

Human access Whether provider personnel can access HHS data and under what conditions

HIPAA/BAA Whether BAA support is available and which surfaces are HIPAA-eligible

PII/PHI/CUI Whether the capability may process public, internal, PII, PHI, CUI, or other HHS-defined data classes

Logging Logs available to HHS and retention/export options

Incident reporting Security incident and breach notification processes

Subprocessors Subprocessor disclosure and change-notification process

The contractor shall identify whether data remains inside a cloud-provider boundary, is processed by the model provider, is processed by a reseller or integration partner, or flows through additional subprocessors. The contractor shall also identify whether the proposed pattern introduces a new HHS authorization boundary or can operate within an existing authorized boundary.

HHS includes Operating Divisions and Staff Divisions that may process Protected Health Information (PHI), Personally Identifiable Health Information (PII), Controlled Unclassified Information (CUI), research data, grants information, financial information, workforce information, and other sensitive information categories.

The contractor shall identify the data categories that may be processed by each model, feature, tool, deployment channel, API, administrative surface, and integration pattern. Specifically, the contractor shall identify:

- HIPAA eligibility status

- BAA availability

- PHI processing restrictions

- Data residency restrictions

- Retention requirements

- Logging requirements

- Model training implications

- Authorization boundary requirements

- FedRAMP 20x implications

- Cloud-provider dependencies

- And any additional controls required before HHS enterprise use

Objective 5 - Enable enterprise identity, portable user management, and administrative control The contractor shall support HHS enterprise identity, access management, and portable-user administration for the pilot cohort.

The objective is to enable HHS to assign, deassign, and reassign portable power-user access during the period of performance, while maintaining centralized control over users, groups, permissions, features, and reporting.

Capability SOO objective

Enterprise SSO Microsoft Entra ID or equivalent integration

Authentication OAuth2/OIDC where applicable; SAML where appropriate for end-user SaaS surfaces

Provisioning SCIM or equivalent automated onboarding/offboarding

JIT access Just-in-time provisioning or equivalent portable-user model

RBAC Role-based access control for administrators and users

Group controls Ability to enable/disable features by group, office, OpDiv, or pilot cohort

Delegated administration Direct support or a workable enterprise pattern for delegated administration

Access auditability Exportable user and administrative activity records

Objective 6 - Support HHS interoperability, API integration The contractor shall support HHS's objective of routing approved programmatic use cases through an HHS-controlled AI gateway, policy gateway, API management layer, or cloud-native equivalent.

Capability SOO objective

Potential gateway invocation Standard API or cloud-provider managed endpoint usable, supporting interoperability of independent HHS tools such as a potential HHS-controlled gateway for telemetry and throttling.

Request tagging Tags/labels for OpDiv, office, application, project, user, cost center, or other HHS attribution

Policy enforcement DLP, PII/PHI handling, prompt policy, allowed tools, rate limits, and access controls

Logging Request, model, token/native meter, response, tool-use, error, and latency metadata where available

Multi-model routing Ability to support routing among models or model tiers where applicable

Fallback and retry Compatibility with retry, failover, throttling, and continuity patterns

No proprietary lock-in No requirement that HHS use only a proprietary SDK or proprietary-only control plane when standard gateway/API methods are available; maintaining full interoperability with actively minimized operational dependencies for transfer/transition readiness

Objective 7 - Baseline power-user usage, adoption, cost drivers, and operational patterns The contractor shall provide usage, adoption, and telemetry reporting sufficient for HHS to baseline how power users actually use advanced models and features.

The objective is not merely to count seats. The objective is to allow HHS to understand which advanced capabilities are used, by whom, for what types of work, how often, through which surface, at what consumption level, with what support burden, and with what implication for future BPA and ELA pricing structures.

Reporting element Objective

User adoption Provisioned users, active users, inactive users, portable-user changes

Organizational attribution Department, OpDiv, office, group, application, project, or cost center

Model usage Model family, model tier, version/snapshot where available

Feature usage Advanced feature category, tool usage, agent usage, coding/data tools, connectors

Native meters Tokens, requests, credits, AMUs, searches, container-hours, seats, capacity, or other native units

Cost drivers Consumption, usage envelope utilization, rate-limit events, premium model usage

API/gateway usage API requests, gateway-tagged usage, error/throttle events

Audit exports User/admin activity, logs, SIEM-ready exports where available

Retention Minimum agency-compliant audit retention or HHS-controlled export that allows retention

Native consumption units are contractor pricing inputs, operational controls, and reporting elements only unless expressly incorporated as a separately priced option. For CLIN 0001, AMUs, credits, tokens, messages, searches, API calls, and equivalent native units shall not be separately invoiced and shall not be used as undisclosed caps on advanced pilot access.

Objective 8 - Sort features and models by customization level, integration effort, and enterprise feasibility The contractor shall produce and maintain a Feature, Customization, and Security Matrix that enables HHS to determine which capabilities are ready for enterprise use and which require additional work.

Classification Meaning

Native-ready Available as-is in the proposed Government pilot boundary

Configurable Available with administrative configuration or policy setup

Gateway-interoperable Available through API or gateway with HHS controls

Boundary-dependent Available only in a different FedRAMP/cloud/commercial boundary

Preview/limited Available only as preview, beta, limited release, or controlled access

Customization required Requires engineering, integration, policy, security, or workflow customization

Not feasible Not available or not recommended for HHS enterprise use

The contractor shall also estimate the customization level, expected timing, dependencies, security pathway, data types allowed, operating model, and whether the feature is suitable for enterprise scaling.

This objective directly supports HHS's purpose: baselining power-user usage, determining enterprise-feasible operational methodology, identifying which models and features need configuration or customization, establishing security logic, and formulating a common HHS enterprise operating model.

Objective 9 - Collaborate on statutory AI governance, use-case inventory, and policy reporting support The contractor shall collaborate with HHS CAIO, OCIO, cybersecurity, privacy, legal, records, acquisition, Section 508, Operating Division, and program stakeholders to produce evidence and artifacts that support statutory AI governance and HHS use-case inventory needs.

The contractor shall support HHS, without making final Government determinations, by providing:

Governance support area SOO objective

Use-case inventory inputs Model/feature/workflow descriptions, intended users, data types, risk indicators

High-impact AI triage Information needed for HHS to assess whether a use case may be rights-impacting, safety-impacting, or otherwise high-impact

Compliance planning Evidence for security, privacy, records, accessibility, and AI governance review

Issue reporting Process for logging harmful outputs, bias concerns, safety issues, security incidents, and feature defects

Human oversight Description of human-in-the-loop controls and escalation paths

Records support Data/export formats that support HHS records and retention determinations

Accessibility VPAT/ACR or equivalent accessibility evidence for user-facing and admin surfaces

Governance operating model Recommendations for controls, roles, release gates, and enterprise policy

HHS retains final responsibility for legal interpretation, AI use-case inventory classification, high-impact AI determinations, risk acceptance, system authorization, privacy, records, accessibility, acquisition, and deployment decisions.

Objective 10 - Support enterprise release alignment and rapid implementation planning The contractor shall provide a Release Alignment and Rapid Implementation Roadmap that enables HHS to understand how newly released commercial models and features can be evaluated, secured, authorized, enabled, monitored, and governed for Government use with minimal lag.

Roadmap element Objective

Commercial release monitoring How HHS will be notified of new releases

Government availability assessment Whether the release is available in the HHS-approved boundary

Security-impact analysis Boundary, data-flow, logging, retention, identity, and subprocessor changes

FedRAMP/ATO impact Whether new evidence, significant-change notice, or AO review is needed

Pilot enablement path Whether feature can be enabled for all users, test group, admin-only, or API-only

Rollback plan How HHS can disable or revert a release

Documentation Release notes, model cards/system cards, policy changes, admin guides

Timeline Immediate, 30 days, 60 days, 90 days, option period, or future release

This objective is a standing roadmap requirement across the base and option periods, not merely a final report, because commercial AI releases will continue during the pilot.

Objective 11 - Produce final enterprise operating model and acquisition recommendations The contractor shall provide a final enterprise feasibility and acquisition recommendations report that helps HHS formulate its anticipated AI multiple-award BPA and ELA task orders.

Recommendation area Objective

Enterprise operating model How HHS should govern power-user, workforce, API, agent, and automated use

Feature segmentation Which features should be broadly available, restricted, gatewayed, customized, or deferred

Security model Recommended FedRAMP 20x/ATO continuous monitoring/release-control approach

Commercial model Recommended pricing units, FFP bundles, consumption units, capacity tiers, options, and surge structures

Reporting terms Standard reporting fields, cadence, retention, dashboard/export requirements

Source selection Future salient characteristics, technical acceptability criteria, and evaluation risks

BPA/ELA terms Contract terms for commercial parity, release alignment, data handling, telemetry, gateway access, and statutory AI governance

Transition Whether and how advance features are assessed, metric based, for broader enterprise use suitability and focus on full interoperability with actively minimized operational dependencies for transfer/transition readiness

For each newly released model or feature, the contractor shall identify:

- FedRAMP impact

- HIPAA impact

- BAA impact

- Privacy Impact

- Authorization impact

- HHS governance impact

Objective 12 - Preserve optional scalability up to 10,000 authorized portable users The base pilot shall support up to [1,000] authorized portable HHS power users per resultant award, unless another base quantity is stated in the order. The Government may exercise one or more priced unit quantity (FFP advanced features up to 1,000 portable-users) options to increase the total authorized portable-user quantity by FFP unit up to 10,000 authorized portable users for the applicable individual LLM.

Quantity expansion may be exercised during the base period or during either option period, at the Contracting Officer's discretion, to support broader baselining, release testing, enterprise feasibility assessment, statutory AI governance support, commercial-parity evaluation, FedRAMP 20x-aligned security analysis, and transition planning for HHS's anticipated AI BPA and ELA task orders.

Any quantity expansion shall preserve the same core pilot objectives: inclusive access to advanced models and features within the ordered usage envelope, usage and adoption reporting, integration-readiness analysis, customization and security mapping, release-alignment planning, AI use-case inventory support, and final enterprise operating-model recommendations.

The contractor shall not reduce commercial parity, feature availability, reporting, support, security evidence, or administrative controls for users added under a quantity option unless the limitation is disclosed in the offer and accepted by the Government.

Objective 13 - Preserve optional baseline consumption capacity for non-advanced AI use The contractor shall provide, if ordered, an optional standard/non-advanced AI native consumption pool for baseline AI usage outside the advanced power-user pilot bundle. The optional pool shall support HHS evaluation of standard chat, light drafting, standard summarization, routine question answering, standard API requests, or other non-premium usage patterns that do not require advanced reasoning, agentic features, premium model tiers, code execution, deep research, high-context workflows, or other advanced capabilities.

The contractor shall disclose the provider-native unit structure applicable to the optional pool, including AMUs, credits, tokens, requests, messages, seats, API units, or equivalent meters. The contractor shall identify what consumes the pool, what does not consume the pool, whether units expire or roll over during the ordered period, whether units are portable across users or organizational components, and what exportable reporting is available for HHS reconciliation.

The optional pool is intended to help HHS distinguish baseline workforce usage from advanced power-user usage and to inform future BPA/ELA pricing models. It is not the primary unit of purchase for the advanced power-user pilot.

The optional line item is intended for baseline, non-premium, non-advanced AI usage outside the CLIN 0001 advanced power-user pilot bundle. It shall not be used to limit, offset, diminish, suspend, or meter the inclusive advanced model and feature access required under CLIN 0001 unless expressly stated in the order and accepted by the Contracting Officer.

The contractor shall not invoice the Government for overages, replenishment, AMU exhaustion, credit exhaustion, token usage, API calls, or other native consumption units beyond the fixed price of this option unless authorized by written modification or separately exercised option.

8. Draft Deliverables

ID Deliverable Due date / cadence Period

D1 Kickoff and Pilot Management Plan Within 10 business days after award

Base

D2 Feature and Model Availability Matrix Within 15 business days;

monthly refresh

Base and options

D3 Commercial Parity Matrix Within 20 business days; refresh when major releases occur

Base and options

D4 FedRAMP 20x / Security and Authorization Pathway Matrix

Initial by day 45; monthly refresh or as major releases occur

Base and options

D5 Usage Baseline and Reporting Data Dictionary Within 20 business days;

monthly reporting

Base and options

D6 Integration, Customization, and Security Matrix Initial by day 45; monthly refresh

Base and options

D7 AI Governance and Use-Case Inventory Collaboration Crosswalk

Initial by day 45; update before closeout

Base and options

D8 Release Alignment and Rapid Implementation Roadmap

Initial by day 60; refresh when major releases occur

Base and options

D9 Training, Office Hours, and Power User Enablement Materials

As scheduled in management plan

Base and options

D10 Monthly Usage, Adoption, and Issue Report Monthly Base and options

D11 Base Period Closeout and Option Exercise Recommendation

No later than 15 days before base expiration

Base

D12 Final Enterprise Feasibility and Acquisition Recommendations Report

No later than 10 business days before final expiration

Final option or base if no option

Reference Relevance

OMB M-24-15, Modernizing the Federal Risk and Authorization Management Program (FedRAMP)

Policy context for avoiding unnecessary Federal-only cloud forks, enabling commercial parity where appropriate, modernizing continuous monitoring, and moving toward automation and machine-readable authorization artifacts.

FedRAMP 20x Phase 2 documentation Context for rapid authorization concepts, Key Security Indicators, provider/assessor responsibilities, and 20x authorization support.

FedRAMP 20x Key Security Indicators documentation

Context for KSI implementation summaries, pass/fail criteria, traceability, validation processes, significant change, and implementation status.

FedRAMP Persistent Validation and Assessment documentation

Context for persistent validation, machine-based validation, non-machine validation, assessor validation of processes, and continuous security evidence.

HHS AI market research questionnaire responses Market context for advanced AI capabilities, identity, audit, reporting, gateway, FedRAMP/cloud boundary, commercial-parity, pricing, and native-meter issues.

Public URLs for FedRAMP references:

• M-24-15 Vision: https://www.fedramp.gov/docs/authority/m-24-15/vision/

• M-24-15 Continuous Monitoring: https://www.fedramp.gov/docs/authority/m-24-15/monitoring/

• M-24-15 Implementation: https://www.fedramp.gov/docs/authority/m-24-15/implementation/

• FedRAMP 20x Phase 2: https://www.fedramp.gov/20x/phases/2/

• FedRAMP 20x Key Security Indicators: https://www.fedramp.gov/docs/20x/key-security-indicators/

• FedRAMP Persistent Validation and Assessment: https://www.fedramp.gov/docs/20x/persistent-validation-and-assessment/

End of draft SOO for public feedback.