Attachment 1 - Statement of Objectives.pdf

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

Statement of Objectives (SOO)

STATEMENT OF OBJECTIVES

HHS AI Power User Advanced Models and Features Pilot

June 26, 2026

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 primary purpose of the advanced power-user pilot is to establish operational baselines for emerging and frontier AI capabilities to enable HHS to accurately forecast enterprise demand, define enterprise operating models, establish governance requirements, determine enterprise scalability, or develop future pricing structures.

HHS also intends to mature enterprise AI governance, attribution, allocation, and consumption measurement capabilities throughout the pilot period, including support for capability-level attribution, program-level allocation, enterprise reporting, and AI Consumption Unit (ACU) normalization methodologies.

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 recognizes that certain AI capabilities are sufficiently mature within the Department to support consumption-based analysis, while other emerging and frontier capabilities require operational baselining before future enterprise pricing, licensing, and acquisition structures can be determined. Accordingly, this pilot distinguishes between frontier capability baselining and established capability consumption analysis.

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.

HHS recognizes that enterprise AI consumption measurement and allocation methodologies will continue to mature. The Government seeks to establish the operational data, telemetry, attribution, reporting, and governance foundations necessary to support future enterprise budgeting, allocation, chargeback, pricing, and acquisition decisions. The pilot is intended to support that maturation process without requiring HHS to prematurely adopt a final enterprise pricing model.

The pilot is intended to generate operational evidence that supports future enterprise acquisition decisions, including BPA structure, enterprise licensing strategies, consumption models, governance frameworks, release-alignment approaches, interoperability requirements, and commercial-parity objectives.

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.

HHS seeks to understand not only how AI capabilities are consumed, but also how frontier AI capabilities create mission value, alter workflows, affect governance requirements, and influence future enterprise operating models.

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 [1,000] 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/cybersecurity 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.

AI Consumption Unit (ACU) A normalized enterprise measurement unit used by HHS to support AI demand measurement, allocation, governance, reporting, budgeting, and future acquisition planning across multiple providers and platforms. ACUs are intended to support enterprise normalization and analytics and are not necessarily contractual billing units.

First-Party Provider Any entity that directly develops, operates, and/or controls the proposed AI capability, model, platform, or service.

Established AI Capability AI capabilities for which HHS possesses sufficient operational experience to reasonably forecast demand, estimate future consumption, understand governance requirements, and support future enterprise pricing analysis.

Emerging and Frontier AI Capability

AI capabilities for which HHS does not yet possess sufficient operational evidence to accurately forecast enterprise demand, estimate future pricing structures, define enterprise operating models, establish governance requirements, or determine enterprise scalability.

Strategic Alliance Any seller arrangement, marketplace relationship, preferred-provider agreement, cloud-provider dependency, exclusivity arrangement, revenue-sharing agreement, or other commercial relationship that materially affects the offeror’s ability to provide, support, operate, price maintain, transition or achieve commercial parity for the proposed capability.

Commercial Equivalent Reporting

Reporting that identifies provider-native utilization metrics and the equivalent market value that would have been incurred under the provider’s standard commercial pricing model.

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.

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 6 months Continuation of access, additional release testing, refinement of usage baselines, customization/security pathway maturation, and interim enterprise formulation.

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

Total if all options exercised

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

6. Contract Line Item The following draft CLIN structure is intended to support two complementary HHS objectives.

First, HHS seeks to establish operational baselines for emerging and frontier AI capabilities whose enterprise demand, governance requirements, operating models, scalability characteristics, and future pricing structures are not yet sufficiently understood. These capabilities are addressed through the advanced power-user pilot construct.

Second, HHS seeks to preserve workforce-scale access to enterprise AI capabilities while simultaneously maturing enterprise attribution, allocation, normalization, governance, budgeting, reporting, and future acquisition methodologies. These capabilities are addressed through the workforce access and enterprise maturity construct.

The CLIN structure is intentionally designed to:

• Preserve continuity of workforce AI operations where such capabilities are already deployed.

• Support onboarding and evaluation of workforce-scale AI capabilities where such capabilities are not yet deployed.

• Establish operational baselines for frontier AI capabilities.

• Generate commercial-equivalent utilization data.

• Support capability-level attribution and AI Consumption Unit (ACU) normalization.

• Enable future enterprise budgeting, allocation, governance, and acquisition decisions.

• Maintain predictable financial exposure during the pilot period.

• Avoid requiring HHS to prematurely commit to a future enterprise pricing model before sufficient operational evidence exists.

The Government's objective is not to predetermine whether future enterprise AI acquisition should be based on seats, entitlements, consumption, ACUs, hybrid structures, or other commercial approaches. Rather, the Government seeks to generate the operational evidence necessary to support those future decisions while preserving continuity of operations and access to frontier innovation.

Accordingly:

• CLIN 0001 focuses on frontier capability baselining and enterprise feasibility.

• CLIN 0002 focuses on enterprise-wide workforce access, continuity of established AI capabilities, usage transparency, commercial-equivalent reporting, attribution, ACU normalization, and enterprise maturity through a firm-fixed-price Enterprise-Wide Access Entitlement..

• CLIN 0003 focuses on workforce adoption learning and baselining.

• CLIN 0004 provides optional scalability to support broader enterprise evaluation and transition planning.

The Government intends to mature toward increasingly granular attribution, allocation, normalization, and enterprise consumption-management methodologies over time; however, the pilot is structured to collect the operational evidence necessary to support that maturity rather than assuming such maturity already exists.

CLIN Description Pricing treatment

0001 - Base FFP Exploratory Frontier AI Entitlement for up to [1,000] authorized portable HHS power users.

Includes access to advanced models, advanced features, agentic capabilities, APIs, administrative controls, reporting functions, integration paths, onboarding, enablement, and pilot support necessary to establish operational baselines for frontier AI capabilities.

Authorized power users will have access to freely explore and utilize advanced capabilities without requiring the Government to pre-allocate, meter, ration, or continuously manage provider-native consumption units at the individual-user level during the pilot period.

FFP Exploratory Frontier Entitlement

0002 - Base FFP Enterprise-Wide Access Entitlement - Provides a firm-fixed-price Enterprise-Wide Access Entitlement for the applicable Individual LLM or Model Family for authorized HHS workforce users during the ordered period.

The purpose of this CLIN is to preserve workforce-scale access to established enterprise AI capabilities while enabling HHS to mature enterprise governance, attribution, allocation, commercial-equivalent reporting, AI Consumption Unit normalization, budgeting, and future acquisition planning.

This CLIN is intended to provide enterprise-wide access to covered AI capabilities during the ordered period without pricing or ordering access on a per-seat basis and without consumption-based invoicing, overage charges, replenishment charges, provider-native unit exhaustion charges, or additional usage-based charges.

The Contractor shall identify all capabilities included within the Enterprise- Wide Access Entitlement and shall identify any capabilities excluded from the entitlement or available only under another CLIN.

Covered capabilities may include, as applicable:

• General chat.

• Mature reasoning capabilities.

• Drafting and summarization.

• Search or research capabilities.

• File and document workflows.

• Data analysis capabilities.

• Tool-enabled workflows.

• Native applications.

• Administrative controls.

• Reporting and analytics.

• Other covered workforce AI capabilities identified in the Contractor’s proposal and accepted by the Government.

The Contractor shall provide commercial-equivalent utilization reporting and provider-native usage reporting sufficient to support:

• Enterprise utilization analysis.

• Workforce access continuity.

• Capability-level attribution.

• Federal employee and contractor attribution where available.

• Organizational and program attribution.

• Cost-driver analysis.

• ACU normalization.

FFP Enterprise-wide Access Entitlement

*existing one gov deals and performance periods must be explicit*

• Future budgeting.

• Future chargeback analysis.

• Future enterprise acquisition planning.

The Government may provide historical usage data as a solicitation attachment to support Quoter pricing. Such data is provided for quotation development, transparency, and market-research support only. The data does not constitute a guaranteed minimum, maximum, ceiling, forecast, commitment, or warranty of future utilization.

Quoters are responsible for developing and supporting their proposed firm-fixed-price entitlement price based on their own commercial judgment, Government-furnished usage data, Quoter-held HHS usage data where available, relevant enterprise usage data, commercial pricing practices, risk adjustments, and proposed discounts.

Quoters shall identify any existing HHS enterprise agreements, OneGov arrangements, pilots, tenant deployments, ordering vehicles, or other HHS arrangements included in the pricing or historical usage analysis, including applicable performance periods.

0003 - Base *ONLY IF APPLICABLE* (OPTIONAL) - Enterprise Workforce Adoption and Operating Model Baselining

Provides workforce-scale access to enterprise AI capabilities f to forecast enterprise demand, establish enterprise consumption baselines, determine enterprise operating models, or formulate future pricing and acquisition strategies.

The purpose of this CLIN is to establish workforce adoption baselines, governance baselines, operating-model baselines, and enterprise feasibility evidence for AI capabilities that are not currently deployed at enterprise scale within HHS.

The contractor shall provide workforce-scale access, onboarding, reporting, governance support, commercial-equivalent reporting, enterprise adoption reporting, and operating-model recommendations sufficient to support future enterprise acquisition decisions.

The contractor shall provide reporting sufficient to identify:

• User activation

• User adoption

• Organizational adoption

• Capability adoption

• Enterprise utilization patterns

• Governance requirements

• Support requirements

• Operational constraints

• Enterprise feasibility considerations

This CLIN is intended to establish enterprise adoption baselines and is not intended to serve as the primary enterprise consumption-baselining vehicle for capabilities that already possess a substantial HHS workforce footprint.

Separately priced FFP Adoption Baselining Entitlement

*existing one gov deals and performance periods must be explicit*

0004 - Base *Optional* - Frontier Entitlement Unit 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 *Quoters may propose this as an FFP enterprise-wide access similar to

CLIN 0002*

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

FFP, 6-month option

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

1003 – OP1 Option Period 1 continuation or refresh of CLIN 0003, if exercised. Separately priced FFP Adoption Baselining Entitlement option

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

FFP, 6-month

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

2003 – OP2 Option Period 2 continuation or refresh of CLIN 0003, if exercised. Separately priced FFP Adoption Baselining Entitlement

Provider-native usage metrics shall be reported and analyzed for all applicable capabilities, including capabilities provided under CLIN 0001 and CLIN 0002. Provider-native usage metrics include tokens, credits, AMUs, requests, messages, searches, tool invocations, agent executions, API calls, capacity units, or equivalent provider-defined metrics.

Provider-native usage metrics are reporting elements, analytical inputs, commercial-equivalent pricing inputs, attribution inputs, and ACU normalization inputs. They shall not serve as undisclosed billing triggers, hidden caps, suspension triggers, throttling mechanisms, provider-native unit exhaustion triggers, or additional payment mechanisms unless expressly incorporated into the awarded contract, order, or written modification signed by the Contracting Officer.

Quoters shall disclose all applicable usage assumptions, fair-use controls, safety controls, abuse-prevention controls, technical limitations, rate limits, throttling conditions, capacity limitations, excluded capabilities, and other commercial constraints applicable to the proposed offering. The Government will consider only those limitations disclosed in the quotation and accepted by the Government at award

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.

HHS seeks to baseline frontier capability adoption independently from mature workforce consumption patterns to ensure future acquisition decisions are informed by actual operational demand rather than artificially constrained consumption behavior.

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 [1,000] 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.

Frontier Baselining with Exploratory Frontier AI Entitlement per each 1,000 authorized power user group

The contractor shall provide an inclusive, firm-fixed-price exploratory frontier entitlement for up to [1,000] authorized portable HHS power users for the applicable individual LLM.

The entitlement shall enable authorized users to access, evaluate, test, compare, stress, and operationally baseline the provider's advanced AI models, advanced features, agentic capabilities, APIs, administrative controls, reporting functions, developer tools, integration paths, and newly released frontier capabilities within the disclosed usage envelope and commercial fair-use parameters identified in the contractor's proposal.

The Government's objective is to establish operational baselines for frontier AI capabilities by allowing authorized power users to freely explore and utilize advanced capabilities without requiring the Government to pre-allocate, meter, ration, or continuously manage provider-native consumption units at the individual-user level during the pilot period.

The contractor shall provide commercial-equivalent reporting and provider-native consumption reporting sufficient to support enterprise baselining, cost-driver analysis, attribution, AI Consumption Unit (ACU) normalization, budgeting analysis, and future acquisition planning. Such reporting shall not be used as an undisclosed limitation, throttling mechanism, or primary unit of acquisition for this CLIN.

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 and gateway access, usage analytics, administrative controls, and newly released frontier capabilities as they become available.

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 Commercial Independence Degree of direct provider control over commercial parity HIPAA / BAA availability Commercial vs. Government availability PHI processing eligibility Available, restricted, boundary dependent, roadmap, unavailable Provider Control First-party, reseller, hyperscaler, marketplace, or intermediary delivery model 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 Strategic Dependencies Dependencies affecting release cadence, feature availability, pricing, or support 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.

The contractor shall identify whether capabilities are delivered directly by the model provider, through a hyperscaler, through a reseller, through a marketplace, or through other intermediary arrangements and shall identify all material processing and operational dependencies.

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, unassign, 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 identify any proprietary SDK, proprietary control-plane, proprietary gateway, marketplace dependency, or exclusivity condition that may materially affect portability, interoperability, transition readiness, or multi-provider operation.

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

Enterprise-Wide Access Entitlement Baselining The objective is to preserve workforce-scale access to covered enterprise AI capabilities while enabling HHS to measure utilization, adoption, cost drivers, capability-level usage, organizational demand, and future enterprise acquisition requirements under an FFP Enterprise-Wide Access Entitlement.

The Contractor shall provide provider-native usage reporting and commercial-equivalent reporting sufficient to support future enterprise pricing, budgeting, governance, allocation, and acquisition decisions.

The Contractor shall identify covered capabilities, excluded capabilities, usage assumptions, fair-use controls, rate limits, throttling conditions, capacity limitations, safety controls, abuse-prevention controls, and any other commercial constraints applicable to the Enterprise-Wide Access Entitlement.

Provider-native usage metrics shall be reported for transparency, attribution, ACU normalization, commercial-equivalent analysis, and future acquisition planning. Provider-native usage metrics shall not be used as undisclosed billing triggers, hidden caps, suspension triggers, provider-native unit exhaustion triggers, or additional payment mechanisms under CLIN 0002.

Enterprise Workforce Adoption Baselining The objective is to:

• Measure adoption

• Measure activation

• Measure enterprise suitability

• Measure governance requirements

• Measure support requirements

• Measure operating-model feasibility

The purpose is to establish an enterprise baseline where no such baseline currently exists.

Pilot Support Activities The contractor may provide onboarding, training, workshops, office hours, enablement activities, use-case acceleration support, adoption support, administrative support, and related provider-delivered assistance when such activities are directly related to successful execution of the pilot and achievement of the applicable CLIN objectives.

Such activities may be utilized under CLIN 0001, CLIN 0002, or CLIN 0003, as applicable.

These activities are intended to support pilot execution, adoption, utilization, enterprise baselining, governance, commercial parity, enterprise feasibility analysis, and future acquisition planning.

The Government is not seeking standalone training services. Training and enablement activities shall be incidental to and supportive of the pilot objectives.

The contractor shall provide usage, adoption, and telemetry reporting sufficient for HHS to baseline how power users actually use advanced models and features. Reporting shall support attribution of usage by user, capability category, organizational component, program, and contractual construct where applicable.

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 Commercial Equivalent Utilization

Commercial-equivalent value of usage under the provider’s standard commercial pricing model

Meter-Based Response vs.

User-Based Response Monitoring

Distinguish provider-metered activity from user-resolved outcomes and identify patterns where repeated prompts, regenerations, retries, continuations, tool calls, searches, agent executions, or unresolved interaction cycles materially increase usage without corresponding user-resolved value

Capability Level Attribution Distinguish usage attribution.

ACU Normalization Reporting Support enterprise normalization and analytics to increase maturity state.

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.

Commercial Equivalent Reporting Requirement For any capability provided under a fixed-price pilot construct, the contractor shall provide monthly commercial-equivalent utilization reporting. Such reporting shall identify the provider-defined consumption metrics utilized during the reporting period and the corresponding commercial-equivalent value that would have been incurred under the contractor's standard commercial pricing model.

At minimum:

• Native provider consumption metrics

• Commercial-equivalent utilization

• Commercial-equivalent pricing

• ACU-equivalent values

• Utilization by capability category

• Utilization by organizational component

• Tokens

• Credits

• Requests

• Searches

• Agent executions

• Tool invocations

• API calls

• Capacity units

• Other provider-native metrics as applicable.

Meter-Based Response vs. User-Based Response Monitoring, User Engagement, and Consistency Analysis The Contractor shall support HHS in distinguishing provider-metered activity from user-resolved outcomes.

For purposes of this requirement, meter-based response activity means any response, regeneration, continuation, tool invocation, search, agent execution, API call, file or document operation, model call, message, request, token, credit, AMU, capacity unit, or other provider-native event that contributes to reported utilization, commercial-equivalent value, or cost-driver analysis.

For purposes of this requirement, user-based response outcome means a response or interaction sequence that the user indicates, or that available engagement signals reasonably suggest, resolved the user’s need, supported the user’s intended task, or produced a useful work product without requiring unnecessary corrective prompting, regeneration, repeated back-and-forth exchanges, or abandonment.

The Meter-Based Response vs. User-Based Response Monitoring requirement is to enable HHS to evaluate whether metered usage reasonably corresponds to user-resolved value and to identify patterns where repeated interaction cycles, low-utility responses, inconsistent outputs, avoidable regenerations, excessive re-prompting, or unresolved exchanges may materially increase usage without corresponding mission value.

The Contractor shall provide reporting, where technically available, sufficient to identify:

• Metered activity by model, feature, tool, API, agent, research, coding, file, search, or capability category.

• Number of user turns, model responses, regenerations, retries, continuations, tool calls, searches, agent executions, API calls, and other metered events associated with an interaction sequence.

• User feedback indicating whether a response was useful, not useful, incomplete, incorrect, outdated, non-responsive, repetitive, hallucinated, refused, overly constrained, required excessive re-prompting, or otherwise failed to resolve the user’s need.

• Re-prompt, regeneration, retry, continuation, abandonment, and repeated interaction-cycle patterns.

• Metered units per user-resolved outcome, where technically feasible.

• Metered units associated with user-reported low-utility or unresolved outcomes, where technically feasible.

• Capability categories, models, tools, workflows, or access surfaces associated with high repeated-cycle rates or high metered activity without corresponding user-resolved outcomes.

• Trends by organizational component, program, user population, Federal/contractor category where available, and capability category.

• Corrective actions, product escalations, user guidance, configuration changes, or roadmap considerations related to recurring response-resolution issues.

The Contractor shall support a user reporting mechanism, feedback mechanism, or equivalent workflow that enables HHS users to report response-resolution issues without requiring disclosure of sensitive prompt or output content unless such disclosure is authorized by HHS.

Reporting under this requirement shall be used to support enterprise baselining, usage transparency, commercial-equivalent analysis, ACU normalization, model and feature evaluation, quality management, user enablement, future acquisition planning, and enterprise governance. It shall not require the Contractor to disclose sensitive user content beyond the data handling, privacy, security, and records requirements established by the Government

Capability-Level Attribution Contractors shall provide reporting…