Amd1.Statement of Objectives PowerUser Adv AI Pilot.pdf

Statement of Objectives (SOO)

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

STATEMENT OF OBJECTIVES

HHS AI Power User Advanced Models and Features Pilot

July 9, 2026

This Statement of Objectives (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 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

Further detail on CLIN objectives:

CLIN 0001 - All advanced, emerging, and frontier capabilities are included in CLIN 0001 by default. This is an emerging and frontier capability pilot. The contractor shall provide its full commercial advanced capabilities set – all advanced models, advanced features, agentic capabilities, APIs, tools, integrations, administrative controls, reporting functions and newly released frontier capabilities available in the contractor’s commercial offering. The Government does not expect a curated or limited subset. Capabilities newly released commercially during the period of performance are likewise expected to become available to HHS pilot users consistent with SOO Objective 1 (commercial parity) and Objective 10 (release alignment).

Capability scope and price is independent of consumption volume. CLIN 0001 is a firm fixed price entitlement structured specifically to let authorized power users freely explore and utilize advanced capabilities so that HHS can baseline actual demand – not to meter, ration, or restrict access against a budget. Native consumption units (tokens, credits, AMUs, request, messages, searches, API calls, or equivalent) are reporting and baselining inputs only. They shall not be separately invoiced, shall not trigger overages charges to the Government, and shall not be used as an undisclosed cap on access. Accordingly, no capability may be withheld, throttled, or deprioritized on the basis of consumption volume or cost.

The contractor shall clearly identify in its proposal any advanced, emerging, or frontier capability that is excluded from the base offering, and the specific reason for exclusion (e.g. security boundary incompatibility, authorization dependency, or not available in the contractor’s current commercial offering). This information shall be reflected in the Feature and Model Availability Matrix (Deliverable D2), due within 15 business days of award and refreshed monthly.

HHS prioritization requests during the performance period. Because all available and emerging capabilities are already within scope, HHS requests during the performance period address prioritization, acceleration of enablement, or clarification of deployment status – not the addition of anything new. Such requests reflect operating division-specific focus areas (e.g. legal, domain-specialized, or mission-critical capabilities) or acceleration of capabilities initially staged as preview or limited release. HHS shall communicate such requests in writing to the COR. Within 5 business days, the contractor shall confirm current deployment status and either provide an enablement timeline or identify the specific technical constraint (security boundary or authorization pathway) preventing acceleration.

No additional cost, ever. All feasible prioritization and acceleration requests shall be accommodated at no additional cost under CLIN 0001, consistent with its FFP structure and the purpose of this pilot. Resource availability and consumption volume are not a basis for declining a request. Where a request cannot be accommodated, the sole permissible grounds are genuine technical constraints, which the contractor shall clearly explain, together with a proposed workaround or alternative timeline within the existing contract scope.

No reduction in committed service level. Prioritizing any capability shall not reduce commercial parity, reporting cadence, support responsiveness, or access to any other committed capability.

Illustration. If a legal research capability is available in the contractor’s commercial offering but stated for preview release in Month 6, and HHS requests it in Month 3, the contractor accelerates enablement and deploys it to HHS pilot users at no additional cost, regardless of resulting consumption. If acceleration is prevented by a genuine technical constraint, for example an outstanding authorization dependency, the contractor sates the constraint plainly and proposes the earliest feasible alternative timeline within scope.

CLIN 0002 - Enterprise-wide access entitlement:

• No overage costs either: “without consumption-based invoicing, overage charges, replenishment charges, provider-native unit exhaustion charges, or additional usage-based charges.” Same no-cost principle as CLIN 0001.

• But Scope is different. This is “established” capabilities, not “all commercial capabilities” by default. Covered capabilities are “identified in the contractor’s proposal and accepted by the Government”. The contractor proposes what’s covered; Government accepts or negotiates. Exclusions must be identified too.

• So: No cost applies, but “everything is in scope by default” does not, CLIN 0002 is the non-advanced, contractor proposed/Government accepted scope not a blanket inclusion like CLIN 0001.

CLIN 0003 – Enterprise Workforce Adoption and Operating Model Baselining (Optional)

• Separately priced FFP entitlement for AI that does not yet have an enterprise footprint at HHS, requiring onramp etc.

• Explicitly for providers that have not yet deployed an enterprise scale offering at HHS.

• Structurally distinct purpose, it is set up / onramp / security foundations with adoption. An LLM using CLIN 0003 would not be proposing CLIN 0002.

CLIN 0004 – Frontier Entitlement Unit Quantity Expansion

• This is literally CLIN 0001, scaled to more users. Not a different capability set, it is a user count option.

• Objective 12 governs this directly: “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.

• So CLIN 0004 inherits the CLIN 0001 logic, same capabilities, same no-cost principle, just more users (up to 10,000 incremental users suggested but Quoters may propose an enterprise wide entitlement offer similar to CLIN 0002. Enterprise wide entitlement offerings priced favorably for Government adoption are encouraged.)

Note on Favorably Priced Entitlement FFP Offerings:

1. Mutual Immaturity Rational – The FFP, no-coverage structure across these CLINS is not a stylistic preference. It reflects that both Government attribution maturity and provider metering/reporting maturity are currently insufficient to support a metered structure. A Quoter proposing metered or consumption-based pricing under these conditions would be knowingly exploiting that asymmetry.

2. Internal Data Findings – The Government had to cross-walk existing enterprise scale AI usage data with internal HHS sources to even get minimal attribution insight, and found that usage does not reconcile across tools, For example, AI-assisted activity occurred on repositories with no corresponding review trail, and gaps existed in the Government’s ability to attribute and gain transparency into AI-assisted work product across organizational, ownership, and lifecycle dimensions. None of this is explainable from the existing enterprise scale AI footprint reporting as it stands, and accordingly ties directly back to SOO Objectives 7 and 13 for Federal Workforce Attribution and other key SOO objective requirements.

3. Pricing Expectation – Quoters with an existing HHS enterprise scale footprint are expected to price similarly to OneGov terms, not at a premium or on actuals. An existing footprint is not a basis for higher pricing and is the contrary, it is the basis for the Government’s most favorable available pricing, given he Quoter’s already-amortized deployment costs and significant immaturity.

4. CLIN Boundary Clarity – Quoters shall explicitly classify coding, repo-task, agentic, and tool-execution workloads must be explicitly classified by CLIN (0001, 0002, both or neither) in the proposal and locked at award. Unclassified usage defaults to CLIN 0002 at no additional cost. This prevents a Quoter from pricing “unlimited enterprise” access assuming such workloads are excluded, or from including them to win on price and later reclassifying them as “frontier” once deployed at volume.

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…