Where should commercial term formation end and UCP transaction execution begin?

[arjun2075]

Discussion #502 explores buyer-agent negotiation. This question is slightly broader: regardless of whether terms come from bilateral negotiation, RFQ, procurement, or an external market mechanism, what artifact—if any—should cross into UCP before Checkout?

UCP currently appears to provide three relevant pieces:

• Cart for pre-purchase exploration, with estimated totals.
• Checkout once purchase intent exists, with payment optionally omitted for use cases such as quote generation.
• The Offer work in #738 / #773, which addresses a Business-proposed change to a specific Cart state.

The boundary I am trying to isolate is different from #738/#773. It concerns commercial terms that may be formed outside UCP—or before a UCP Cart or Checkout exists—and then need to be carried into a transaction with the Business responsible for executing them.

Examples include:

• a buyer agent and Business reaching terms through bilateral negotiation;
• a procurement system selecting a supplier response from an RFQ;
• a marketplace or auction producing winning terms;
• an external broker or market mechanism producing terms that a Business is willing to honor.

Conceptually:

external term formation
↓
terms selected or agreed
↓
handoff into UCP
↓
Business-returned Cart or Checkout
↓
Order

I do not think UCP should define bidding rules, negotiation strategy, participant selection, auction clearing, scoring or ranking, reserve prices, or how a marketplace reaches a result. Those concerns can remain mechanism-specific.

The interoperability question is the handoff: should different term-formation mechanisms be able to produce something that a UCP Platform and Business can consistently recognize, validate, and bind to the resulting transaction?

I see three plausible boundaries:

1. No pre-Checkout artifact. The Platform submits ordinary Cart or Checkout inputs, and the Business returns the terms it can honor. Any negotiation, quote, or award reference remains out of band.
2. An opaque reference. Cart or Checkout carries a reference to externally formed terms that the Business resolves and validates.
3. A minimal portable artifact. UCP defines common semantics for a finalized proposal, quote, or award and its binding to Cart or Checkout, without standardizing the process that produced it.

Questions for maintainers:

• Is one of these already the intended UCP model?
• Should this handoff land in Cart, in Checkout creation or update, or in a separately addressable pre-Checkout resource?
• If externally formed terms are referenced, does UCP need a portable binding between those terms and the authoritative Cart or Checkout, or is the Business restating the terms sufficient?
• Would this belong in core UCP, an optional generic extension, vertical-specific capabilities, or entirely outside UCP?
• What minimum invariant, if any, would be useful across bilateral negotiation, RFQ/procurement, and external marketplaces without pulling their mechanisms into UCP?

This is not proposing a competing negotiation design or an auction protocol. #502 should remain the discussion for the bilateral negotiation flow. I am trying to isolate the more general architectural boundary before proposing any schema or implementation.

If maintainers consider this the same scope as #502, I am happy to consolidate the discussion there.

[juanferrub]

Adding a B2B perspective from Shopware, and building on the buyer-agent negotiation direction in #502.

We are currently working on B2B agentic commerce and have implemented RFQ/quote workflows as a vendor extension. Our experience suggests two complementary layers:

1. A Business may advertise and operate a buyer-agent negotiation flow.
2. Once terms are agreed—through that flow, an RFQ, a marketplace, or a human-assisted process—UCP needs a portable way to carry those terms into authoritative Cart or Checkout execution.

For B2B, this is not an edge case. Pricing may depend on buyer identity and contracts, volume tiers, inventory allocation, delivery dates, payment terms, and human approval. These workflows commonly involve revisions, expiry, counteroffers, and asynchronous steps before an order can exist.

We would support a minimal, optional term-formation artifact or capability that works with bilateral negotiation as well as RFQ/procurement flows, without trying to standardize negotiation strategy or supplier selection. It should be revisioned and time-bound; bind parties, line items, and commercial terms; record acceptance or award state; and bind deterministically to the authoritative UCP Cart or Checkout.

An opaque reference may help bridge existing implementations, but portable semantics should remain the destination. We would be glad to share concrete B2B flows and lessons from our extension if that helps shape a proposal or working group.

[arjun2075]

Thanks Juan — the Shopware implementation experience is particularly useful here because it gives us a concrete B2B case rather than designing this boundary from first principles.

I also like the separation you describe between the two layers. #502 can stay focused on whether and how a Business advertises and operates negotiation, while this thread can focus on what must survive once commercial terms have actually been agreed and need to enter authoritative UCP transaction state.

Rather than choosing a schema yet, I think the next useful step is to derive the smallest common contract from a few concrete flows.

If you can share sanitized examples from your extension, especially an RFQ → revised quote → accepted terms → Cart/Checkout flow, an expiry/revision or counteroffer across an asynchronous pause, and a flow involving human approval, I can turn those into protocol-level test vectors and compare the two handoff models discussed here: an opaque reference versus a minimal portable artifact.

The comparison I’d want to make is whether each model can preserve term identity/revision, parties, item/quantity scope, expiry, acceptance or award state, and deterministic binding to the Business-authoritative Cart or Checkout without pulling negotiation strategy or supplier-selection semantics into UCP.

If those flows expose a stable common subset, that would give us a much stronger basis for a vendor-namespaced experiment or eventual proposal than designing the artifact top-down.

[juanferrub]

Hi @arjun2075

Sharing more info below. You can see an example of our current B2B Quote capability here:

• Prose specification: https://sw-ag.dev/.well-known/ucp/specs/quote.html
• OpenAPI contract: https://sw-ag.dev/.well-known/ucp/schemas/quote.openapi.json

It currently supports request, retrieval/polling, counter, accept, and decline operations. The lifecycle distinguishes the merchant turn (open / in_review / change_requested) from the buyer turn (replied), with expiry as an explicit property. A buyer can accept, counter, or decline only from replied.

It takes into account the three flows you named:

1. RFQ → merchant review → revised quote → buyer acceptance.
2. A counteroffer across an asynchronous pause, including revision and expiry.
3. A request outside the merchant’s automation policy that is escalated to a human

One implementation lesson already seems relevant to the handoff boundary: the quote is a durable, customer-authorized commercial object, not just a Cart with a temporary discount. Its identity, ownership, state, expiry, offered unit prices, tax-status-aware totals, and decision trail have to survive that human-led pause. In our current implementation, acceptance places an order through the B2B quote flow; a UCP-native handoff would instead need to bind that accepted commercial state deterministically to the resulting Cart or Checkout.

Let me know if this helps

[arjun2075]

This helps a lot — thanks Juan. The fact that the quote has to survive async and human-led pauses as its own durable commercial object is particularly useful for defining the boundary here.

I’m going to work through the spec and the three flows you shared and map the accepted-quote → Cart/Checkout handoff against the two models we discussed: carrying an opaque reference versus carrying a minimal portable set of agreed-term semantics.

I think the useful test is whether we can preserve quote identity/revision, expiry, item/quantity and price scope, acceptance state, and deterministic binding into the resulting transaction without pulling the negotiation workflow itself into Checkout.

I’ll bring the resulting comparison back here rather than proposing a schema upfront.

[westonale]

One property worth adding to that comparison, because it decides whether either model is safe rather than whether it round-trips.

Everything on the list so far is preservation: term identity and revision, parties, item and quantity scope, expiry, acceptance state, deterministic binding. All necessary. But a handoff can preserve every one of those and still move pricing authority to whoever formed the terms, because preservation describes what the artifact carries, not what the Business is permitted to do with it.

The missing property is direction of authority. When the accepted quote reaches the authoritative Cart or Checkout, is it an input the Business reads a price out of, or an assertion the Business must independently re-derive and agree with before the transaction exists? Those two can produce an identical wire format and have very different failure modes. In the first, anyone who can mint or replay a term-formation artifact can set a price. In the second, a forged or stale artifact fails closed because the Business recomputed and disagreed.

Juan's point that the quote is a durable, customer-authorized commercial object is exactly why this bites. Durable objects outlive the conditions they were priced under. Inventory allocation moves, a contract tier lapses, a delivery date slips past what the quoted freight assumed. Expiry covers the clock but not the state, so an unexpired quote can still be one the Business would no longer agree to, and the human-led pause is precisely the window where that drift happens.

Concrete test for both models: can the Business decline an artifact that is valid, unexpired, correctly bound to the right parties and line items, and still wrong? If a model has no representation for "I recognize this and I do not agree", it has quietly made the external artifact authoritative, and the opaque-reference version hides that more effectively than the portable one, since there is nothing to re-derive against.

That also suggests a fourth flow worth adding to the three you asked Juan for: accepted quote, then a Business-side rejection at binding time. It is the flow that separates the two models, and it is the one neither an RFQ nor a counteroffer example exercises.

[arjun2075]

That’s a useful distinction. I was treating deterministic binding mainly as an identity/integrity property, which misses who actually has authority over the terms at the transaction boundary.

I’ll add the fourth flow: an accepted, unexpired, correctly scoped quote reaches Cart/Checkout after relevant Business state has changed.

One thing I’d like the comparison to distinguish, though, is whether the artifact represents a Business-issued commitment or merely accepted terms that still require Business revalidation. In the latter case, “recognized but no longer agreed” clearly needs to be representable. In the former, allowing arbitrary repricing at binding time could undermine the semantics of the quote itself.

So I think the additional property is not just rejection support, but explicit authority/commitment semantics: who authorized the terms, what authority the artifact carries, and under what conditions that authority can be invalidated before execution.

I’ll make that a separate dimension in the comparison rather than folding it into deterministic binding.

[arjun2075]

I worked through the implementation cases we discussed and turned them into a small review artifact with seven protocol-level vectors:

https://github.com/arjun2075/ucp-term-handoff

The vectors cover accepted RFQ, async revision, human approval, scope mutation, expiry, Business rejection at binding, and a Business-issued firm commitment.

The main thing that fell out of the exercise was that four concerns need to stay separate:

• preservation/integrity of the accepted terms;
• authority provenance;
• commitment semantics;
• binding-time revalidation/invalidation.

The V6/V7 pair was particularly useful. V6 models a valid, recognized artifact that may still be rejected because its commitment semantics explicitly retain Business revalidation. V7 models the opposite case: under the harness's proposed business_firm semantics, ordinary state drift alone does not invalidate the commitment unless a declared invalidation condition applies. That is a candidate semantic for review, not a claim about current UCP behavior.

Comparing the two handoff models also exposed different gaps:

• an opaque reference handles Business resolution/current revision well, but needs a shared binding-result contract and exposes little scope/commitment information to the Platform;
• a portable artifact makes those semantics visible, but needs verifiable issuer authorization and a freshness/supersession mechanism.

A hybrid — portable semantics plus an authoritative Business reference and classified binding result — looks worth testing, but I don't think the evidence is strong enough yet to make that a UCP proposal.

@westonale @juanfernandez — I'd particularly like to know whether the commitment distinction and the rejection taxonomy match the failure/implementation cases you had in mind, or whether there's a case these vectors still miss.

[westonale]

Both match, and I7 through I11 are sharper than what I described. Separating issuer from authorized_by is the piece I did not have, and it is what turns I9 from a principle into something a verifier can actually check.

Two cases the vectors do not reach. Both come from one assumption, visible in I12: binding is one evaluation, at one instant, of one artifact, against one target.

The window does not close at binding. In both V6 and V7 the state change lands before the bind attempt, and the timeline ends at the bind. But a bound Checkout is not an executed transaction. It sits until completion, and the same conditions can move again in that gap: V6's inventory allocation, V7's contract tier, or a freight assumption the quote priced. By then the commitment has been evaluated and there is nothing left to revalidate against, so the harness has no outcome for "bound, then the conditions that made it bindable stopped holding". Two clocks are in play and no invariant says which governs the interval between them: the quote's expiry and the Checkout's own lifetime. It bites hardest on business_firm, which reads as an obligation through expiry, so a firm quote can hold a Checkout open past the point the Business would still honor it.

The shape that sidesteps that interval rather than shortening it is worth naming: where settlement is conditional on fulfillment, the terms lock at agreement and value does not move until delivery is confirmed, so the interval does not have to be drift free. That converts a revalidation problem into a release condition. Not the only answer, but it is the one that makes the gap between bind and execute safe rather than short.

Binding is all or nothing. The taxonomy in unresolved question 3 is per artifact. I3 forbids silent scope expansion and nothing covers scope contraction, so a 40 line award where 38 lines still bind and 2 are no longer available resolves either as a whole artifact recognized_rejected, discarding 38 valid lines, or as a bind that quietly dropped 2, which is I3's failure mode in reverse. Per line binding results, each carrying the accepted revision, would cover it. It is a common B2B shape rather than an edge case, and it makes unresolved question 7 harder: after a partial bind, a retry has to be idempotent per line rather than per artifact.

[arjun2075]

Thanks — I extended the artifact around both gaps you identified, while leaving V1–V7 unchanged:

https://github.com/arjun2075/ucp-term-handoff

For the bind → execute gap, I added two cases:

• V8: a valid artifact binds, then relevant Business state changes before execution. The harness now treats binding and execution as separate lifecycle points and requires the relationship between term expiry, transaction lifetime, and post-bind invalidation to be explicit.
• V9: the alternative shape you mentioned: commercial terms lock at binding, while execution/settlement waits on a declared release condition. A failed release condition produces explicit non-execution without repricing the agreed terms.

For partial binding, I ended up going slightly broader than per-line results. A line isn't always independently severable when pricing, freight, minimums, bundles, or thresholds span multiple lines, so the harness now uses explicit binding units / atomicity groups:

• V10: a 40-line award has four independent units; 38 lines remain effectively bound, two fail explicitly, and replay of an already-bound unit is idempotent.
• V11: several commercially dependent lines form one atomic unit; one unavailable required line rejects the whole unit rather than silently contracting scope.

That also pushed idempotency down to the granularity of artifact + revision + binding unit + target transaction.

The model comparison still doesn't select a universal carrier. Both opaque references and portable artifacts need additional transaction-lifecycle semantics for the post-bind cases, and partial binding needs an authoritative grouped-result contract either way.

The parts I'd most like you to challenge are:

1. whether the post-bind authority modes are actually distinct enough;
2. whether the binding-unit abstraction captures the partial-bind case you had in mind better than raw per-line results;
3. whether a failed binding unit should ever be able to succeed under the same artifact revision, or whether that necessarily requires a new authorized transition.

[westonale]

Binding units are the better abstraction. Per-line results are just the case where every unit has one line. Taking your three questions in order, against what the harness does today:

1. The four modes are distinct, but they sit on two axes, not one. Three of them say what bounds execution: the original term expiry, a separate deadline, or the transaction's own lifetime once authority transfers at bind. Conditional release answers a different question, which is what has to happen before value moves. Real terms often need both, because a delivery-gated release still needs a date it cannot pend past. A single mode enum means only one of the two ever gets evaluated, and the evaluator shows it: the deadline checks only run for their own modes, and transaction.valid_until is never read, so a release that is neither confirmed nor failed reports release_pending indefinitely, including past V9's own transaction lifetime. Splitting mode into a deadline source plus an optional release condition fixes the shape. The piece that needs a declared rule is what happens when the deadline arrives with release still pending, because that default decides who ends up holding the value: back to the buyer as non-execution, or forward to the Business as deemed accepted. Both exist in practice, so neither can be the silent default.

2. Units capture it, with one coupling V10 avoids by construction. None of V10's 40 lines is an order-level term, and its commercial terms state outright that the four units are independent. In a real award, freight, an order minimum or a volume tier is often computed across the whole award, so when U4 fails the price basis for U1 through U3 can move with it. With all_or_nothing as the only atomicity mode, that leaves two choices: collapse every unit into one group, which removes partial success, or bind the survivors at prices computed for scope that did not bind. What closes it is letting the artifact declare, under the Business's authorization, how an order-level term recomputes when scope contracts. A partial bind then applies a rule both sides already accepted instead of repricing at the boundary.

3. Yes under the same revision, never under the same attempt. The idempotency key identifies an attempt and the revision identifies an authorization, and the harness currently ties the two together. Once U4 has a prior failure it stays rejected even after its lines come back, which is exactly what test_retry_cannot_turn_prior_failure_into_success_without_transition asserts, and a fresh key returns idempotency_conflict, so under the harness U4 has no path to success at revision 4. The failure reason should decide. line_unavailable is a fact about Business state at one moment and nothing in the accepted terms changed, so a new attempt inside the validity window should be able to bind. stale_revision and atomicity_violation are facts about the artifact, so they need a new authorized transition. Treating a restock as a new revision has a real cost: the Business re-issues identical terms, the buyer has to accept revision 5, and with approvals in the loop that is V3 again for terms that never changed. Replaying the same attempt should still reproduce the failure, which the harness already gets right.

[arjun2075]

Weston, your validation of binding units helped settle that abstraction. I’ve opened a reviewable revision: arjun2075/ucp-term-handoff#1

Deadline policy now composes with optional release conditions, including an explicit pending-at-deadline disposition. Cross-unit contraction uses previously authorized deterministic adjustment rules. Attempt identity is separate from revision: same-attempt replay preserves the failure, while a fresh attempt can recover transient availability under the same valid authorization.

Could you challenge those three choices—particularly the deadline boundary/disposition, the limits on authorized contraction adjustment, and the transient-versus-structural retry classification? V1–V7 remain unchanged.

[sanj-directbooker]

I'm coming from the world of hotels, and would like to suggest adding a third flow that differs from the B2B cases above in one respect: the terms are formed by a party that is neither the buyer nor the Business.

PR #780 (Lodging Booking Capability) does this as an existence proof of need. The spec separates "provisional discovery" from "authoritative booking": search, quotation and room lookup return "provisional rates", available room types and policy summaries,. Creating the booking session is where the Business locks or evaluates real-time inventory, resolves binding rate rules, calculates totals and attaches authoritative cancellation terms.

What between these stages is minimal. The Platform sends accommodation.id, either a pre-composed room_rate.id or both room_type.id and rate_plan.id, and the itinerary. The spec describes those identifiers as sourced from upper-funnel discovery mechanisms and says nothing further about them. Provisional prices and policy summaries are effectively discarded and restated by the Business during the "authoritative booking" step.

In the taxonomy above that sits close to model 1, with a trace of model 2: ordinary Checkout inputs plus identifiers whose provenance is out of band, with the Business restating the terms. It is cheap and it works. What it does not preserve maps onto the list you and Juan assembled:

• Term identity and revision. On the compound path the identifiers are reconstructible by any party holding current room type and rate plan codes, so they identify a product binding rather than an offer.
• Expiry. The hold on price and availability starts at session creation. A provisional rate carries no stated validity, so a Platform cannot tell a buyer how long a quoted price is good for.
• Party identity. Nothing records which party formed the terms the buyer saw. In travel the discovery layer is frequently a third party, so the Business receives a session with no indication of who quoted what.
• Acceptance state. Absent by construction, since nothing was agreed before session creation.

In the world of lodging this is a known, prevalent, annoying problem: a website will show a low rate to get the click and then show the user a higher price when they're about to book. Having run the Price Accuracy team while part of Google Hotels, I've been fighting this problem for years. I'd like to prevent it in the world of Agents.

The reason I think this bears on the general boundary rather than only on lodging: it is an existing capability where external term formation is already assumed and deliberately left unspecified. If a minimal portable artifact lands, lodging is a test of whether it can describe terms formed by a third party rather than by the two parties to the transaction. If it cannot, model 3 ends up meaning bilateral only.

[arjun2075]

This is a useful third case, and I think it exposes a boundary slightly earlier than the accepted-term handoff we’ve been modeling.

In the lodging flow, room_rate.id or room_type.id + rate_plan.id + itinerary tells the Business what to evaluate, but it does not identify the actual provisional price/policy the buyer saw. The Business then authoritatively validates inventory and evaluates/restates the commercial terms when the booking session is created.

So I think there are two separate things we should avoid conflating:

1. provenance of a provisional commercial observation — what terms were shown, when, and from which source; and
2. authority to bind those terms — which the provisional observation may not have at all.

The issuer / authorized_by distinction can represent different provenance and authority parties. The gap in the current harness is different: it assumes the artifact presented at the binding boundary is an accepted/awarded, authority-bearing artifact. Your lodging example suggests another semantic class—an authentic, attributable observation that is intentionally non-binding.

The question I’d test from your example is: should the handoff carry the actual provisional observation the buyer saw—price/policy plus enough source/time identity to compare it with the Business-authoritative session—or is the intent that only the room/rate identifiers cross that boundary?

If it is the former, that seems like a distinct provenance case rather than another Business-authorized quote case, and it would let us represent the price-accuracy delta without implying that the discovery source had authority over the Business.

[sanj-directbooker]

should the handoff carry the actual provisional observation the buyer

saw—price/policy plus enough source/time identity to compare it with the Business-authoritative session

or only the room/rate identifiers cross that boundary

The former is what I would recommend. My rationale here is that providing only the room/rate identifiers leaves open the bait-and-switch dynamics we've seen to date. They may be less annoying to Agents than to humans, but if we have an opportunity to design them out, I believe we should attempt to do so.

…

On Sun, Sep 13, 2026 at 9:10 PM Arjun ***@***.***> wrote: This is a useful third case, and I think it exposes a boundary slightly earlier than the accepted-term handoff we’ve been modeling. In the lodging flow, room_rate.id or room_type.id + rate_plan.id + itinerary tells the Business what to evaluate, but it does not identify the actual provisional price/policy the buyer saw. The Business then authoritatively validates inventory and restates/recomputes the commercial terms when the booking session is created. So I think there are two separate things we should avoid conflating: 1. provenance of a provisional commercial observation — what terms were shown, when, and by/source from whom; and 2. authority to bind those terms — which the provisional observation may not have at all. Our current issuer / authorized_by split helps with the second question, but the harness is still built around artifacts presented for binding. A third-party lodging quote may instead be authentic and attributable while remaining entirely non-binding. The question I’d test from your example is: should the handoff carry the actual provisional observation the buyer saw—price/policy plus enough source/time identity to compare it with the Business-authoritative session—or is the intent that only the room/rate identifiers cross that boundary? If it is the former, that seems like a distinct provenance case rather than another Business-authorized quote case, and it would also give us a way to represent the price-accuracy delta without implying that the discovery party had authority over the Business. — Reply to this email directly, view it on GitHub <#812?email_source=notifications&email_token=BKCATR6PFRD2Y7KJNE6UQAL5O5AQ5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUGI3TGMRSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18427322>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKCATR7N4KRZYEHCNWY5PSD5O5AQ5AVCNFSNUABJKJSXA33TNF2G64TZHMYTCMRVGU4TCOBUGE5UI2LTMN2XG43JN5XDWMJQG43TCNRYGOQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BKCATRZL7IGKTIDC64U6AYT5O5AQ5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUGI3TGMRSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/BKCATR5TWQGJHRRYM6AMZYT5O5AQ5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUGI3TGMRSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: <Universal-Commerce-Protocol/ucp/repo-discussions/812/comments/18427322@ github.com>

[arjun2075]

That clarifies it. I agree the useful object here is the provisional commercial observation itself, not just the lodging identifiers.

I’d keep its semantics deliberately weaker than an accepted-term artifact: it can preserve what was shown, its source/provenance, observation time, commercial scope, price/policy terms, and any stated validity — but it carries no implied authority over the Business. Any buyer acceptance or authorization would need to be explicit and would not by itself turn the observation into a Business commitment.

Then the Business-authoritative booking session can be compared against that observation explicitly. A price/policy change becomes an attributable delta rather than the earlier terms simply disappearing at session creation.

One distinction I’d keep separate is observation from enforcement: preserving the provisional terms makes bait-and-switch detectable, but the protocol would still need an explicit policy if a Platform is expected to block, warn, re-confirm, or otherwise react to a material delta.

I’ll model this as a separate provenance vector after the current accepted-term PR review, rather than folding it into the binding-authority cases.

[westonale]

Read PR #1 at 4882bfde. All three choices move the right way, and each has one case the evaluator does not handle yet. In your order:

1. The exclusive boundary is right. Late observation needs a finality point. Nothing bounds how late an earlier verified event can arrive, so the disposition applied at the deadline is never final. V13 with deemed_acceptance_to_business, evaluated at the deadline with nothing resolved, reports executed. Add a failed delivery resolved at 2026-09-19T12:00Z, evaluate again on 09-21, and the same transaction reports release_condition_failed, after the deemed acceptance already released value toward the Business. return_to_buyer has the mirror case with a late satisfied delivery. There are two ways to close it. Either the disposition waits for an evidence cutoff after the deadline, so the deadline governs when the event must happen and the cutoff governs when its evidence must arrive, or the first terminal outcome is final and a verified event that arrives later opens a claim against value that already moved instead of re-evaluating the transaction. The second is how a dispute window works. Either way lifecycle() needs to know whether a disposition was already applied, since today it evaluates a snapshot at attempt.at.

2. The authorization limits hold. The repricing guard compares against the wrong price. Attempt history records that a unit bound, not the price it bound at, so the check compares the tier price with the artifact's list price. That misfires in both directions. Replay V12 against the four history entries its own result implies (U1 to U3 bound, U4 line_unavailable, same attempt ids): L01 to L03 already sit at 1200, 1200 is not the list price, and the replay returns prior_bound_adjustment_requires_transition instead of partially_bound, so the I19 replay property fails on the vector that introduced the tier. In the other direction, a fresh attempt that restocks U4 leaves failed empty, the contraction branch never runs, and effective_unit_prices reports L01 to L03 at 1000 with no transition. Recording the bound price on each history entry, and running the comparison whenever already-bound units are in the result rather than only when lines failed, fixes both. On your question: yes, keep it a separate result, though it needs no new authorization, because the accepted table already sets 1000 once four units bind. It changes what is owed on scope that already bound, so it belongs in an explicit adjustment against U1 to U3 rather than in a changed effective price.

3. The classes are right for the unit reasons, but the class should follow who has to act. A per-unit idempotency_conflict falls through to new_authorized_transition, yet it means the caller reused an attempt id for different content. A new revision cannot fix that, since the reused id conflicts again at revision 5; only a new attempt id does. Request-level failures also carry no retry class at all: attempt_history_unavailable returns invalid_artifact, so a Business that cannot read its own attempt history looks to the platform like a defective artifact, when a store that is only temporarily unreachable calls for the same attempt, later. That gives the retry class four owners rather than a transient and structural pair: the caller (new attempt id), Business state (new attempt), Business availability (same attempt, later) and the authorization (new transition).

[arjun2075]

Weston — I pushed the follow-up to PR #1 at e7dd449c.

I addressed the three cases from your review:

1. Deadline finality: the first applied terminal outcome is now persisted and replayed. Late contradictory evidence cannot re-evaluate the original transaction; it would belong to a separate claim/correction path. I also tightened this so a deadline disposition cannot claim an applied_at before the governing deadline.

2. Previously bound commercial basis: successful history now records the effective basis actually bound. V12 therefore replays U1–U3 at 1200 rather than comparing against the artifact's 1000 list price. If U4 later binds and the accepted four-unit tier selects 1000, the result emits explicit 1200→1000 adjustments against U1–U3 under the already accepted tier rather than silently rewriting their history or requiring a new revision.

3. Recovery ownership: idempotency_conflict now requires a new attempt id under the same valid revision; line_unavailable permits a fresh attempt; temporary attempt-history unavailability permits the same attempt later; and structural/authorization failures require a new authorized transition.

I also changed the initial deadline tests so they clear persisted terminal state and exercise the deadline calculation itself.

The PR now reports 70/70 tests with V1–V7 still byte-for-byte unchanged.

Could you take another look at those three closures, particularly whether the explicit adjustment representation preserves the distinction you had in mind between existing authorization and a separate economic adjustment?

[westonale]

Read e7dd449c. The adjustment has the right shape: bind-time prices stay in history, the accepted tier produces a separate record with the previous and new basis, and a change the table does not cover fails instead of becoming a new effective price. That distinction holds for the request that emits the adjustment. It does not survive the next evaluation, because nothing records that the adjustment was applied.

Take the restock request from test_restock_surfaces_accepted_tier_adjustments and replay it after recording U4's bind at 1000, with U1 to U3 left at 1200 as the PR intends. All four units come back already_bound and prior_units has four members, so the prior authorized price is 1000. L01's recorded 1200 matches neither the new price nor the prior one, and the request that just returned bound with three authorized adjustments now returns prior_bound_adjustment_requires_transition as invalid_artifact.

It also fails a later bind that reprices nothing. Add a 2-unit row at 1100, and bind the units one at a time by presenting all four each request with the rest marked unavailable. When U2 binds, count reaches 2 and L01 is adjusted 1200 to 1100. When U3 binds, count is 3, the tier is still 1100, so nothing new is repriced, yet the request fails: L01 is still recorded at 1200 while the authorized price for two prior units is now 1100. In both cases the comparison reads the bind-time price where it needs the current basis, the bind-time price plus the adjustments already applied.

Recording each applied adjustment as its own history entry closes both, as long as the entry carries what caused it: the triggering attempt id, the tier row applied, and the revision. The evaluator then compares the current basis with the prior authorized price, a replay recognizes an adjustment it already applied instead of rejecting or re-emitting it, and a consumer can deduplicate. History is never rewritten, and after the fact an adjustment stays distinguishable from a new authorized transition, which is the distinction you asked about.

Two smaller points:

1. terminal_outcome is replayed but never checked against the accepted pending_at_deadline. V13 declares return_to_buyer; change its record to report deemed_acceptance_to_business as executed and lifecycle() returns it. And once a record exists, contradicting earlier evidence returns the same answer as no evidence, so nothing tells a caller that the correction path applies.
2. commercial_basis_history_unavailable means history is missing, not that the artifact is defective, but it returns invalid_artifact with new_authorized_transition. That contradicts the rule that missing authoritative history fails closed without calling the artifact invalid, and it is the same case as attempt_history_unavailable.

[arjun2075]

Thanks — I pushed a follow-up in 31e11d59 addressing these cases.

Accepted commercial-basis adjustments are now persisted as append-only history. Bind-time prices remain unchanged; subsequent evaluation derives the current basis from the bind-time price plus the applied adjustment chain.

That fixes both adjustment cases you described:

• replay after the 1200→1000 adjustment recognizes that the adjustment was already applied instead of returning prior_bound_adjustment_requires_transition;
• a later bind while the active tier remains 1100 derives the current basis as 1100, so it neither reprices nor fails.

Each adjustment records the artifact/line, previous and new basis, triggering attempt, tier row, and revision. Replay uses one canonical identity for those fields, so an already-applied adjustment is not emitted or persisted again. The basis derivation also validates each link against the running basis; inconsistent or reordered adjustment history fails closed rather than producing an effective price.

I also addressed the two smaller points:

• terminal_outcome is now checked against the disposition authorized by the accepted pending_at_deadline. A contradictory record is not replayed; it returns the existing post_bind_invalidated status with terminal_outcome_conflicts_with_accepted_disposition. This keeps the contradiction distinct without adding an in-harness correction workflow.
• commercial_basis_history_unavailable now follows the same fail-closed semantics as attempt_history_unavailable: unavailable authoritative history does not make the artifact invalid and does not imply a new authorized transition.

Validation is now 82/82 tests, 14/14 vectors, unchanged V1–V7 hash guards, and clean git diff --check.

[westonale]

Read 31e11d59. Both adjustment traces now pass, and deriving the current basis from bind-time prices plus the applied chain is the right model. The terminal outcome check accepts on the label rather than the outcome.

The conflict check runs only when the record's reason is one of the two deadline dispositions and a release condition exists, and it then compares only the reason, so three records replay as executed:

• V13 with its record changed to status: executed and executed: true, reason still return_to_buyer, replays as executed. Without the record, V13 returns deadline_non_execution.
• A record with reason release_condition_satisfied, executed, and no release evidence skips both checks and replays as executed.
• V8 has no release condition, so authorized_deadline_disposition returns None and nothing is compared. A deemed_acceptance_to_business record applied at V8's deadline replays as executed, where without it an attempt after the deadline with no active invalidation returns execution_deadline_elapsed.

invariants.md says the persisted record is validated against the authorized disposition, and it is, by its reason. What is not checked is that status and executed are consistent with what that disposition means: return_to_buyer is a non-execution, so a record labelled return_to_buyer carrying executed: true should be the conflict, not a replay. And when no disposition is authorized, a deadline-disposition record has nothing to match against and replays unchecked. Comparing the structured fields against the disposition, and treating any terminal record the evidence does not authorize as the conflict, closes all three.

Smaller: a broken or reordered adjustment chain returns commercial_basis_history_unavailable, whose recovery is same_attempt_later. Corrupted append-only history will not recover by waiting, and a contradictory bind record already returns invalid_artifact_semantics; a broken chain is the same kind of fact.

[arjun2075]

Thanks — your three terminal-outcome cases were valid, and the broken-chain recovery point was valid as well. I ended up tightening both areas beyond the individual reproductions rather than special-casing the vectors.

The current implementation is in 1dd6d5b.

Terminal outcome replay

The persisted terminal record is no longer accepted on its reason label alone.

Replay now validates the complete semantic outcome:

• status
• reason
• executed
• terms_preserved

against the terminal class permitted by the accepted policy and the record's timing.

That closes the cases you identified:

• V13 cannot carry reason: return_to_buyer with an executed shape; the semantic fields conflict even though the label matches.
• A deadline disposition cannot replay when the accepted policy authorizes no such disposition, including the V8 case.
• A release terminal result cannot be represented by only release_condition_satisfied / release_condition_failed; those classes require persisted release authorization provenance.
• Unsupported or diagnostic lifecycle reasons cannot become terminal history.
• Declared invalidation-condition names are required to be disjoint from the lifecycle-reason namespace, so a condition such as executed cannot be interpreted as one class on first evaluation and another on replay.

For release finality, I added a minimal release_authorization_basis to the persisted terminal record. It stores the release result and event time used when the terminal outcome is applied. First application still evaluates the authoritative release evidence; replay validates the persisted basis, accepted policy and application timing instead of re-reading a later execution_attempt.

That means a legitimate terminal result is final across later attempt-state drift: disappearing or contradictory fields in a later attempt do not retroactively re-decide the historical result.

Transient evaluator results are also explicitly outside terminal history. Things such as binding_not_successful, transaction_mismatch, invalid timing/evidence, release_condition_pending, and the terminal-conflict verdict itself are neither emitted by the persistence helper nor accepted if injected directly as persisted terminal state.

There is one trust boundary worth stating explicitly. The terminal record and its release basis are trusted Business-store history; the basis is not separately authenticated from the record carrying it. Replay detects internal, policy and timing contradictions, but it cannot detect coherent replacement of the entire trusted record plus its provenance. Also, resolved_at is event time, not evidence-observation time, so the harness proves the cited event occurs no later than application; it does not prove when that evidence became observable.

Commercial-basis history

I also changed the broken-chain behavior you called out.

commercial_basis_history_unavailable is now reserved for the case where authoritative history genuinely cannot be obtained. That remains retryable.

If the history is available but internally inconsistent, it is structural invalidity and returns invalid_artifact_semantics. Waiting cannot repair immutable contradictory history.

The current basis is still derived from immutable bind-time prices plus the accepted append-only adjustment chain; bind-time prices themselves are not rewritten.

The history validation is now independent of whether the current request happens to replay as already_bound, stale, rejected, or idempotency-conflicting. A bad current request can neither hide corrupt persisted history nor make valid persisted history corrupt.

For each artifact revision, persisted adjustments are validated in recorded order against authoritative successful-bound history. Among other things, the validator now checks:

• the adjusted line has an authoritative bind-time basis;
• the record is not a no-op;
• previous_unit_price matches the running predecessor basis;
• authorization_source is the accepted unit-count tier mechanism;
• effective_unit_count >= 2;
• the recorded count does not exceed the union of validated historical effective units and units legitimately effective in the current evaluation;
• recorded counts do not move backward;
• accepted tier thresholds are unique;
• the recorded count selects the recorded highest eligible tier;
• that tier authorizes new_unit_price;
• the trigger is either a validated historical successful binding attempt or the exact in-flight attempt the producer would select for the current partial transition;
• the trigger's binding-unit membership, lines and target transaction are consistent with the accepted binding authorization;
• one trigger cannot claim multiple transition contexts, and one effective transition count cannot claim multiple triggers;
• same-revision history cannot refer to orphan bound scope;
• other revisions remain outside the current chain.

Successful bound records used as authoritative history are also validated before they can contribute basis/count/trigger state, including an exact match between line_ids and the keys in effective_unit_prices. Raw history can still establish that an attempt ID is already occupied for idempotency purposes, but a malformed collision record is not thereby promoted to authoritative successful-bound history.

Adjustment replay keeps the idempotency key separate from the payload. An already-applied identity suppresses re-emission only when the persisted effect and transition provenance match the transition being replayed. For later adjustments in a chain, that comparison uses the basis immediately preceding that record — e.g. 1100 -> 1000, not the original 1200 bind-time price and not the final derived price.

There is a narrower remaining trust boundary on historical adjustment triggers: attempt history does not retain ordering, so among otherwise structurally compatible successful historical attempts the harness cannot independently prove which one occurred at the exact transition count. Membership, lines, target, successful status, count, tier, price, source and cross-record context are checked; historical ordering itself is not reconstructed.

Validation

Current validation is:

• 190/190 tests
• 14/14 vectors
• 16/16 JSON files
• unchanged V1–V7 hash guards
• unchanged matrix output
• clean git diff --check

No vector or golden value changed.

Thanks for pushing on the distinction between a matching disposition label and an actually authorized persisted outcome. That ended up exposing the broader replay/history issue, and the implementation is now checking the structured historical state rather than relying on labels or the current request to reconstruct it.