TLDR
Executive briefTwo identical models can be two different purchases
- The procurement unit is a bounded operating capability: outcome, process, data, model, integration, assurance, operations and commercial exit.
- Name whether the deal is a managed outcome, integrated capability, replaceable component or paid proof before comparing suppliers or prices.
- Allocate supplies, configures, decides, operates, evidences and remedies duties to named parties; shared responsibility is never the final owner.
- Accept through buyer-relevant end-state and control evidence under realistic conditions, not through benchmarks, demos or supplier self-description.
- Price the whole operating path and preserve revalidation, portability, transition and deletion rights before production dependency forms.
Two suppliers quote the same foundation-model endpoint. Supplier A includes workflow discovery, retrieval integration, case-specific evaluation, identity controls, trained reviewers, monitoring, incident support and a managed transition. Supplier B quotes the endpoint and a small implementation package. Its price is one quarter of Supplier A's. On a model comparison, B looks efficient. On an operating-capability comparison, the buyer must fund, integrate and own every omitted layer. The offers do not supply the same thing.
This category error is easy to make because the model is visible, measurable and commercially named. The business need is less tidy. It may be faster complaint resolution, safer maintenance scheduling, better fraud triage or more reliable document review. That result depends on the population, baseline, process, data, tool authority, people, controls, evidence, service capacity and route by which benefit is captured. A good model can enter a weak process and produce no value. A modest model can improve a well-designed process because the operating conditions make its contribution usable.
Procurement therefore needs a more precise object. The Outcome Procurement Stack defines eight layers of a bounded operating capability. The Procurement Boundary Decision says which of those layers the supplier is actually taking responsibility for. The Accountability Allocation Map assigns the verbs that make shared work auditable. The Acceptance Evidence Chain replaces demonstrations with witnessed end-state evidence. The Whole-Capability Cost Ledger prevents attractive unit pricing from exporting cost into the buyer's operations. Together they make model identity important without pretending it is the outcome.
The strongest rival deserves protection. A supplier cannot fairly guarantee an economic or service outcome when the buyer controls adoption, staffing, policy, data quality, demand or frontline decisions. A vague outcome contract merely transfers uncontrollable risk, invites disputes and encourages defensive pricing. The answer is not to return to model-only purchasing. It is to decompose the desired result into controllable service, integration, control and evidence obligations, while the buyer retains accountable ownership of the operating conditions it controls.
Outcome Procurement StackSpecify eight layers before asking the market for a price
The first layer is the outcome contract. State the business result or decision, affected population, current baseline, measurement window, value route and unacceptable consequence. Name the executive who can accept residual exposure and the owner who can capture the benefit. A target such as “improve claims productivity” is not ready. Specify the claim classes, starting workload, quality floor, customer effect, staff capacity, measurement method and conditions under which speed has no value.
The process boundary describes where work begins and ends. Record the trigger, steps, human handoffs, decision rights, exceptions, downstream effects and completion definition. A supplier may produce a draft while the buyer's queue, approval rules and core system determine whether the case closes. Procurement must expose that seam. Otherwise a vendor can meet output latency while cycle time and customer remedy remain unchanged.
Context and data includes sources, rights, quality, freshness, entitlements, transformations, retrieval, feedback and retention. Buyers often ask suppliers to be accountable for performance while withholding representative data or leaving policy labels inconsistent. The layer distinguishes what the buyer must prepare, what a data provider supplies, what the prime transforms and who verifies lineage. Production data is not an entitlement granted for a convincing demo. A bounded test needs a rights analysis, minimum dataset, protected environment and deletion receipt.
The model component records provider, model or artefact, configuration, intended use, limitations, version, region and substitute. Documentation such as model cards, datasheets and AI service FactSheets can help locate questions and declared limitations. They are evidence inputs, not certification that the model fits this buyer's language, population, process or consequence. A named model family does not resolve the operating version behind an endpoint alias.
Integration and action covers orchestration, tools, identities, APIs, state, evidence, reversibility and dependencies on existing systems. A chat licence and an embedded workflow are different risk and cost objects. If the capability can create a payment, send a notice or update a record, acceptance must test receiving-system state and recovery, not merely the generated text. If a human commits the action, the contract must still define the evidence and capacity that make the review meaningful.
Evaluation and assurance turns the buyer's context into representative cases, population slices, failure modes, red-team exercises, control tests, independent evidence and acceptance thresholds. Generic benchmarks may inform market research, but they do not prove fitness for the buyer's language mix, data quality, escalation load or policy rules. The test configuration, model identity, prompts, retrieval, tools and human workflow are frozen and recorded so the evidence actually belongs to the proposed capability.
Operations and change covers monitoring, support, incidents, data or model changes, revalidation, continuity, capacity and service management. A capability is not accepted once and then assumed stable. The contract states which changes require notice, which require evidence refresh, what happens while evidence is stale and how the buyer receives useful incident facts. Support for the endpoint is not support for the end-to-end service.
Commercial accountability and exit defines the price unit, cost drivers, subcontractors, responsibility boundaries, remedies, evidence rights, portability, transition and retirement. Remedies should follow controllable obligations. Service credit may address unavailable inference, while failed case handling may require correction, affected-person remedy and operating changes. Exit includes configuration, evaluation cases, decision records, retained data, open cases, provider jobs and deletion proof, not just an export of prompts.
| Layer | Minimum buyer question | Acceptance object |
|---|---|---|
| Outcome | Which result, population, baseline, time and consequence define value? | Measured business and affected-person end state |
| Process | Where do trigger, authority, exception and completion sit? | Observed case journey and handoff receipt |
| Context and data | Which rights, quality, freshness and transformations are required? | Lineage, entitlement, quality and deletion evidence |
| Model | Which version, configuration, limits, region and substitutes apply? | Frozen identity and use-relevant evaluation |
| Integration and action | Which tools, identities, states and effects complete the work? | Resource-side action and recovery receipt |
| Evaluation and assurance | Which cases, slices, failures and controls can falsify fitness? | Witnessed threshold and control evidence |
| Operations and change | How are capacity, incidents, drift and change governed? | Monitoring, support, continuity and revalidation proof |
| Commercial and exit | Who pays, remedies, transfers, deletes and retires? | Cost ledger, rights and tested transition |
Procurement Boundary DecisionName what the buyer is buying before choosing how to buy it
A bounded managed capability places the largest operating boundary with one prime. The supplier integrates the defined layers, operates the service, produces end-state and control evidence, coordinates its chain and remedies failures within its control. The buyer still owns business policy, lawful purpose, adoption conditions, residual-risk decisions and consequences that cannot be delegated. This boundary suits a mature, repeatable process when the market can observe and influence the required result.
An integrated capability combines components from several parties under an integrator-owned outcome contract. The integrator is not magically accountable for an upstream provider it cannot see or constrain. Its duty is explicit: resolve version identity, coordinate change, maintain integration and test evidence, enforce downstream controls, expose material opacity and operate remedies. If upstream evidence is unavailable, the contract narrows the promised outcome or blocks that dependency.
A replaceable component purchase is honest when the buyer chooses to integrate and operate the capability. The vendor supplies a bounded model, tool or data service with version, availability, security, documentation, change and exit duties. The buyer owns process design, case evaluation, action controls and outcome capture. This is not inferior to outcome procurement. It becomes dangerous only when commercial language implies a managed result while responsibility and price cover a component.
A paid proof buys evidence, not disguised production. It has a bounded dataset, environment, population, period, spend, access, deletion plan and decision gate. The supplier must produce test artefacts that the buyer can retain and inspect. A proof cannot be used to reach a consequential population merely because the purchase falls below a monetary approval threshold. If the buyer's own data, process or baseline is not decision-ready, discovery should precede even a proof.
The boundary can also be “no AI purchase”. Procurement remains open to deterministic automation, process repair, better search, additional staff or removal of unnecessary work. The UK procurement guidance explicitly starts from the challenge and keeps alternatives open. The discipline prevents a market category from dictating the requirement. It also provides a negative control: if a non-AI method meets the outcome with clearer evidence, lower consequence and better recoverability, it should win.
Accountability Allocation MapReplace shared responsibility with named verbs
For every stack layer, assign seven possible parties: buyer, prime supplier, model provider, integrator, data provider, cloud provider and business operator. Then assign six verbs: supplies, configures, decides, operates, evidences and remedies. A party may hold several verbs, but each failure path needs one named duty and one buyer-side accountable executive. “Jointly responsible” can describe collaboration; it cannot close the map.
The verbs expose quiet gaps. A model provider may supply weights and release notes. An integrator configures retrieval and tools. A cloud provider operates infrastructure. The prime evidences service performance. The business operator decides an exception. The buyer remedies a customer outcome. If nobody is required to reconcile a disputed action after a timeout, the commercial stack has an unowned failure even when every supplier has a security schedule.
The map also prevents impossible liability. Suppose the buyer controls source-data quality, operating policy and reviewer staffing. A supplier cannot own the final service outcome without timely access to those conditions and authority to correct them. The contract can make the supplier accountable for detecting defined input failures, refusing unsafe processing, meeting integration thresholds and reporting their effect. The buyer remains accountable for fixing data and staffing. Outcome orientation becomes more credible when duties follow control.
| Failure path | Named supplier duty | Named buyer duty | Evidence and remedy |
|---|---|---|---|
| Model substitution behind stable API | Prime supplies version identity and notice; integrator revalidates | Capability owner decides continued use | Change receipt, regression result, restrict or roll back |
| Buyer data quality below threshold | Supplier detects, reports and abstains as agreed | Data owner corrects sources and labels | Quality report, excluded cases and re-entry test |
| Action accepted but result disputed | Integrator obtains receiving-system postcondition | Operator resolves customer or business consequence | Action receipt, reconciliation and correction |
| Reviewer queue exceeds safe capacity | Prime limits automated intake and exposes queue state | Operations owner staffs, narrows or suspends service | Capacity telemetry and bounded-work decision |
| Upstream evidence unavailable | Prime discloses the gap and enforces agreed isolation | Risk owner accepts narrower use or rejects dependency | Gap record, compensating control and expiry |
Acceptance Evidence ChainBuy proof of the operating end state, not confidence in a demonstration
Acceptance starts with an agreed use-case population and baseline. Without them, improvement cannot be distinguished from case selection or ordinary variation. The buyer freezes the proposed operating configuration: model version, system instruction, retrieval sources, policy, tools, identities, human role, thresholds and environment. A supplier cannot demonstrate one arrangement and deploy another under the same product name.
Representative cases should be buyer-controlled or independently witnessed. They include ordinary work, important population slices, rare but consequential cases, ambiguous inputs, escalation demand, prohibited actions, dependency failure, load and change. Outcomes are checked at the business system and user journey, not only at the model response. An explanation that “the request completed” is weak evidence when the case record, payment or message says otherwise.
Acceptance specifies error, abstention, escalation and recovery behaviour. A system that reaches its average target by silently dropping difficult cases has failed. So has one that routes too much work to a reviewer group without capacity. Thresholds therefore cover successful completion, harmful or prohibited effect, abstention quality, escalation precision, queue burden, evidence completeness, time to recover and the buyer's ability to intervene.
The finance and operating owners then confirm that the outcome can be captured. If staff cannot change the process, customers do not adopt the channel, savings cannot be removed from the budget or exceptions consume the benefit, technical acceptance has not created an economic result. The supplier should not bear every adoption failure, but the purchase gate must expose the dependency and its owner.
Acceptance is conditional and time-limited. Model, data, policy, tool, provider, population and operating changes can invalidate evidence. The contract names material-change triggers, the evidence that must be refreshed, the authority allowed while it is stale and the decision deadline. This is why a cloud security authorisation cannot prove task fitness: it answers an important security question, not whether this configuration produces acceptable decisions and recoverable effects in this process.
| Gate | Required evidence | Failure disposition |
|---|---|---|
| Population and baseline | Case definition, slices, present outcome and measurement window | Return the requirement for discovery |
| Frozen configuration | Model, prompts, data, tools, controls, people and environment | No inference from demo to production |
| Representative exercise | Buyer-controlled cases, failures, load, human use and witness | Run a bounded paid proof |
| End-state and control proof | Business-system receipts, intervention, escalation and recovery | Repair the layer that failed |
| Benefit capture | Finance and operating confirmation of adoption and capacity | Retain buyer obligation or change the business case |
| Conditional acceptance | Expiry, change triggers, revalidation and permitted stale mode | Restrict, revert or suspend at trigger |
Whole-Capability Cost LedgerCompare the cost that moves, not the price that is easiest to quote
Token and seat prices are valid commercial facts. They are poor totals. The Whole-Capability Cost Ledger records implementation, data preparation, integration, inference, tools, human review, controls, evaluation, monitoring, support, incident response, change, capacity, migration and exit. It assigns each cost to the party that incurs it, the event that drives it and the uncertainty that can move it. A cheap endpoint can be the expensive offer if it exports integration and operating burden.
Cost movement matters more than cost inclusion. One vendor may bundle reviewers and monitoring into a case price. Another leaves both to the buyer. A third offers low inference charges but requires a proprietary retrieval service, premium audit logs and a specialist integrator. Procurement normalises the same operating volume, quality floor, exception rate, support window, geography, evidence requirement and exit scenario before comparing them.
Human review needs causal modelling. The model's error and abstention profile determines case volume; process complexity determines review time; policy and labour conditions determine capacity and cost. A low model price that produces many ambiguous escalations may move the dominant spend into operations. The ledger therefore connects acceptance cases to cost assumptions. Observed escalation, tool use, evidence storage and recovery exercise become commercial data.
Change and exit are current costs, even before they occur. Model substitution can require regression, policy adjustment, retraining and customer communication. Portability may require transforming prompts, evaluation cases, state and interfaces. Retirement includes data deletion, open-case completion, evidence retention and access revocation. If an offer omits these duties, the buyer should price them rather than pretending they are free or indefinitely avoidable.
| Cost family | Typical driver | Comparison treatment |
|---|---|---|
| Build and prepare | Discovery, data repair, integration, controls and evaluation | Amortise against the bounded use and include buyer labour |
| Run | Inference, tools, storage, human review, monitoring and support | Normalise by workload, exception, quality and service window |
| Fail and recover | Incidents, reconciliation, remedy, capacity and continuity | Price tested failure cases and responsibility allocations |
| Change | Model, data, policy, tool, provider or population update | Include notice, revalidation, reconfiguration and restricted mode |
| Exit | Portability, transition, retained evidence, deletion and retirement | Price the credible replacement path at contract formation |
Upstream opacity, change and exitA stable interface can conceal a commercially different capability
An integrator may be unable to disclose training data, model updates or provider controls because the foundation-model provider does not share them. Procurement should not convert that information gap into a claim of confidence. Record unresolved visibility, decide which uses remain supportable, demand available version and behavioural evidence, and isolate the dependency where necessary. The prime's duty includes disclosing what it cannot evidence.
Change terms cover model, data, policy, tool and provider events. Notice must arrive early enough for the buyer to act. The contract states the change identity, reason, affected layers, proposed date, available evidence, compatibility limits and rollback. An unchanged API is not continuity proof. The new model may alter language performance, refusal, tool selection, latency, cost, region, monitoring signals or the human-review burden.
Subcontractor control follows the same boundary. The prime keeps an accurate chain, obtains equivalent duties, reports material replacements and coordinates incidents. The buyer does not need every confidential implementation detail, but it needs enough evidence to make its decision and meet its obligations. Where the chain cannot supply that evidence, the buyer can narrow the population, restrict action, require an independent assessment, retain the service as a component or reject it.
Portability is tested, not asserted. Export formats, evaluation cases, configuration, prompts, decision records, logs, customer data, state and outstanding obligations must move without hidden dependence. A substitute is qualified against the same acceptance chain. Transition assistance has people, time, interfaces and service levels. Deletion rights cover primary, cached, derived, training, support and subcontractor copies, with lawful evidence retention separated from reusable customer content.
Commercial remedies match the affected layer. Missed notice can suspend a change. Failed evidence can restrict production. Unavailable logs can trigger investigation and stronger retention. A harmful external effect requires reconciliation and affected-person remedy, not merely service credit. Persistent opacity or failed portability can trigger exit. The buyer retains authority to protect its population even when a supplier disputes causation.
Ten worked casesChoose the boundary only after scope, duty, evidence and cost align
1. The same model, two incomparable quotes
One vendor includes workflow integration, evaluation and reviewer operations; the other prices only the endpoint. The stack shows that the quotes cover different layers. Procurement normalises integration, human, assurance, support, change and exit cost. If the buyer wants to integrate, the endpoint remains a replaceable component. If not, the broader scope should be competed as an integrated or managed capability, not penalised as expensive model access.
2. Generic benchmark success, buyer-population failure
A managed service cites a strong benchmark, then fails regional language, disability-access and escalation cases from the intended population. Supplier self-evidence cannot close the acceptance chain. The buyer freezes configuration, adds representative slices and witnesses recovery under realistic staff capacity. Production is withheld while a paid proof determines whether the service can meet a bounded managed-capability threshold.
3. The supplier cannot own buyer-controlled adoption
A supplier promises lower case duration, but the buyer controls poor source data, fragmented policy, reviewer staffing and adoption. No supplier should receive the final outcome obligation yet. The allocation map assigns data repair, process simplification, staffing and adoption to named buyer owners. Procurement may buy discovery or components, but rejects the outcome contract until the baseline and controllable obligations are decision-ready.
4. AI enters through a software renewal
A productivity suite adds an AI feature during renewal. The feature can retrieve internal material and alter a consequential workflow, yet it avoids AI-specific evaluation because the parent product already passed security review. The model and integration layers are new even when the vendor record is old. The buyer disables broad use and runs a paid proof with rights, population, evidence, authority and deletion gates.
5. A cheap pilot reaches a consequential population
A department uses a low-cost pilot route below ordinary procurement thresholds. The tool begins ranking service applications for real residents. Price does not define consequence, and “pilot” does not make production effects experimental. The purchase is rejected until impact, data rights, representative cases, accountable decision rights, appeal, monitoring, remedy and a bounded population are in place.
6. A FactSheet without interpretable evidence
The supplier's FactSheet names intended use but provides no interpretable population performance or training-data evidence. Structured disclosure is useful because it makes the gap visible. It is not proof. The buyer requests use-relevant evidence, creates its own cases, requires independent witness and treats the engagement as a paid proof. Missing disclosure never becomes a favourable score.
7. The integrator cannot see upstream change
An integrator offers an outcome but cannot identify foundation-model changes or useful training-data facts because the upstream provider shares neither. The allocation map shows an evidence break. The buyer can retain the model as a replaceable, isolated component with stringent receiver controls, or reject it for higher-consequence use. The integrator cannot own an outcome that depends on invisible, ungoverned change.
8. Low token price, dominant operating cost
Model usage is inexpensive, but tool calls, reviewer handling, monitoring, incident support and repeated revalidation dominate the ledger. A prime can reduce those costs by integrating the path and owning queue, evidence and change duties. Procurement compares the same workload and recovery conditions, then selects an integrator-owned outcome contract rather than the apparent cheapest endpoint.
9. API-stable model substitution
The provider changes the underlying model while preserving the endpoint. Language behaviour, refusal patterns and tool sequencing shift; the buyer's evaluation and reviewer-capacity assumptions no longer apply. The contract treats model identity as a material event. Authority narrows, representative regression runs, cost and controls are reconciled, and the component remains replaceable until evidence supports renewed acceptance.
10. The non-AI alternative wins
A team seeks a generative model to classify routine requests. A deterministic rule and modest process redesign cover the actual categories, preserve reasons and allow staff to maintain exceptions. They meet the outcome with clearer evidence, lower whole-capability cost and easier recovery. Procurement rejects the AI offer. Technology neutrality is not reluctance; it is fidelity to the required result.
Interactive decision artefactOutcome Procurement Boundary Board
The Board returns one commercial boundary from the evidence entered. It does not calculate a vendor score, infer missing obligations or let model quality compensate for an unowned consequence.
Operating cadenceProcurement continues through change, evidence and exit
Before market engagement, the business owner, procurement, finance, operations, data, technology, security, privacy, legal and risk teams define the outcome, baseline, population, unacceptable consequences and buyer-controlled conditions. They map the eight layers, choose the candidate boundary and keep non-AI alternatives open. Data discovery and impact work precede production-data access.
During market engagement, suppliers explain which layers they supply and which remain with the buyer. The team asks each party to allocate the six verbs, identify its provider chain, expose known evidence gaps and describe how cost moves under volume, error, escalation, failure, change and exit. Comparable offers use the same operating assumptions.
At proof and award, the buyer freezes configuration and controls representative cases. Evaluation covers end states, human use, controls, load, failure, recovery and a material change. Finance and operations verify benefit capture and staffing. Acceptance is conditional, time-limited and tied to named evidence. A failed non-negotiable obligation cannot be averaged away by a composite supplier score.
During operation, the contract is joined to actual identities, versions, configurations, provider chain, monitoring and business outcomes. Supplier performance and buyer conditions are reviewed together without blurring responsibility. Incidents produce external-state reconciliation and remedy. Lessons from discontinued and successful acquisitions return to requirements, price assumptions and future tests.
At change and renewal, model, data, tool, policy, population and provider events reopen affected layers. The buyer checks whether evidence, cost, control and human capacity still hold. A broader software renewal cannot silently import a new AI capability. Renewal compares credible substitutes and the cost of staying, moving and retiring.
At exit, the parties transfer approved artefacts, complete or reconcile open work, preserve required evidence, revoke access, stop provider jobs and obtain deletion proof. The buyer tests the replacement against the same capability boundary. Exit success means the business process can continue or stop safely without hidden dependency, not merely that a contract has ended.
Primary evidenceReferences
Links and live status were checked on 2 September 2026. GSA's Buy AI page was updated on 1 September 2026, and the cited GAO acquisition report was published in April 2026. NIST AI RMF 1.0 remains current while revision is under way. Documentation frameworks and voluntary supplier disclosures below are treated as evidence inputs rather than certifications. The Outcome Procurement Stack, Accountability Allocation Map, Acceptance Evidence Chain, Whole-Capability Cost Ledger, Procurement Boundary Decision and Board are this article's synthesis.
- U.S. General Services Administration, Buy AI.
- U.S. Government Accountability Office, Artificial Intelligence Acquisitions: Agencies Should Collect and Apply Lessons Learned to Improve Future Procurements.
- NIST, AI RMF Playbook.
- UK Government, Guidelines for AI Procurement.
- NIST, Artificial Intelligence Risk Management Framework 1.0.
- NIST AI 600-1, Generative Artificial Intelligence Profile.
- NIST AIRC, Technical Reports.
- NIST SP 800-218A, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models.
- European Commission, AI Act regulatory framework.
- CISA and partners, Choosing Secure and Verifiable Technologies.
- OECD, Governing with Artificial Intelligence: AI in public procurement.
- Mitchell, M. et al., Model Cards for Model Reporting.
- Gebru, T. et al., Datasheets for Datasets.
- Arnold, M. et al., FactSheets: Increasing Trust in AI Services through Supplier's Declarations of Conformity.
- Johnson, R. et al., Disclosure or Marketing? Analyzing the Efficacy of Vendor Self-reports for Vetting Public-sector AI.
- Zick, T. et al., AI Procurement Checklists: Revisiting Implementation in the Age of AI Governance.
- Hickok, M., Public procurement of artificial intelligence systems: new risks and future proofing.
- Stanford HAI, 2025 Foundation Model Transparency Index: Transparency in AI is on the Decline.
About this paperForm the purchase around the operating result
The Outcome Procurement Stack, Procurement Boundary Decision, Accountability Allocation Map, Acceptance Evidence Chain, Whole-Capability Cost Ledger and Outcome Procurement Boundary Board are this article's synthesis. They extend needs-first acquisition, performance-based procurement, lifecycle risk, supplier responsibility and documentation practices into a capability-level commercial method. The design does not treat a model, benchmark, demo, cloud authorisation, supplier declaration or low unit price as sufficient evidence of an accountable business outcome.