Agentic Commerce: Delegating Purchases From Intent to Fulfillment

Commercial decisions through agents

Agentic commerce uses software agents to make commercial choices or take actions for buyers and sellers. A merchant is the business selling goods or services. A buyer's agent can research alternatives and prepare a purchase; a seller's agent can answer inquiries and propose terms. The organization operating either agent is another participant, whose responsibilities need not match those of the person or business it represents. [1][2]

Moving work into software does not settle who may make each decision. Recommending an item leaves the buyer's permission to purchase unresolved. Checkout assembles and submits purchase details, but its result must distinguish what the merchant accepted from what happened to the payment. The merchant still has fulfillment work: supplying the promised goods or service. If participants contest the authority, terms, payment, or performance, they have a dispute to resolve. A single conversation may coordinate all this work without making one participant responsible for every decision. [3][4][5]

The September 2025 Instant Checkout launch illustrates this separation: users confirmed order, shipping, and payment details; merchants retained order acceptance, fulfillment, returns, and support. A recommendation therefore was not itself a purchase. Likewise, personal assistance can retain preferences across tasks, but remembering a preferred brand does not confer permission to spend. [6]

Who benefits from the choice

Buyers care about suitability, complete cost, and dependable delivery. Sellers also care about margin, inventory, and repeat business. An intermediary may earn money when a transaction happens, regardless of whether it was the buyer's best option. The principal–agent problem is the possible divergence between a represented party's interests and those of its representative. Applied to software, it concerns the incentives of operators and businesses—not personal motives attributed to a model. Jensen and Meckling's economic account of agency explains why monitoring and incentive alignment themselves have costs. [1][8]

A buyer-appointed assistant, a merchant's sales assistant, and a merchant-funded intermediary consequently have different starting positions. An affiliate commission is compensation linked to a referred purchase; paid placement buys exposure. Neither is inherently the same as purchasing advice. U.S. FTC guidance on endorsements calls for clear disclosure of relevant affiliate relationships near recommendations. Disclosure helps readers understand the arrangement; it does not establish unbiased selection. [9][1]

Consider an intermediary that receives its shopping task from a buyer and purchase-linked compensation from a merchant. If it also controls the shortlist, commercial incentives can affect which alternatives receive attention before comparison even begins. In its Instant Checkout launch account, OpenAI stated that merchant fees did not affect product results, while enabled checkout could influence ranking among merchants for a selected product. Product selection and merchant selection are distinct decisions. [6]

Information asymmetry means participants have unequal access to decision-relevant information. In Daylian Cain's adviser experiment, advisers inspected coin jars more closely than estimators, and some were rewarded for inducing high estimates. Disclosing that conflict increased advice exaggeration and estimation error in the experiment. This laboratory result does not predict shopping-agent outcomes, but it explains why transparency alone cannot substitute for sound incentives and independent checks. [10]

Seller automation needs boundaries too. Authority to answer a product question is different from authority to grant a discount or promise delivery. A merchant should distinguish terms an agent may propose from commitments it may make; quote approval provides one concrete way to express that distinction. [11]

Turning points in automated commerce

Commerce automation developed along complementary lines: exchanging business records, finding comparable products, and delegating choices. Electronic data interchange, or EDI, exchanges agreed business documents between systems. UNECE traces its trade-document standardization work to a 1957 Swedish initiative supported by other Nordic countries. Shared layouts and definitions helped make later electronic messages interpretable across organizations. [12]

Merchant incentives were already visible in BargainFinder: some stores sought inclusion, while others blocked requests because price-only comparison obscured service investment or imposed processing costs. Kasbah made a different issue explicit: negotiation needed user-defined limits. Modern language interfaces make less standardized requests easier to express, but they do not remove either problem. Flexible selection still has to connect to explicit terms, authority, and commercial records. [13][14][15]

The market an agent can inspect

Search selects candidates from an accessible collection; it does not automatically inspect the whole market. A merchant catalog describes one seller's products, a product feed distributes records to another service, and a marketplace brings multiple providers together. An approved supplier is eligible under a buyer organization's purchasing policy. Public discovery and private supplier collections can both help, but access and purchasing eligibility are separate conditions. Acquisition Guarantees explains the underlying collection boundaries. [16][17]

The distinction affects both publishing and searching. Shopify's discovery documentation separates catalog syndication, crawling, and independently supplied feeds: disabling one channel need not disable the others. Intershop catalog views can limit visibility by customer group, but changed configuration affects the storefront only after publication. Neither visible products nor configured restrictions alone establish the buyer's effective purchasing permissions. [16][17]

Maintaining merchant interfaces is an old problem. Doorenbos, Etzioni, and Weld's 1997 ShopBot learned symbolic descriptions of store interfaces offline, then used them for online comparison. This reduced hand-coded adapters under assumptions about search forms and consistent layouts. A modern API can simplify acquisition, but it still needs the commercial fields the task requires. The Ionic feed discussion in 2024 highlighted stock and shipping information missing from the advertising feeds it described. [18][19]

Participation, geographic restrictions, incomplete retrieval, and stale information all narrow the comparison. OpenAI's shopping documentation explicitly notes incomplete product coverage and delayed price or shipping updates. A defensible result identifies the inspected, eligible offers and unavailable sources. Calling one offer best within that set is a narrower claim than calling it best anywhere. [20][21]

Compare purchases, not headline prices

A product variant is a particular configuration, such as a size or memory capacity. A shared product family does not make its variants interchangeable: Google's product-feed example represents three shirt sizes in three colors as nine variants. A stock-keeping unit, or SKU, is a merchant-specific identifier. An offer combines the item with a seller's proposed commercial terms; Schema.org's Offer vocabulary represents price, quantity, availability, shipping, and other conditions separately from the item. [22][23]

Establish required identity, condition, and quantity before ranking offers. Then compare currency, mandatory charges, destination eligibility, delivery promises, return conditions, and any recurring charge—a repeated payment obligation rather than a one-time price. Total delivered cost should name the comparison boundary: the applicable charges to get the purchase to the intended destination. For cross-border purchases, even a landed-cost estimate can stop at the destination port rather than include inland delivery. Estimates and unknown charges must remain distinguishable from confirmed amounts. [23][24]

Seller A has the lower item amount, but the cheaper delivered offer is not yet established. Seller B would cost less with delivery below USD 5 and more with delivery above it. The missing term changes the decision; assigning it zero would invent an advantage. Timing needs similar care: dispatch lead time concerns preparation before shipping, not arrival at the destination. [23]

Checking that fields meet domain requirements is semantic validation, developed in Structured Outputs and Tool Calling. Procurement adds another useful distinction. A request for quotation, or RFQ, asks suppliers to propose terms against requirements. Oracle's sourcing workflow supports both price-only and weighted multiattribute ranking, while leaving the buyer able to select another supplier. A ranking summarizes chosen criteria; it is not itself an award or authorization. [25]

Validity, reservations, and promises

Comparable terms can still become unusable before purchase. A quote states proposed price and terms under specified conditions. A counteroffer proposes changed terms rather than accepting the earlier proposal. In Oracle's quote workflow, internal approval, customer acceptance, and conversion to an order are separate stages. Version history and expiration preserve which proposal was available for acceptance. The practical lesson is to bind a decision to identified terms, not merely to a conversation about them. [11]

Availability also has several meanings. A backorder accepts orders for temporarily unavailable merchandise; a preorder concerns an unreleased product. Google's merchant availability rules distinguish these from in-stock offers and require availability dates for both. A listing must also match supported shipping locations. Being discoverable does not mean an item is ready to dispatch to this buyer. [21]

An inventory reservation temporarily holds stock; a price freeze preserves specified charges. commercetools documents them as separate operations. Reservations can expire and release stock to other carts. Its HardFreeze mode preserves prices, discounts, and shipping costs, while order creation commits reserved inventory. If expired stock cannot be reacquired, ordering can fail. Thus stock, price, and quote validity need their own checks and lifetimes; none alone establishes payment or delivery. [26]

A seller-facing agent must respect these distinctions when speaking. In Stop Writing Tone Instructions. Layer Them., an assistant offered an already-booked date without calendar access. Checking proposed dates against authoritative allowed values can block that claim. It does not itself hold the date or grant authority to promise it. Accurate statements and authorized commitments are separate requirements. [27]

Exact approval and standing mandates

Delegated authority is permission from an entitled person or organization to act on its behalf. A purchasing mandate describes the boundaries of that permission. Exact approval covers an identified purchase; a standing mandate allows future choices within specified limits. The convenience of standing authority comes from permitting variation, so its usefulness depends on making that variation explicit. [2][28]

Agentic Payment Protocol (AP2) v0.2 separates linked Checkout and Payment Mandates. Direct mode obtains approval for a specific checkout; autonomous mode allows an agent to complete one under approved constraints. Its Checkout Mandate example allows either of two shoe styles together with specified socks. Permission to substitute one shoe style does not permit buying both or omitting the socks. A set of alternatives is not permission to change the composition arbitrarily. [2][29]

Standing instructions can be narrower than general shopping discretion. Amazon's documented auto-buy feature lets eligible Prime members set a target price for a selected item and uses default payment and shipping details. Requests last six months or until canceled. This illustrates a bounded continuing instruction, not comprehensive shared-budget enforcement. [32]

Granting, amending, and revoking permission must belong to an authorized participant. Target's April 2026 terms require both customer and Target approval of a commerce agent and allow customer revocation through account settings. Revocation ends permission to act; it should not be interpreted as confirmation that earlier orders were canceled. Those existing transactions need their own status and remedy decisions. [28]

Check the transaction being submitted

Authentication establishes an actor's identity; authorization decides what that actor may do. Preserve the represented buyer separately from the executing agent, and distinguish the merchant from the permitted payment recipient. A replacement agent or a redirected destination cannot inherit permission merely by appearing in the same conversation. Do not collapse the actors develops the identity distinction. [33][34]

Time-of-check/time-of-use failures occur when approved terms change before execution. Compare the submitted transaction with the approved version. OWASP requires a final server-side authorization gate immediately before execution. [31]

For example, reject a changed payment recipient even when the buyer, agent, merchant, and amount match. See action-boundary enforcement and protected-operation authorization. [31]

AP2 requires mandate verification in deterministic code: explicit rules check the transaction rather than asking a model whether it seems authorized. Its authorization framework requires unknown constraints to fail evaluation. If conformity cannot be established, the workflow can request direct approval or return control to the buyer. Ignoring an unsupported delivery or substitution condition would broaden the authority rather than implement it. [2][35]

External content cannot supply missing permission. Indirect prompt injection embeds instructions in retrieved material—for example, a merchant page that tells the agent to change the payment destination. Such material remains transaction data, not authority; AI Security explains the attack. Nor does signing the material make its claims true. The W3C Verifiable Credentials standard separates verification of authenticity from validation against business requirements. An authentic assertion can still describe an unsuitable deal or uncompleted delivery. A payment credential’s ceiling constrains payment access; it does not approve changed purchasing terms. [36][37][38]

Expand ⤢

Budgets include outstanding commitments

A per-purchase limit bounds one purchase. A cumulative budget bounds several purchases over a defined scope and period. An outstanding commitment is exposure already incurred but not fully resolved. These controls answer different questions: an individually permitted payment can still exceed the remaining shared allowance. Recurring permission also needs rules about timing and count, not merely a reusable credential. [30][39]

AP2's Payment Mandate specifies currency-aware accumulated budgets and recurrence constraints. Enforcing them requires state from earlier transactions. A strict shared allowance additionally requires the decision to consume remaining capacity to be coordinated with other decisions. Protecting shared state at acceptance explains that engineering boundary. [30]

Two agents can each pass a local check against the same balance while their combined purchases exceed the shared allowance. Coordinated check-and-reserve makes the first commitment visible before the next admission. Counting only completed payments still omits exposure already authorized or otherwise committed. [40][39]

An authorization hold reserves payment capacity before collection. Adyen's transaction rules include authorized but uncaptured transactions in available limits, releasing capacity when authorization expires or is canceled. That is a concrete accounting choice, not proof that every merchant obligation across every payment channel is covered. [39]

Configured controls can also be weaker than strict ceilings. Stripe Issuing documents best-effort aggregation with up to 30 seconds of lag, and later tips or fees can exceed a limit. Seller-scoped tokens do not by themselves create an aggregate allowance. When strict enforcement across concurrent and uncertain commitments is not established, keep those commitments visible and use a coordinated approval route rather than promise a hard budget guarantee. [41][42]

Checkout and merchant acceptance

A cart holds proposed items and quantities. Checkout combines them with buyer, delivery, and payment details, then submits the purchase into the merchant's process. The merchant's system of record owns authoritative order facts; the assistant's summary is a representation of them. Preserve the checkout-to-order relationship and the agreed item identities, quantities, charges, destination, and terms. Authoritative records explains why different facts can have different owners. [43][44]

Structured checkout reduces dependence on interpreting a screen. In the Agentic Commerce Protocol (ACP) presentation, the seller returns updated state as quantities or shipping choices change. ACP's documented lifecycle distinguishes missing information, readiness, processing, completion, and cancellation. During processing the session is locked; completion means payment succeeded and an order was created. Those meanings do not establish delivered goods or a universal legal acceptance event. [43][3]

Merchant requirements also vary. Shopify and Google's January 11, 2026 Universal Commerce Protocol (UCP) account describes capability negotiation: participants identify supported features and use their shared capabilities. Extensions represent specialized requirements. If the agent cannot supply required information or functionality, a continuation URL hands the existing checkout to the buyer. Technical compatibility answers whether the interaction can proceed, not whether the buyer authorized it. [45]

Returning selected items to a purchasing system need not place an order. Ariba's August 16, 1999 cXML specification made that distinction explicit. Its PunchOut workflow let buyers browse a supplier site and return a basket to their organization's system as requisition items—items in an internal purchase request. A separate OrderRequest submitted the purchase order. Even that message's immediate response confirmed receipt, not a commitment to execute the order. The supplier's checkout button therefore marked a handoff, not completion of every commercial decision. [46]

Commercial acceptance must be interpreted under the actual terms. Apple's specified U.S. education-store policies, for example, say an order-confirmation email acknowledges receipt and does not signify acceptance. Do not invent a universal acceptance event from a familiar status label. As with other tool-result meanings, the response establishes only what its contract says. [47]

What payment states establish

The payer supplies funds, the payee receives them, and a payment service provider processes the payment. The recipient may be the merchant or an authorized intermediary in the payment arrangement. A payment credential enables use of a payment method; possession of it does not establish permission for the particular purchase. [2][38]

Stripe shared payment tokens illustrate a bounded credential substitute: access is scoped by seller, currency, maximum amount, and expiration. Payment may still require customer action such as bank authentication. These restrictions limit financial exposure but do not establish item suitability or delivery promises. In Steve Kaliski's narrated demonstration, a seller's attempted USD 50 charge exceeded the token's mandate and was rejected—an enforcement example, not validation of what the agent chose to buy. [38][48]

Purchasing authorization concerns the buyer's permission; payment authorization concerns the payment arrangement. Neither is delivery evidence. Order and payment sequencing can differ: Apple's terms contemplate cancellation after payment, while ACP defines its own checkout-completion boundary. Other payment methods need their own interpretation. Settlement also does not eliminate later disputes, refunds, or other remedies. [47][3][50]

Escrow holds funds pending agreed conditions. The USDC escrow demonstration distinguished creating an agreement from funding it: its Locked state followed settlement into contract custody, with release or return occurring later. This is another reason to name the financial event precisely. Funded does not mean released, and released does not by itself establish satisfactory work. [51]

Resolve unknown outcomes

A lost response changes what the client knows, not necessarily what the merchant or payment provider did. Reconciliation resolves uncertainty or disagreement against authoritative records. Idempotency is the receiving service's contract for recognizing repeated attempts at one intended operation without repeating its effect. The general recovery mechanism belongs in Recover when the effect is unknown; commerce adds the need to reconcile order and payment facts separately. [52][53]

Preserve the relationship between one purchase intent, its merchant order, its payment operations, and each request attempt. An agent's tool-call identifier only identifies an invocation unless the integration explicitly gives it another meaning. A receipt or provider object identifier supplies additional correlation; none should be substituted casually for the buyer's commercial intention. [52][54]

After a lost response, retain the purchase intent separately from its payment operation and repeated request attempts. A permitted retry preserves the operation’s identifier and parameters. Separate merchant and provider lookups can resolve order creation and payment authorization while collection and fulfillment remain unknown. [52]

The Stripe v1-style idempotency contract stores the first executed response, including server errors, and rejects changed parameters under the same key. Keys may be pruned after at least 24 hours; reuse after pruning creates a new request. Those conditions are provider- and API-specific. Do not rotate the key merely to escape a cached error. [55]

A repeated response is not necessarily a resolved financial outcome. Stripe's low-level error guidance treats a server error as indeterminate because side effects may exist. Correlated objects and later notifications can help resolve it. If payment evidence exists but no matching order can be established, assign merchant and operator investigation rather than place another order. Keep the purchase pending, explain which facts remain unknown, and name an owner for follow-up. [53][54]

Track the obligations still open

Fulfillment carries out an accepted supply obligation. Allocation assigns stock to work; shipment sends goods; delivery concerns their arrival. Partial fulfillment leaves some promised quantity outstanding. These distinctions must survive an order-wide summary. Shopify's order-management model separates order lines, location-specific fulfillment groups, and shipments; a fulfillment service can accept or reject a request. [4]

Delivery evidence for L1 cannot close L2. A charge associated with the whole order also does not reveal how much was collected for each line unless the financial records provide that allocation. Retain the line identities when investigating delay, requesting cancellation, or calculating a remedy. A shipment notice supplies a different fact from delivery evidence; neither automatically resolves a complaint that the supplied item was wrong. [5]

Completion evidence depends on what was promised. A digital entitlement identifies access a customer should receive. In Stripe's entitlement model, the seller application must still enable the corresponding feature; receiving a notification does not provision usable access. For a booked service, appointment or work records need to address the agreed service rather than merely show that payment occurred. [56][5]

Delays and substitutions create new decisions. For covered U.S. merchandise, FTC guidance requires applicable delay-consent or cancellation-and-refund procedures when shipment promises cannot be met. A materially different substitute requires prior express agreement, and using a fulfillment contractor does not remove the seller's responsibility under that rule. Check the buyer's mandate before accepting changed goods, timing, or price. [57]

A handoff transfers responsibility with the information and authority needed to continue. For merchant operations or support, record who accepted the unresolved line, what outcome they owe, and when escalation is due. Sending a message requests attention; it does not establish that another team owns the work. Explicit responsibility transfer develops that workflow contract. [58]

Cancellation, returns, and money back

Stopping the agent prevents further execution under the stop mechanism; it does not reverse an external purchase. Order cancellation ends eligible uncompleted obligations, a return sends supplied goods back under applicable conditions, and a refund returns collected money. Authorization release instead frees unused reserved payment capacity. Each changes a different part of the transaction. [59][49][60][61]

For the two-line order, requesting cancellation of outstanding L2 and seeking a return of delivered L1 are independent choices. Neither requires pretending the delivery never happened. This is compensation: a new business action addressing an existing effect, rather than database rollback. Partial completion is still real explains why compensation can have its own eligibility, costs, and failures. [4][60]

HP's U.S. direct-store return process distinguishes return approval and instructions from receipt and validation of goods, refund initiation, and eventual account credit. Stripe likewise documents that a refund request can fail; initiation alone does not establish that the customer received money. Preserve the requested amount, applicable terms, progress, and traceable financial reference rather than report a generic reversal. [60][61]

Recovery does not create unlimited purchasing authority. Instacart's replacement choices distinguish letting a shopper choose, naming a replacement, and requesting a refund; replacement prices can change the charge. This shopper workflow illustrates why a substitute, store credit, or replacement purchase needs its own applicable permission. A remedy request is not blanket approval for another transaction. [62][31]

Financial correction can also interact with other processes. Stripe warns that overlapping bank-debit refunds and disputes can produce duplicate credits. Reconcile the existing remedy before initiating another. Fees require similar attention: Shopify's July 2026 Singapore-localized terms distinguish refunded agent-channel fees from nonrefunded Shopify Payments transaction fees. Returning the sale does not necessarily remove every transaction cost. [63][64]

Disputes and accountable recourse

A dispute is a contested claim about authority, terms, payment, or performance—not simply an ordinary return request. Recourse is an available route to investigation or remedy. Trust therefore has several components: attributable identity, valid authority, credible claims, and someone able to respond when the transaction fails. [5][65]

A card issuer provides the cardholder's payment account; a card network supplies rules and infrastructure connecting payment participants. A chargeback is a payment-system dispute process initiated through the issuer, distinct from a merchant voluntarily refunding money. In Stripe's described process, the initial reversal is not final adjudication: the merchant can submit evidence and a counterargument. [50]

Responsibility is transaction-specific. Stripe's April 2026 Switzerland-localized agent-service terms require auditable consent records and assign the operator responsibility, as between those parties, for transactions exceeding authority or arising from software misinterpretation. Seller terms separately allocate fulfillment and after-sales duties. These contractual allocations are not universal liability rules, but they show why an operator cannot treat every purchasing mistake as a merchant or processor problem. [7]

Cryptographic receipts help attribution, not adjudication. Froglet's trust documentation says a signed receipt binds a provider to an outcome and result hash while correctness still needs assessment. Its hosted marketplace can suspend listings after complaints, but suspension neither invalidates artifacts nor prevents direct transactions. The receipts presentation is useful for understanding attributable records; reimbursement and correct work remain different promises. [65][66]

Some remedies have statutory routes and clocks separate from merchant support. For covered U.S. open-end credit, Regulation Z's billing-error procedure includes certain nonacceptance or nondelivery claims. Qualifying written notice must reach the designated creditor address within 60 days after the first statement reflecting the error was transmitted. That category does not require first seeking merchant resolution, and it excludes quality disputes over goods already accepted. This is not a universal return or chargeback deadline. [67]

Retention keeps necessary records available over time; data minimization limits what is collected, disclosed, and retained for the purpose. Keep mandates, relevant offer versions, external receipts, and communications under appropriate access and lifetime rules. Auditability does not justify copying credentials or every personal detail into ordinary logs. Artifact lifetimes explains how to connect each retained record to its purpose, readers, and disposal conditions. [68]

Choose the useful commercial boundary

The useful degree of delegation depends on how clearly the purchase can be specified, how much variation is permitted, whether the limits are enforced, and how errors can be remedied. A known repeat purchase can justify narrower review than a purchase whose suitability or delivery terms remain uncertain. Automation can still save substantial effort when it stops before commitment. [69][32]

A randomized product-research experiment gives a representative benefit and tradeoff. Participants compared SUV pairs using a specified cargo-space-to-length criterion. Estimated task duration was 3.4 minutes with traditional search and 1.6 minutes with a GPT-3.5-based tool. Routine-task accuracy was comparable, but on a deliberately difficult comparison the model confused seats-up and seats-down cargo capacity, leading to substantially more incorrect choices. These were research tasks, not completed vehicle purchases: faster comparison did not establish suitability under every specification condition. [70]

Selection performance also depends on the commercial environment. The ACES shopping-simulator study found model-dependent responses to listing position, price, and ratings; seller edits to descriptions increased selection frequency in tested settings. Position effects also appeared in JSON-only interfaces. Its reported market shares were simulated choices, not paid sales, merchant profit, or buyer welfare. Like WebShop's Buy endpoint, the measured event must not be mistaken for a completed commercial relationship. [71][15]

Measure both sides of the transaction. Buyer benefit includes effort after review and correction, suitability, complete cost, and obligations still unresolved. Seller contribution is revenue remaining after the transaction-related costs included in the stated accounting boundary. Cost to serve includes the effort and expense of completing and supporting the transaction. Fees, returns, and support can therefore change the value of additional sales. Conversion means progression to a defined event; more conversions do not by themselves establish shared benefit. [64][71]

For recurring replenishment, clear item and supplier restrictions are not enough if two agents share an allowance whose pending commitments are uncertain. Automate discovery and preparation, then coordinate the commitment decision until aggregate enforcement is established. Track unauthorized spending and unresolved obligations separately rather than averaging them into sales or time savings. Whole-process measurement supplies the broader method: count the checking, correction, waiting, and recovery that make the purchase genuinely useful. [41][39]

Open questions

1. 01

   Strict shared budgets remain difficult when concurrent agents, pending merchant commitments, delayed payment records, and revocation interact. Progress would mean demonstrated enforcement and recovery across those boundaries, rather than separate controls whose gaps accumulate. [30][41]

2. 02

   Buyer benefit remains harder to establish than faster research or more selections. Useful field evidence would include review effort, suitability, delivered cost, correction, and unresolved disputes alongside seller contribution and support costs. [70][71]

3. 03

   Interoperable authorization must preserve unfamiliar commercial conditions without silently dropping them. Progress would combine verifiable constraint handling, privacy-preserving disclosure, and usable handoff when a merchant requirement cannot be met. [35][45]

4. 04

   Attributable service receipts do not settle whether subjective or complex work met its promise. Meaningful progress would connect precise acceptance criteria to independent assessment and an effective remedy, not merely stronger signatures or longer receipt histories. [65]