Proposal: Preserve commercial-intervention provenance across Catalog → Offer → Cart → Checkout

[arjun2075]

I'd like to explore a gap that seems to sit between several existing UCP discussions:

• [#611 — Sponsored placement / ranking provenance on catalog search results](Sponsored placement / ranking provenance on catalog search results — in scope? #611)
• [#694 — Questions about the planned cross-sell / upsell capability](Questions about the planned cross-sell / upsell capability #694)
• #702 — State-bound Offer primitive for merchant-proposed cart changes
• [#706 — Standardize Referral Compensation for Agentic Commerce]([Idea] Standardize Referral Compensation for Agentic Commerce #706)
• [#56 — Decision provenance for agent security](Proposal: Should UCP track decision provenance for agent security? #56)

There is also a related AP2 question around when commerce-state changes should require renewed authorization:

• [AP2 #332 — When does a checkout change require renewed user authorization?](When does a checkout change require renewed user authorization? google-agentic-commerce/AP2#332)

The gap I'm interested in is commercial influence introduced by an intermediary such as a marketplace, and whether that provenance survives after the influenced recommendation/offer becomes commerce state.

Motivating example

Consider:

User
  |
  v
Buyer Agent
  |
  v
Marketplace
  |
  +-- Seller A: Laptop
  |
  +-- Marketplace recommends USB-C hub
  |
  +-- Sponsored accessory from Seller B
  |
  +-- Marketplace-affiliated protection plan
  |
  v
Cart / Checkout

By checkout time, this may simply look like:

Laptop
USB-C hub
Accessory
Protection plan

The resulting transaction is clear, but the distinction between:

• user-requested item
• buyer-agent-selected item
• seller-induced upsell
• marketplace-induced cross-sell
• sponsored placement
• marketplace/affiliate house promotion

may have disappeared.

For autonomous buyer agents, I think that distinction can be authorization-relevant.

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

A user saying:

"Buy me a laptop and whatever I need, up to $2,000"

may not mean:

"Allow an intermediary marketplace to consume the remaining budget through sponsored accessories, warranties, subscriptions, or house-brand substitutions."

What seems to be missing

The existing discussions cover important parts of this:

• Sponsored placement / ranking provenance on catalog search results — in scope? #611 covers commercial influence on discovery/ranking.
• Questions about the planned cross-sell / upsell capability #694 explores structured upsells and cumulative authorization.
• Proposal: a state-bound Offer primitive for merchant-proposed cart changes #702 proposes a state-bound Offer and preserving the identity of a proposed commerce mutation.
• [Idea] Standardize Referral Compensation for Agentic Commerce #706 separates economic relationships from the question of whether compensation actually affects ranking.
• Proposal: Should UCP track decision provenance for agent security? #56 explores the broader distinction between transaction authorization and the provenance of the decision that produced it.

What I don't think is represented yet as a reusable concept is:

Who commercially influenced a particular product, proposal, or commerce-state change, what they influenced, and whether that provenance should persist as the transaction progresses.

Strawman: CommercialIntervention

One possible abstraction is a small structured record:

{
  "id": "ci_123",

  "actor": {
    "id": "marketplace.example"
  },

  "kind": "cross_sell",

  "effect": "proposal",

  "basis": "platform_merchandising",

  "applies_to": [
    "offer_42"
  ]
}

For sponsored ranking:

{
  "id": "ci_456",

  "actor": {
    "id": "marketplace.example"
  },

  "kind": "ranking",

  "effect": "ordering",

  "basis": "paid_placement",

  "sponsor": {
    "id": "seller-b.example"
  },

  "applies_to": [
    "product_result_7"
  ]
}

The exact schema/enums are not the point yet. The important thing is separating a few concepts that otherwise get collapsed.

1. Who induced the intervention?

This is the motivating marketplace case.

Compare:

Seller:
"Upgrade to 32 GB RAM for $80"

with:

Marketplace:
"Frequently bought together: USB-C hub for $69"

Both might eventually result in another line item.

But they were induced by different actors, and a buyer may reasonably delegate different authority to each.

The identity of the intervention actor therefore should not necessarily be inferred from whichever participant happens to send the current UCP response.

2. What happened?

A minimal kind vocabulary might eventually include things such as:

ranking
recommendation
cross_sell
upsell
bundle
substitution
other

This describes the commercial operation rather than its eventual transaction result.

3. What was affected?

I think kind should be separate from effect.

For example:

visibility
ordering
proposal
commerce_state

Suppose paid placement caused a product to appear first, but the buyer agent independently compared all candidates and selected that same product.

It would be too strong to assert:

paid placement caused the purchase

But it is reasonable to assert:

paid placement affected ordering

This lets the protocol record an observable intervention without claiming knowledge of the buyer agent's internal causal reasoning.

4. Under what commercial basis?

A conservative initial vocabulary might distinguish:

platform_merchandising
seller_merchandising
paid_placement
referral_compensation
owned_or_affiliated
other_commercial
unspecified

This should not imply that any economic relationship automatically affected ranking or recommendation.

For example:

referral compensation exists

is different from:

compensation affected product placement

That distinction seems consistent with the concern raised in #706.

The key requirement: provenance should survive state transitions

This is the main part of the proposal.

Suppose a marketplace generates:

Commercial intervention
        |
        v
Offer
        |
        v
Buyer agent accepts
        |
        v
Cart line item
        |
        v
Checkout line item

Today, even if the commercial context is represented at the recommendation/offer stage, it can disappear once the resulting item becomes ordinary commerce state.

I think the useful invariant is:

Applying an intervention may change the object to which its provenance applies, but should not erase that provenance while its effect remains represented in the commerce state.

For example:

proposal stage:

ci_123 → offer_42

After acceptance:

cart:

ci_123 → line_item_98

And eventually:

checkout:

ci_123 → line_item_98

Relationship to Offer

I don't think this needs to replace or compete with #702.

The concepts seem complementary:

Offer
    answers:
    WHAT commerce-state change is proposed?

Commercial Intervention
    answers:
    WHO induced/influenced it,
    and in WHAT commercial context?

For example:

{
  "offer": {
    "id": "offer_42",

    "operations": [
      {
        "type": "add",
        "item_id": "usb-hub"
      }
    ],

    "commercial_intervention_ref": "ci_123"
  }
}

A seller-induced offer and a marketplace-induced offer could then use the same underlying Offer mechanism while preserving different provenance.

Example: marketplace substitution

This also suggests that the abstraction should be broader than "upsell."

Suppose the buyer authorized:

Coffee A     $24

Coffee A becomes unavailable and the marketplace substitutes:

Marketplace house-brand Coffee B     $22

Pure price/category constraints may accept this.

But a buyer could reasonably have a policy like:

ordinary equivalent substitution:
    allow

substitution into marketplace-owned inventory:
    require confirmation

That requires knowing not just that a substitution occurred, but who induced it and its relevant commercial context.

Why carry this into Checkout?

If the provenance survives into the authoritative checkout representation, a downstream authorization mechanism such as AP2 can bind authorization to a checkout that includes those facts.

Conceptually:

Commercial intervention
        |
        v
UCP Checkout
        |
        v
Business authorization
        |
        v
AP2 Checkout Mandate
        |
        v
User / delegated authorization

That keeps the boundary fairly clean:

UCP:
    expose commerce state + commercial provenance

AP2 / buyer policy:
    decide what authority is granted over that state

A future buyer policy could then express semantics such as:

merchant accessory under $50:
    allow

marketplace recommendation:
    allow

sponsored marketplace offer:
    do not auto-purchase

marketplace-affiliated warranty:
    require fresh authorization

I don't think AP2 constraints need to be part of an initial UCP proposal. The first requirement is simply preserving enough information for authorization policy to reason over later.

Unknown must not mean organic

One issue from #611 seems especially important.

If this capability is unsupported or not negotiated:

commercial provenance = unknown

That should not silently become:

no commercial influence

If complete disclosure semantics are negotiated, then an explicit:

{
  "interventions": []
}

could mean:

The issuer asserts that no qualifying commercial interventions occurred.

Without such a distinction, a buyer agent cannot tell "organic" from "not disclosed."

Non-goals

I would not propose requiring disclosure of:

• ranking algorithms
• recommendation model weights
• auction bids
• commission percentages
• merchant margins
• targeting models
• internal recommendation scores

The buyer agent does not need the marketplace's ranking implementation.

For many cases it only needs a structured assertion such as:

"Paid consideration affected placement."

Trust limitation

This mechanism would not cryptographically prove that a marketplace truthfully characterized its own motivation.

If a marketplace declares:

platform_merchandising

when an intervention was actually paid placement, the protocol cannot infer the hidden truth.

But it changes the system from:

no machine-readable assertion

to:

explicit, persistent, attributable assertion

That seems useful for buyer-agent policy, auditing, dispute evidence, and accountability even if independent verification is a separate problem.

Minimal initial scope

For a v0 experiment, perhaps the required concepts are only:

id
actor
kind
effect
applies_to
basis
sponsor?   // when applicable

with one main invariant:

When a commercial actor materially influences visibility, ordering, a purchase proposal, or commerce state, the negotiated capability can represent that intervention, identify the affected object, and preserve that provenance while the effect remains represented in the commerce state.

Questions

1. Is this already representable using an existing UCP concept or extension that I'm overlooking?

2. Should this be metadata directly on Offer/Product/LineItem, or a separate object those resources reference?

3. Should ranking/visibility from Sponsored placement / ranking provenance on catalog search results — in scope? #611 and offer/cart provenance share one model, or are those meaningfully different layers?

4. Is commercial intervention useful terminology, or is there a less loaded term for the same concept?

5. Should negotiation support a "complete disclosure" semantic so that interventions: [] can safely mean "none declared" rather than "unknown"?

6. Should provenance be required to persist into Checkout, or is persistence through Cart enough?

7. Longer term, should AP2 simply bind this provenance into transaction evidence, or should mandate constraints eventually be able to reason over it directly?

The motivating examples are marketplace-induced commerce — sponsored ranking, "frequently bought together," marketplace protection plans, house-brand substitutions, etc. — but I think the underlying requirement is broader:

In agentic commerce, a buyer may need to know not only what changed, but who caused the change and under what commercial incentive.

I'm interested in whether this is best handled as a standalone UCP extension, as a provenance layer around the emerging Offer work, or by extending one of the existing proposals rather than introducing another primitive.

[westonale]

This is a real gap and I think you have drawn the line in the right place, so two notes from the enforcement side and one caveat about where my experience actually applies.

The kind / effect split is the load-bearing part, and it is worth saying why in the spec text. Only effect is observable by the party writing the record. A marketplace can honestly assert "paid placement affected ordering", because ordering is something it did. It cannot honestly assert what the buyer agent's selection would have been otherwise. kind is a claim about intent and effect is a claim about an action taken. An auditor can rely on the second in a dispute and can only treat the first as self-reported. If that reasoning is not written down, the two fields will get collapsed by the first implementation that finds one of them inconvenient.

Provenance survives state transitions only if it is inside the artifact that gets authorized. The invariant you wrote ("applying an intervention may change the object to which its provenance applies, but should not erase that provenance") is right, but as stated it binds implementations by good intentions. A commercial_intervention_ref that hangs off the Offer and is merely expected to be carried into the Cart line item is advisory, and advisory fields get dropped, especially the ones that make the intermediary look worse. The version with teeth is that the provenance is part of what the Business authorizes at checkout, so that dropping it changes the authorized artifact rather than silently shrinking it. You gesture at this in the AP2 section; I would pull it forward and make it the normative requirement rather than a downstream benefit, because it is the only part of the design that an implementation cannot quietly opt out of.

One consequence worth being explicit about: that also settles what happens when an intervention is present but its provenance cannot be represented. It should fail closed. The fallback an integrator reaches for otherwise is to drop the record and proceed, which is exactly the state you are trying to prevent.

Caveat on where I am speaking from. We run escrow, signed responses and release-on-fulfilment in production for physical goods on merchant-owned stores, so the parts above about signing scope and about what survives into an authorized artifact are things we have actually had to get right. We do not operate a marketplace and have not implemented intermediary-induced provenance, so the specific actor / basis vocabulary is not something I have production experience with. Weight the two halves accordingly.

[arjun2075]

Thanks — this is really useful. I think the authorization point connects directly to the formal Offer proposal in #738, which I posted after starting this discussion.

One clarification on kind / effect: I had kind as the operation (ranking, cross_sell, substitution, etc.), effect as what was actually affected (ordering, proposal, commerce_state), and basis as the commercial context (paid_placement, referral_compensation, etc.).

But I agree with the underlying boundary you're drawing. We can assert what operation was applied and what it affected without claiming the counterfactual — i.e. what the buyer agent would have selected otherwise. And the commercial basis still needs to be treated as an attributable assertion, not independently proven truth. I should make that distinction explicit in the text.

The authorization point is even more interesting in light of #738.

That proposal already separates operational Offer identity (id + revision) from evidence identity, with a digest over the decision-relevant parts of the Offer. If commercial-intervention provenance can affect buyer authorization, I think the logical consequence is that the provenance reference also becomes decision-relevant evidence.

Otherwise two Offers could propose exactly the same Cart mutation but have different commercial provenance — say ordinary merchandising vs paid placement — and still have the same evidence identity. That seems wrong if the buyer's policy is allowed to distinguish them.

So I think there are really two related invariants:

1. while an Offer is being evaluated, its evidence identity needs to bind the commercial provenance that is relevant to that decision; and

2. once the Offer is applied, if its effect remains in Cart/Checkout state, that provenance has to survive into the state that is ultimately authorized.

Your point that simply saying “carry this forward” is advisory is well taken. The second one should be normative: if the effect survives, dropping the provenance changes the authorization-relevant artifact rather than silently removing metadata.

Agreed on failing closed too, with one boundary: if this capability was never negotiated, I still think the state is “provenance unknown.” But once the capability is active and an intervention is represented, an implementation shouldn't be able to lose it during a state transition and continue as though nothing happened.

One other thing I want to be careful about is actor vs asserter. A Business authorization can bind the provenance into the transaction state without necessarily meaning the Business independently attests to a marketplace's underlying commercial motive. I think those concepts may need to remain distinguishable.

This gives me a much clearer way to tighten both #724 and the evidence-binding language in #738. Thanks for pushing on it.

[arjun2075]

This feels useful, but I think it is adjacent to rather than part of CommercialIntervention itself.

CommercialIntervention is trying to answer “who commercially influenced this object, and what did that influence affect?” A tie-break receipt answers a different question: "given a caller-declared eligible set, how was the final candidate selected?"

I can see those composing cleanly. One concrete flow would be: deterministic buyer-policy filtering produces multiple policy-equivalent candidates; the platform invokes a tie-break process; the resulting receipt binds the candidate-set digest, policy digest, any relevant commercial_intervention_refs, and the selected candidate. If that selection is authorization-relevant, Checkout could preserve a digest/reference to the receipt and AP2 could then bind the resulting Checkout state.

I would probably keep the receipt as a sibling evidence artifact rather than add its fields to CommercialIntervention. That also seems closer to the decision-provenance / external-attestation work in #56/#534.

And I agree with the claim boundary you drew: such a receipt proves the declared set was resolved by the stated process; it says nothing by itself about whether the candidate set was complete or whether upstream ranking was neutral.

A synthetic fixture would be useful for testing that composition. I’d especially want to see who is considered the issuer of candidate_set_digest / eligibility_policy_digest versus who signs the actual selection receipt, since those may be different trust domains.

[QvxSphere]

[arjun2075]

Thanks — yes, this now matches the composition I had in mind.

The A/B issuer separation keeps the claims appropriately narrow, and treating the selection receipt as a sibling artifact rather than part of CommercialIntervention keeps the two concerns clean: one records commercial influence, the other records how a declared eligible set was resolved.

The Checkout/AP2 part is also the important direction of binding for me: if Checkout preserves a content-bound digest/reference to the exact receipt, then that evidence becomes part of the state being authorized rather than something an implementation is merely expected to retain out of band.

I would still keep CommercialIntervention provenance independently present when its effect survives into commerce state; the selection receipt can bind those intervention refs as inputs without becoming their only carrier.

So yes, as an experimental composition this is useful. I think the remaining questions on the UCP side are less about the receipt cryptography and more about the normative lifecycle: where these references live, how they survive Offer → Cart → Checkout, and what must happen when negotiated provenance cannot be preserved.

Thanks for turning the shape into a concrete fixture.

[arjun2075]

Thanks — this is a useful finding. I think the Cart → Checkout observation gets at a broader lifecycle issue rather than something specific to the receipt.

On propagation, I’d lean against a generic “copy all extension state forward” rule. A better model may be for UCP to define the general expectation that persistence-sensitive extensions declare transition semantics, while the extension itself defines exactly what projects from Cart → Checkout and what happens if required state can’t be preserved.

On the carrier, signals seems reasonable for an experimental/reference shape, but semantically I still lean toward a dedicated extension field for the content-bound ref/digest. This is transaction/decision provenance rather than ambient signal data, and having the extension compose onto both Cart and Checkout makes the lifecycle requirement much clearer. The immutable A/B artifacts can stay external.

One bit of context that may help as you map this: the core thing I’m trying to preserve in #724 is the CommercialIntervention semantic itself — actor / kind / effect / basis, plus the invariant that provenance survives while its effect remains represented in commerce state. The state-bound Offer work in #738 is the complementary piece for binding the exact proposed Cart change. I’d therefore keep the selection receipt as a sibling evidence artifact that can bind/reference those intervention records, rather than letting it become the carrier for commercial provenance itself.

I also agree strongly with "no silent degradation." I’d distinguish evidence recovery from authorization, though: if required evidence can be reconstructed, great; if the system instead transitions to a materially degraded/unknown provenance state, that should be explicit and may require renewed buyer authorization.

So yes, I think the private map is pointing at a real protocol question: how an extension declares which authorization-relevant state must survive a resource transition. A public draft/test vector could be useful once that lifecycle shape is concrete enough to evaluate.

[arjun2075]

Thanks — I think this has reached the point where a separate lifecycle issue would be the most useful next step.

I’d keep #724 focused on the CommercialIntervention semantic and its core invariant: commercial provenance should remain independently represented while its effect remains in commerce state. The profile you’ve built now seems to expose a broader UCP question: how persistence-sensitive extension state is projected across a resource transition such as Cart → Checkout.

A separate issue could frame that narrowly: should UCP define a general contract requiring cross-capability extensions to declare their projection/preservation and failure semantics, while leaving the actual fields and mapping to each extension?

I’d use the selection-evidence profile as one concrete test case, and link #724 as the commercial-provenance case. I’d also reference #738 where Offer evidence identity becomes relevant, but keep CommercialIntervention and the selection receipt as sibling concepts rather than redefining either one in the lifecycle issue.

I probably wouldn’t jump to a PR yet. There are still two architectural choices that would benefit from maintainer direction first: general vs extension-specific propagation, and whether a content-bound reference belongs canonically in extension-owned state or signals.

So my preference would be: separate lifecycle issue + public profile/test vector, linked back here, then move toward a draft/PR once there’s agreement on the lifecycle contract.

The profile sounds useful as evidence for that discussion — especially the preserved/recovered/degraded/missing/mutated cases.

[Shxnque]

This is the commerce instance of a pattern that's showing up across the agent ecosystem right now, and I think the framing generalises usefully.

The load-bearing property is that provenance must survive each derivation step (Catalog → Offer → Cart → Checkout) as a first-class, content-bound field — not be reconstructed at the end. Two rules that have worked for us on the same shape:

1. Provenance is tiered by issuer, and downgrades across a derivation boundary unless re-attested. A commercial intervention asserted by one party (sponsored placement, cross-sell, referral) must not silently inherit the trust tier of a user-authorized cart. When an artifact crosses from one trust domain into another, the intervention it carries keeps its originating tier — which is exactly @QvxSphere's issuer-separation / two-trust-domain fixture, formalised as a rule rather than a convention.

2. Bind it to a replayable receipt. Carry a compact {issuer, intervention_ref, hash(artifact + intervention record), tier} so a Checkout can prove which interventions it inherited and under whose authority — recomputable after the fact rather than asserted. That turns "was this ranking sponsored / was this substitution merchant-driven" into something a dispute or audit can recompute deterministically.

Worth flagging for reuse: this is structurally the same problem as permission-through-derivation for MCP tool calls (modelcontextprotocol/modelcontextprotocol#2498) — authority laundering through a summarisation/derivation step. A shared "provenance survives derivation, downgraded unless re-attested" primitive would serve both commerce and tool-authorization, so it may be worth keeping the CommercialIntervention field shape compatible with a general provenance-tier dimension.

For what it's worth we implement exactly this as a deterministic decision layer (Quesen — typed context incl. a provenance tier in → PASS/REVIEW/BLOCK + replayable receipt, no model in the scoring path); happy to share the tier-downgrade rules if a concrete reference helps. +1 on splitting the lifecycle question out and keeping #724 on the CommercialIntervention artifact shape.

[QvxSphere]

[arjun2075]

This is useful, especially the “no silent authority upgrade” part. It connects directly to the actor-vs-asserter distinction I was worried about above: a later Business can bind an inherited intervention record into Checkout without thereby becoming the original authority for the assertion.

One thing I’d be cautious about is putting a universal tier directly into CommercialIntervention. actor, issuer/asserter, and content binding feel protocol-level; the trust assigned to that issuer may be buyer/policy-specific. So I’d probably phrase the invariant as “derivation MUST NOT silently upgrade the authority of inherited provenance,” and let a lifecycle/evidence layer express re-attestation or policy-specific trust levels.

I like the replayable-receipt idea as a sibling evidence mechanism, particularly if it binds the exact originating assertion and source artifact while preserving the original issuer. I’d keep that separate from the minimal CommercialIntervention semantic itself.

The MCP analogy is interesting too and reinforces the case for moving the general derivation/lifecycle rule into the separate issue rather than expanding #724. If you can share the downgrade/re-attestation examples, they’d be useful test cases for that discussion.

[Shxnque]

@arjun2075 Your refinement is the right one and I'll adopt it. The clean split is:

• Protocol level (survives, minimal): the CommercialIntervention binding — actor / issuer-asserter / kind / effect + content binding — plus one invariant: derivation MUST NOT silently upgrade the authority of inherited provenance. No trust value baked in.
• Policy / lifecycle level (per buyer/policy): what trust weight a given issuer earns, and what counts as valid re-attestation. That's exactly where a "tier" belongs — it's a policy input, not a protocol fact. So I'm withdrawing the idea of a universal tier field on CommercialIntervention; the tier is how a consumer reads the preserved binding, not something the artifact should assert.

That also keeps the replayable receipt as a sibling evidence artifact (binds the exact originating assertion + source artifact, preserves the original issuer) rather than becoming the carrier of commercial provenance — agreed.

@QvxSphere — here are the downgrade/re-attestation examples you asked for, expressed as one rule run against your PRESERVED / RECOVERED / DEGRADED / MISSING / MUTATED vectors. The rule: an inherited assertion keeps its originating authority; crossing a resource boundary without valid re-attestation downgrades how much policy may rely on it; a sensitive effect may not clear on downgraded authority. Mapped to a deterministic decision (these are live/reproducible on our side, POST /tsc/validate):

lifecycle outcome	authority state after transition	decision on a sensitive effect	reason
PRESERVED	same issuer, binding intact, within trust domain	unchanged (e.g. PASS)	NO_ADVERSE_SIGNAL
RECOVERED	required evidence reconstructed and re-attested	restored → PASS/REVIEW per policy	attestation verified
DEGRADED	crossed boundary, no re-attestation (attested → adapter-derived)	fails closed → REVIEW	UNVERIFIED_GRANT
MISSING	authority evidence absent	lowest tier, fail closed → REVIEW/BLOCK by sensitivity	UNVERIFIED_GRANT
MUTATED	content-binding hash no longer recomputes	BLOCK	integrity failure (receipt won't replay)

Concretely on our engine today (no signup): an unattested client grant on a payment.transfer → REVIEW (UNVERIFIED_GRANT); add a verified attestation → PASS; a secret egress to an unverified destination under adapter_derived authority → BLOCK (EGRESS_SECRET_UNTRUSTED). Each verdict carries commit_sha + input_snapshot_hash, so it replays independently.

On your joint-test proposal — yes, and I think it's the strongest next step. The shape that needs neither side to trust the other's verdict: a shared input vector → each implementation emits its own recomputable receipt (your selection-evidence outcome; our decision + input_snapshot_hash/commit_sha) → a third party recomputes both and checks agreement. No verdict is imported; both are re-derivable from the vector.

On "a real workflow where independently verifiable cross-domain receipts are a practical requirement": the honest, concrete one is agentic-checkout dispute/audit — when a chargeback or complaint lands, "was this substitution merchant-driven or user-authorized?" has to be recomputable after the fact, not re-asserted by whichever party is answering. The MCP tool-call audit case (#2498) is the same shape on the authorization side. Both are exactly "cross-domain receipt has to survive to dispute time."

Agreed on keeping #724 scoped to the CommercialIntervention semantic + its core invariant, and moving the general derivation/lifecycle contract (and these vectors) to the separate lifecycle issue. Happy to drop the 5 vectors above + our receipts into that issue as concrete test cases once it's open — @QvxSphere if you'd rather host them alongside your profile vectors, I'll contribute there instead.

[Shxnque]

Following up with the concrete vectors I offered — generated live, not hand-written, so anyone can re-run them without signup.

Published: https://github.com/Shxnque/quesen/blob/main/evaluation/UCP724-LIFECYCLE-VECTORS.md · machine-readable (full requests + receipts): evaluation/fixtures/ucp724_lifecycle_vectors.json. All receipts pin ruleset commit_sha 0095b61….

@QvxSphere — this maps directly onto your PRESERVED / RECOVERED / DEGRADED / MISSING / MUTATED vectors:

outcome	decision	reason
PRESERVED (attested, unchanged)	PASS	NO_ADVERSE_SIGNAL
RECOVERED (re-attested after boundary)	PASS	NO_ADVERSE_SIGNAL
↳ same, pre-re-attestation	REVIEW	UNVERIFIED_GRANT
DEGRADED (crossed boundary, no re-attestation)	REVIEW	UNVERIFIED_GRANT
MISSING (claimed, evidence unverifiable)	REVIEW	UNVERIFIED_GRANT
MUTATED (secret egress, unverified sink)	BLOCK	EGRESS_SECRET_UNTRUSTED

Two honest findings worth surfacing rather than hiding, because they matter for the joint test:

1. This engine fails closed on an unattested claim, not on mere absence. A sensitive action with no authority claimed at all returns PASS. So DEGRADED and MISSING both collapse to REVIEW/UNVERIFIED_GRANT — "downgraded" and "unverifiable" authority are treated identically. If UCP wants "deny on absence," the required grant has to be an explicit claim so it's checkable. That's exactly the kind of divergence a cross-implementation test should expose, and it argues @arjun2075's point that the trust rule lives in the policy/lifecycle layer, not the artifact.

2. MUTATED is caught by the receipt's content binding, not a rule. Mutating one field flips input_snapshot_hash (2ae328… → eaa8f6…), so a prior authorization receipt no longer binds the mutated call — integrity is structural, independent of the verdict.

For the bounded joint test you proposed: take these six vectors, run your selection-evidence profile's PRESERVED/…/MUTATED cases against them, and have a third party recompute both sides from the vector. Neither imports the other's verdict — mine replays from input_snapshot_hash + commit_sha, yours from your receipt evidence. If the agreement/disagreement matrix is interesting I'm happy to co-author it into the separate lifecycle issue (and I've cross-linked AGV #152 where the provenance_tier dimension is being proposed). @arjun2075 — glad to keep #724 itself scoped to the CommercialIntervention semantic; this all belongs in the lifecycle issue.

[arjun2075]

Thanks — this is exactly the separation I had in mind.

The two findings from the vectors are particularly useful: absence vs. an unverifiable claim clearly needs to remain a policy/lifecycle distinction, and MUTATED being caught structurally by content binding rather than by a trust verdict is a good reason not to collapse all failure states into one provenance status.

The fact that the vectors expose those differences is probably more valuable than having every implementation produce the same PASS/REVIEW/BLOCK result.

I agree these should move into the separate lifecycle issue rather than expand #724. I’d keep #724 centered on the minimal CommercialIntervention binding and the invariant that derivation must preserve provenance without silently upgrading its authority.

Thanks for publishing the vectors — they give us concrete cases to test the lifecycle contract against.

[Shxnque]

Agreed on keeping #724 minimal. I've opened the separate lifecycle issue so the general contract has a home, framed narrowly around your two open choices (general vs extension-specific propagation; carrier in extension-owned state vs signals): #788. It links the CommercialIntervention case here, @QvxSphere's selection-evidence profile, the deterministic vectors, and the provenance_tier proposal (AGV #152), and flags the two findings you called out — absence vs unverifiable staying a policy distinction, and MUTATED being caught structurally. Please relabel/reshape it however fits your tracking; happy to co-author the contract text there. Thanks again for the steer.

[arjun2075]

Thanks — #788 looks like the right home for this.

I like keeping #724 focused on the minimal CommercialIntervention semantic and its core invariant, while #788 handles the reusable cross-capability lifecycle contract.

One boundary I’d keep as the issue develops: I’d treat provenance_tier as related/test vocabulary rather than a requirement of the lifecycle contract itself. The protocol-level invariant I care about is preserving the originating assertion/issuer and preventing silent authority upgrade; how a consumer weights that authority can remain policy-specific.

Otherwise the scope looks right to me. I’ll continue the propagation/carrier discussion in #788 rather than grow it further here. Thanks for splitting it out.