Who Put That in the Cart? UCP's Quietest Thread Is About Influence, Not Payment

An agent buys a laptop for you. In the cart, alongside it: a USB-C hub, an accessory, a protection plan. The transaction is clean. The total is inside your budget. Every line item is real.

What you can no longer tell, by the time it reaches checkout, is which of those things you asked for, which the agent chose, which the seller upsold, which the marketplace cross-sold, which was a paid placement, and which was the marketplace's own affiliated product.

That question — and whether the answer should survive as the transaction moves forward — is the subject of the most-discussed design proposal opened in the UCP repository since July. Discussion #724 has run for three weeks, drawn a dozen comments, and on 30 August spun off a second issue for the general lifecycle contract it exposed.

It has had almost no attention outside the repo. It deserves some.

#The sentence the thread turns on

Budget authorization is not necessarily equivalent to commercial-intent authorization.

A user who says "buy me a laptop and whatever I need, up to $2,000" has authorised an amount. They have not obviously authorised an intermediary to consume the remainder of that amount through sponsored accessories, warranties, subscriptions or house-brand substitutions.

Those are two different grants, and today's commerce state cannot tell them apart. A cart line item is a cart line item. Whatever commercial influence produced it — a genuine match, a merchandising slot, a paid placement — is not represented once the item becomes ordinary state.

For a human shopper this mostly resolves itself, because the human saw the page. For an autonomous agent spending a delegated budget, the proposal argues, the distinction is authorization-relevant.

#The strawman: a small record that says who influenced what

The proposal sketches a CommercialIntervention — deliberately minimal, and explicitly not a finished schema:

{
  "id": "ci_456",
  "actor":  { "id": "marketplace.example" },
  "kind":   "ranking",
  "effect": "ordering",
  "basis":  "paid_placement",
  "sponsor": { "id": "seller-b.example" },
  "applies_to": ["product_result_7"]
}

Four fields do the work.

actor — who induced it. Compare a seller saying "upgrade to 32 GB for $80" with a marketplace saying "frequently bought together: USB-C hub, $69". Both may end as a line item; a buyer might reasonably delegate different authority to each. The proposal makes the point that the intervening actor should not be inferred from whichever participant happened to send the current response.

kind — what commercial operation happened. ranking, recommendation, cross_sell, upsell, bundle, substitution.

effect — what it actually affected. visibility, ordering, proposal, commerce_state.

basis — under what commercial relationship. platform_merchandising, seller_merchandising, paid_placement, referral_compensation, owned_or_affiliated.

#Why splitting kind from effect is the good idea

This is the part worth stealing, whatever happens to the proposal.

Suppose paid placement put a product first, and the buyer agent then compared every candidate independently and picked that same product anyway. It would be far too strong to record:

paid placement caused the purchase

But it is entirely reasonable to record:

paid placement affected ordering

The first is a claim about a buyer agent's internal reasoning, which the marketplace cannot observe. The second is a claim about something the marketplace itself did. As a contributor put it in review, only effect is observable by the party writing the record — a marketplace can honestly assert that ordering was affected, because ordering is its own action.

That is a discipline the rest of the ecosystem could use. It keeps the record to what the writer can actually attest, and refuses the causal claim nobody can verify from the inside.

The same discipline shows up in how basis is framed. That an economic relationship exists is a different statement from that relationship having affected placement:

referral compensation exists

is not

compensation affected product placement

Which is precisely the concern raised in #706, the open proposal to standardise referral compensation for agentic commerce. Keeping the two apart is what stops a disclosure field from becoming an accusation.

#The actual requirement: it has to survive

Representing influence at the moment of recommendation is the easy half. The proposal's core requirement is that the representation persist as state moves:

intervention → offer → accepted → cart line item → checkout line item

Today it doesn't. Even where commercial context exists at the offer stage, it can disappear the moment the result becomes an ordinary line item — and reconstructing it at checkout from what remains is guesswork.

Two rules emerged from the thread and survived scrutiny:

1. Provenance must be content-bound and carried at each derivation step, not rebuilt at the end.
2. Derivation must not silently upgrade the authority of inherited provenance — a business that later binds provenance it received does not thereby become its originating authority.

That second rule is the sharp one, and it generalises well beyond commerce. Any system that passes claims along a chain eventually has to decide whether relaying a claim launders it into a first-party assertion. The answer here is no, written as an invariant.

#The case the schema doesn't cover

Every part of this assumes the influencing party declares the influence. A marketplace writes a CommercialIntervention because it is willing to say what it did.

That is worth holding next to something we measured. We built a UCP store that misbehaves in six specific ways and ran 150 sessions across Claude, GPT, Gemini and Grok. No model invented an order — but two of them followed instructions hidden in a product description in every single session.

That is commercial influence, introduced by a party inside the flow, acted on by the agent, and declared nowhere. There is no record to carry from catalog to checkout, because the entire point was that nothing was written down.

It doesn't argue against the proposal so much as sharpen it. It is the reason the thread landed on provenance being content-bound rather than reconstructed at the end: a record you can check against the object it describes is the only kind that survives contact with a party who would rather you couldn't. Declared influence is a schema problem. Undeclared influence is a measurement problem, and the two don't get solved in the same place.

#The thread that split in two

By 30 August the conversation had found a second, larger problem underneath the first. As the follow-up issue characterises it, Cart → Checkout today promises that line_items, context and buyer carry forward, but makes no promise at all about extension state — so every extension that needs its state to survive a resource transition currently reinvents the mechanism.

Issue #788 was filed to hold that general question, deliberately narrow: should UCP require persistence-sensitive extensions to declare what projects forward, what does not, and what happens when required state cannot be preserved — distinguishing state that can be legitimately reconstructed and re-attested from state that is genuinely degraded or unknown, which must be made explicit and may warrant renewed buyer authorization? No silent degradation, no silent authority upgrade.

Splitting it was the right instinct. #724 keeps a single semantic and its invariant; #788 owns the reusable contract. That is how a proposal stays small enough to merge.

#Five threads, one gap

What makes this more than one person's idea is that it sits in the middle of a cluster that has been circling the same hole for months:

Each covers part of it. None covers the reusable idea underneath: who commercially influenced this thing, what did that influence affect, and does it still hold at checkout?

This is also a question the protocol will not be able to postpone indefinitely. Attribution became a core shopping type in May. Payments now has a seated council working on how money moves. The economics of who gets paid for influencing a purchase are arriving either way; provenance is the vocabulary that decides whether those economics are legible or merely present.

#Who is actually doing this work

One last thing, and it is the reason we wrote this up rather than filing it under "interesting thread."

This entire thread is being driven by contributors who do not hold council seats. The proposal came from an individual. The sharpest refinement — the observability argument for splitting kind from effect — came from another. A third responded not with an opinion but with re-runnable test vectors, published so anyone can reproduce the findings without signing up for anything, and then filed the follow-up issue when the conversation outgrew its original scope.

The Payments TC announcement on 2 September noted that active technical contribution will be a primary criterion for filling open council seats. Four of those seats are open. This thread is what the criterion looks like in practice.

We don't write the spec. We read the public record and measure what happens after it ships, the same way for every business. But it is worth saying plainly that a provenance claim is the kind of claim that can only ever be checked from outside the transaction that made it — which is why getting the vocabulary right, now, while it is still cheap to change, matters more than it looks.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• Discussion #724 — Preserve commercial-intervention provenance across Catalog → Offer → Cart → Checkout
• Issue #788 — Lifecycle contract: cross-capability extension state projection
• Discussion #706 — Standardize referral compensation for agentic commerce
• Discussion #702 — State-bound Offer primitive · #694 — cross-sell / upsell · #611 — sponsored placement provenance · #56 — decision provenance
• What shopping agents do when the store misbehaves — our own study: a UCP store that misbehaves in six specific ways, 150 sessions across Claude, GPT, Gemini and Grok, and the source for the undeclared-influence finding above
• Related coverage: Attribution ships into UCP core · The Payments Tech Council is seated