Task-level identity across multiple mandate chains: documented stance and linkage artifact?

[archerII]

Follow-up to #258 (cumulative state across mandate fulfilments) and #207 (cross-merchant budget enforcement), also related to the budget-field proposal in #133. Those threads establish that per-task cumulative caps are not carried by the protocol today and that enforcement location is topology-dependent. I'd like to ask the piece I don't think has been answered yet: task identity.

Concrete scenario (heterogeneous rather than repeated purchases): a user authorizes "buy me a phone, total cost under 350,000 HUF." The agent buys the phone for 348,500 (chain 1), then — because the box ships without a charger and the deadline matters — buys a charger for 4,990 at the same or another merchant (chain 2). Each Cart/Payment Mandate chain is individually well-formed and within any per-transaction constraint; jointly they exceed what the user meant by "total." Unlike the groceries example in #258, the two purchases are different line items serving one user-level task, potentially across different merchants.

Three questions:

1. Documented stance: is cumulative/task-level constraint evaluation intentionally out of scope for AP2 (as Cumulative state across mandate fulfilments -- where does it live? #258's operational discussion suggests), and is that boundary recorded anywhere in the spec or docs — or is it currently just implied by silence?

2. Task linkage: is there a defined identifier or artifact that lets a verifier associate multiple mandate chains with a single user-level task or Intent Mandate? Put differently: is the intended cardinality one Intent Mandate per task, per merchant, or per session? If one task legitimately spans several chains, is intent_mandate_id reuse across chains valid and meaningful to verifiers, or would each chain typically carry its own Intent Mandate?

3. If downstream by design: would an informative convention for task-level linkage (a join key, as sketched in the Cumulative state across mandate fulfilments -- where does it live? #258 comment thread) be in scope for the sample docs, so that orchestrators and verifiers converge on the same association rule instead of inventing incompatible ones?

Motivation: I'm evaluating what a task-level orchestration layer must provide on top of AP2 versus what it can expect from the protocol. "Total cost of the task" is how users state budgets, so understanding whether task identity is representable inside AP2 — or explicitly the orchestrator's job — shapes the design either way. Either answer is useful.

[chopmob-cloud]

Same vantage point as my note on #304: merchant-side resource gate, not the shopping agent.

There is no task-level identifier anywhere in what we handle. CartMandate.request_id is generated per resource check and does not survive or link across calls; nothing in the PaymentMandate we verify carries a task or intent reference either. Two purchases against the same gate, five minutes apart, are two completely independent checks as far as the protocol payload is concerned.

That is a real data point for your question 1: at least on the production side I can speak to, cumulative/task-level constraint evaluation is not something the mandate artifacts carry today, which matches the "intentionally out of scope, currently just implied by silence" read rather than there being a hidden mechanism I am missing.

For question 2, if intent_mandate_id reuse across chains became the convention, the gate as built would not object (it does not read or validate that field at all), but it also would not enforce anything from it. Any cumulative check would have to happen entirely on the orchestrator's side, tracking its own running total across however many CartMandate/PaymentMandate pairs it issues under one user task, since nothing arriving at the gate names the task.

If a join-key convention does get written up for the sample docs, I would just flag that it needs to work for implementations like this one that verify mandates but do not currently look at (or store) anything task-scoped, so the convention should not assume every verifier is also the task owner.

[send21io]

Useful framing from the merchant-gate side in this thread: if the artifacts do not carry a task join key, cumulative "total for this job" is an orchestrator concern, not something verifiers can invent from silence.

One adjacent split we keep seeing in agent payment tooling: who may create a payment artifact vs who may bind spend. In our lane (non-custodial drafts), an agent can mint a draft with a scoped key that cannot spend; the human wallet signature is what binds that specific payload. That does not give you cross-chain task identity either — each signed draft is still one discrete authorization — but it does keep "task budget" and "this payment is authorized" as separate layers, which matches the orchestrator-owns-cumulative-state read here.

If a join-key convention does land in the sample docs, agreeing that verifiers need not store task scope (as chopmob-cloud notes) seems like the right default.