Bind MCP Tasks and authenticated callbacks into cMCP evidence

Define how task creation, updates, cancellation, callbacks, and terminal results bind to one cMCP call graph and policy context. Acceptance evidence: replay and out-of-order callback tests; cancellation-authority checks; terminal result binding; documented limits for delivery and completion claims.

One additional boundary from final SEP-2663 may be useful alongside the identity/authority boundary already called out for #567 on #565.

The Tasks lifecycle gives deliberately different evidentiary strength to different successful responses:

Task creation: a server MUST NOT return CreateTaskResult until the task is durably created and a subsequent tasks/get for that taskId would resolve.
Task update: success is an empty acknowledgement and is explicitly eventually consistent. The acknowledgement may precede any observable state change, and input for unknown, already-satisfied, or superseded request keys may be ignored.
Task cancellation: success is also an empty acknowledgement, but cancellation is cooperative. The request signals cancellation intent; the acknowledgement does not establish that cancellation took effect, and the task may legitimately reach a terminal state other than cancelled.

That suggests a separate evidence rule for the task lifecycle:

The evidentiary strength assigned to a protocol response should not exceed the lifecycle guarantee that the protocol actually gives that response.

Or, for the two control methods:

request acknowledgement ≠ applied state transition ≠ terminal task outcome

The creation path is a useful positive control because SEP-2663 intentionally gives its response a stronger guarantee: durable task existence has already been established before the response is returned.

A small differential set could therefore be:

CreateTaskResult returned → the task already resolves through tasks/get;
tasks/update acknowledged → the acknowledgement alone does not establish input consumption or an observable state transition;
an already-satisfied or superseded input key may produce the same successful acknowledgement while being ignored;
valid case: tasks/cancel acknowledged → task later reaches cancelled;
contrasting valid case: the same cancellation acknowledgement → task legitimately reaches another terminal state because cancellation did not take effect before completion.

For evidence, that seems to argue for keeping at least:

control request issued
control request acknowledged
state transition observed
terminal state established
external effect evidenced, if separately available

independently attributable, so that evidence at one lifecycle layer cannot silently stand in for a stronger claim at the next.

Retain the lifecycle evidence distinction raised above: request acknowledgement, observed state change, and terminal outcome are separate claims. The next step is the task/callback evidence design and its acceptance matrix, coordinated with #565 and #568.

@solloek369-arch

The two threads this was coordinated with are now ruled, so this is unblocked. Recording what the matrix inherits rather than leaving it to be rediscovered.

From #568, ruled today

Each negative case names which boundary failed. Collapsing authentication, delegated authorization, proof-of-possession and attestation into one generic identity error destroys the only information a relying party can act on. The same applies here: a task failure that does not say whether creation, delivery, authority or the terminal outcome is what failed supports no response.

From #566, ruled today

Every refusal in the matrix needs a conformant twin that forces the condition being tested. A set composed only of negatives is satisfied by an implementation that refuses everything, and that implementation scores identically to a correct one. For Tasks the obvious positive control is a well-formed cancellation that is honoured, sitting beside the cancellation that is acknowledged and then does not take effect.

Ruling the lifecycle claims, since it is the same distinction one level down

@solloek369-arch's SEP-2663 reading is the shape the evidence has to take. Three successful responses, three different strengths, and they are separate claims rather than three spellings of "ok":

Creation. A server must not return CreateTaskResult until the task is durably created and a subsequent tasks/get would resolve it. This one does establish state, and it is the only one of the three that does.
Update acknowledgement. Explicitly eventually consistent. It may precede any observable state change, and input for unknown, already-satisfied or superseded request keys may be ignored. So it establishes that the request was accepted for processing and nothing about the processing.
Cancellation acknowledgement. Cooperative. It signals intent. It does not establish that cancellation took effect, and the task may legitimately reach a terminal state other than cancelled.

So the evidence records the acknowledgement and the observed outcome as separate fields, never one. An acknowledgement written into a field a reader will interpret as an outcome is the failure mode here, and it is the same one as reporting a malformed decision as a signed denial, or an unread catalog page as a catalog change.

A cancellation that was acknowledged and then did not take effect is not a defect in the record. It is the true state of the world, and the record has to be able to say it.

Current-state ceiling first: read against cMCP main 0db343a901adbddff536359daa30e4d506203e42, cMCP still does not implement the Tasks methods, task storage, notifications/tasks, or a Tasks-specific authenticated callback/webhook evidence path. This is an evidence-contract proposal for review, not a runtime implementation or conformance claim.

task_evidence
├── evidence_profile + protocol_profile
├── task_anchor
│   ├── task_id
│   ├── originating_audit_entry_commitment
│   ├── originating_call_id
│   ├── originating_execution_id: string | null
│   └── originating_request_commitment
├── records[]       {record_id, kind, subject_task_id?, observed_at,
│                    ingest_index, source_evidence, source_order?,
│                    claimed_policy_context_ref?, data}
└── assessments[]   {assessment_id, subject_record_id, boundary,
                     disposition, applicable_at, evaluated_at, evaluator_ref,
                     basis_citations[], related_record_ids?, reason_code?,
                     result_code?}

The anchor fields are claimed projections. Positive origin and execution-correlation assessments must resolve them against the exact committed originating AuditEntry under the same independently established authenticated-agent scope. call_id identifies one attempt; the same non-null execution_id across relevant committed entries supplies correlation only. Null remains null. Task, attempt, execution correlation, logical action and external outcome remain distinct; logical-operation sameness additionally needs the immutable action/intent binding required by #574 and defined in #588/#627. When execution correlation is unavailable, its required assessment is NOT_ESTABLISHED, not omitted.

The candidate record union contains:

task_creation_result_observed
control_request_issued
protocol_acknowledgement_observed
protocol_error_response_observed
delivery_observed
task_state_observed

These kinds keep creation result, control request, acknowledgement, protocol error, receiver-side delivery and later task state distinct. A protocol-error record commits the exact outer response and preserves its typed response ID when present. Without a bound request occurrence, operation and protocol_error_binding remain NOT_ESTABLISHED. It is not a terminal task_state=failed, proof of the failed authority boundary, or proof that no effect occurred. Every protocol_error_response_observed requires a protocol_error_binding assessment; an absent or unbound response ID leaves it NOT_ESTABLISHED rather than erasing the obligation. This task-anchored envelope covers post-creation operation errors; pre-creation errors remain call/request evidence unless a request-anchored envelope is adopted.

Records are append-only. Conflicting independently established terminal observations remain visible; ingest order supplies no precedence without an authorized rule. Local observed_at and ingest_index preserve receiver-side arrival only, not producer event identity/order, replay or currentness.

Assessment boundaries remain distinct: creation durability; task/call/execution/acknowledgement/protocol-error binding; requested condition versus subscription honour; control-request authority; delivery binding/authentication/authority/replay/order/integrity; policy-context/terminal-result binding. The #568 boundaries remain separate; none collapses into delivery authority or execution correlation. An assessment using committed evidence cites exact in-envelope record/anchor operands and commitment slots; names, pointers or copied digests self-prove neither relation nor authority. evaluator_ref identifies, but neither authenticates nor authorizes, its evaluator.

The relying party pins evidence_profile, constraining protocol_profile and required assessments per record kind. Missing/partial evidence may remain NOT_ESTABLISHED; unavailable required evidence records it explicitly; omission is profile-incomplete. VERIFIED_CONTRADICTION requires a boundary-specific evaluator to establish an actual mismatch between eligible, comparable, correctly bound evidence; absence/non-comparability remains NOT_ESTABLISHED.

One concrete reason this split is load-bearing appears in Tasks io.modelcontextprotocol/tasks@2026-07-28: UpdateTaskResult and CancelTaskResult both permit the same empty successful result, {"resultType":"complete"}. Response bytes therefore cannot select their own operation. protocol_acknowledgement_observed.data.operation must come from an independently bound request occurrence. Typed request/response ID mismatch can contradict the asserted pair, while equality alone is insufficient when an ID may have been reused and complete exchange scope is not established.

For callbacks, delivery_observed records only the receiver-side observation of exact bytes. It does not establish sender authentication, authority, task binding, payload truth or task outcome. Likewise, a terminal task result does not establish an external effect; external_effect stays outside this bounded core.

Candidate names and details remain open, including callback authentication/authority, terminal-result verification, and originating AuditEntry representation.

Is this split between typed historical observations and independently evaluated relations the right structural direction for #567? If so, I will follow with the bounded acceptance matrix and its conformant positive twins.

@solloek369-arch

@solloek369-arch, proceed with the bounded acceptance matrix. Keep typed observations separate from independently evaluated relations; field names remain provisional.

Include paired cases for update versus cancellation acknowledgements, reused request IDs, replayed or out-of-order deliveries, and authorized versus unauthorized cancellation. Preserve conflicting terminal observations. An acknowledgement must never establish completion or an external effect.

Make profile completeness testable: an explicit NOT_ESTABLISHED assessment and an omitted required assessment must produce distinguishable results. Each case should identify its evidence, trust assumptions and expected boundary result.

This approves the direction for the matrix. Callback authentication, terminal-result verification and the final claim representation remain open.

@imran-siddique

@imran-siddique
Thank you :D!

Here is the bounded acceptance-matrix proposal as agreed. As far as I can tell, this captures the current rulings while keeping the still-open points open.

Typed observations remain separate from independently evaluated relations. NOT_ESTABLISHED differs from verified contradiction, and an explicit required NOT_ESTABLISHED assessment differs from an omitted assessment. Acknowledgement, later observed state, terminal-result verification and external effect remain separate claims.

I reused existing lifecycle, binding, replay, ordering and completeness distinctions where they already covered a boundary; additions are limited to gaps from the current ruling and the September 13 field shape.

Each group states its evidence, trust assumption and expected boundary result. These are conditional oracles: when a case supplies the stated independently verified evidence under an applicable trusted profile, its corresponding positive or contradictory disposition is required. Returning NOT_ESTABLISHED for every case does not satisfy this matrix. This does not adopt a verifier.

Every terminal observation below is preserved with terminal_result_binding = NOT_ESTABLISHED, because terminal-result verification remains open.

Group	Contrast / evidence	Trust assumption	Expected boundary result / claim limit
AM-01 · Creation	Exact CreateTaskResult versus a generic successful CallResult offered for the same creation claim.	The exact source and result type are bound, and the applicable creation contract is trusted.	Under that contract, the real creation result establishes durable creation and subsequent tasks/get resolvability at return. The generic result cannot establish that claim. Neither establishes later completion or effect.
AM-02 · Acknowledgements	Update and cancellation requests each independently bound to an exact response occurrence with the same successful form, {"resultType":"complete"}.	The applicable exchange-scope evidence identifies the exact request/response occurrence; matching result bytes or ID text alone do not.	Operation comes from the independently bound request, not the response bytes. Once the successful response is independently bound to an update request, the protocol guarantee is that the request was accepted for processing; it establishes nothing about the processing itself, input consumption, or an observable state change. A cancellation acknowledgement signals intent and does not establish that cancellation took effect. Neither acknowledgement establishes completion or external effect.
AM-03 · Cancellation authority	Hold requester, request, acknowledgement, task, instant and other applicable independently established authority prerequisites fixed. Vary only authority evidence that includes this cancellation, is missing, or verifiably excludes it.	Cancellation authority is evaluated independently for that requester, task, scope and instant; authentication alone is insufficient.	Authority is respectively ESTABLISHED, NOT_ESTABLISHED, or a VERIFIED_CONTRADICTION of the positive authority claim. Missing evidence is not proof of unauthorized cancellation. Preserve the acknowledgement in all three cases.
AM-04 · Reused IDs	Two actual request occurrences reuse one typed ID. Hold the response, claimed target and eligible occurrence scope fixed; vary only independently verified evidence that disambiguates the exact occurrence.	“Complete eligible scope” means all request occurrences that could match this response are accounted for, not merely the displayed examples. The discriminator is verified independently of ID equality or a local completeness flag.	Without sufficient disambiguation, exact binding is NOT_ESTABLISHED; with it, exact binding is ESTABLISHED. Reuse itself is not failure, and ID equality is not occurrence identity.
AM-05 · Replay	Equal payloads in two preserved receiver observations; independently bound producer-event evidence identifies either distinct events or two deliveries of one event.	Event identity and its binding to the exact event and payload are independently verified; payload equality is not identity evidence.	Preserve both observations and report the evidenced distinct-event or duplicate-delivery relation. Neither equal bytes nor two receipts establish an additional task transition.
AM-06 · Ordering	The same receiver arrival sequence has independently bound, comparable producer/source order that agrees with or reverses ingest order.	Source order is bound to the exact records in a comparable order domain; ingest order is not its evidence.	Both arrival histories can be valid. Report source order separately. Reordering is not replay, and latest ingest supplies neither truth nor precedence.
AM-07 · Requested condition	The same independently bound cancellation request and acknowledgement are followed by an observed cancelled or completed snapshot. The exact request and state operands are independently bound to the same task.	The source observations support that comparison; no causal rule or positive terminal-result verifier is assumed.	For the exact compared snapshot, the requested cancelled condition is ESTABLISHED in the former case and contradicted in the latter. Both histories remain observable. The acknowledgement alone establishes neither state, and the comparison establishes neither causality nor verified terminal truth.
AM-08 · Tool-result flag	Source-faithful observed completed snapshots carry isError:false versus isError:true, retaining exact result commitments and task binding.	The exact task, source and result observations are trusted for what they record; no positive terminal verifier or effect evidence is assumed.	Both remain observed completed. isError:true does not imply task-level failed; isError:false does not establish business success or external effect. Both terminal-result assessments remain NOT_ESTABLISHED.
AM-09 · Conflicting terminals	Preserve separately sourced completed and failed observations independently bound to the same task, their distinct evidence/provenance and both terminal-result assessments.	Each exact source/task observation is retained independently; no authorized resolution rule or positive terminal verifier is assumed.	Both terminal-result assessments remain NOT_ESTABLISHED. Preserve the conflict without deletion or a synthesized winner. Reversing ingest order grants no precedence and establishes no current terminal truth.
AM-10 · Origin / execution	Baseline: exact committed originating AuditEntry and relevant entries, faithful call/request projections, independently established same authenticated-agent scope, and correctly bound non-null execution correlation. Compare three variants, each changing one item: execution unavailable/null; a verifiably comparable wrong originating-call projection; or missing agent-scope evidence.	Exact entry/call/request provenance and, where claimed, same-agent scope are independently verified. Equal ID text cannot replace that evidence.	The baseline conditionally requires established origin and execution correlation. Null preserves origin evidence but requires explicit execution NOT_ESTABLISHED, without a synthesized ID. A proven wrong call projection contradicts the origin claim; execution assessment dependent on that wrong origin join remains NOT_ESTABLISHED, while separately supported entry-to-entry correlation is preserved. Missing agent-scope evidence leaves origin/execution NOT_ESTABLISHED, not proof of another agent. Task identity, call attempt, execution correlation, logical action and effect remain distinct.
AM-11 · Post-creation error	Preserve the exact outer error response. Compare exact independently bound request occurrence; no usable typed response ID; and a typed ID present without independently established occurrence binding.	Positive binding requires sufficient independent exchange-scope and occurrence evidence. No alternative correlation contract repairs the absent-ID variant; the error code itself is not authority, state or effect evidence.	Under the stipulated exact binding, protocol_error_binding is ESTABLISHED. The other two cases require explicit NOT_ESTABLISHED for different reasons; preserve the error and any ID. Its operation follows only from a bound request. Error alone establishes neither task failure, unauthorized cancellation/update, absence of effect nor successful acknowledgement.
AM-12 · Execution completeness	In the task-origin context requiring execution accounting, execution is unavailable/null. Compare an explicit NOT_ESTABLISHED execution assessment with the same observations but that required accounting omitted.	The obligation is fixed by the stated case context, not by the assessments supplied. Presence checking needs no positive execution verifier; the exact subject-record trigger and cardinality remain open.	Explicit uncertainty accounts for this obligation; omission fails its conceptual completeness requirement. This contrast claims no completed mechanical wire-schema check and settles no trigger/cardinality decision.
AM-13 · Protocol-error completeness	A post-creation error has no usable correlation ID. Compare required protocol_error_binding = NOT_ESTABLISHED with the same observation but that assessment omitted.	The error observation requires its binding assessment independently of ID availability; checking presence needs no positive occurrence verifier.	Explicit uncertainty accounts for the obligation; omission is profile incompleteness, not another spelling of NOT_ESTABLISHED.

Listen/subscription acknowledgement is not a separate group in this bounded selection; this does not remove its relation from the broader candidate profile.

These are textual, unexecuted acceptance cases. No fixture PASS or implementation conformance is claimed. Conditional positive expectations depend on the stated independently verified evidence and applicable trusted profile. Fixture implementation follows matrix review.

Callback authentication, terminal-result verification and final claim representation remain open. Field names are provisional; no final wire enum is proposed. Accepting this matrix would not settle those decisions.

One matrix-shape point remains underspecified for a mechanical execution-correlation fixture: execution correlation must be accounted for, including explicit NOT_ESTABLISHED when unavailable or null, but the current sources do not determine its exact subject-record trigger or cardinality. I have left that open rather than inventing it.

Does this bounded matrix capture the distinctions you want frozen before fixtures, while leaving callback authentication, terminal-result verification and final claim representation open?

This captures the intended distinctions. Proceed with fixtures for the settled cases, retaining the stated evidence and trust assumptions. Positive controls must establish their claimed relation; returning NOT_ESTABLISHED everywhere must fail the suite.

Before implementing AM-12’s completeness check, propose the exact trigger, subject record and assessment cardinality. Include cases for an omitted assessment, one attached to the wrong subject, and duplicates. Keep that proposal explicit rather than letting fixture code decide the contract.

In AM-07, keep the verdict scoped to the compared observation. It establishes neither cancellation causality nor verified terminal truth.

Callback authentication, terminal-result verification and the final representation remain open. This accepts the bounded matrix direction, not implementation conformance.

Thanks — I kept AM-12 out of the fixture code as requested. Here is one concrete, bounded contract proposal for your ruling.

Trigger. For the profile proposed here, each task_creation_result_observed record in the declared fixture input requires execution-correlation accounting. The obligation exists independently of whether the execution identity is non-null, null or unavailable, and independently of which assessments are supplied.

Subject record. The subject is that exact task_creation_result_observed record. This is a proposed profile designation, not a requirement I could derive uniquely from the current material. Task-origin contexts without that record are outside this bounded proposal; their accounting is not thereby established or waived.

Evaluation view and cardinality. For this fixture, one evaluation view means one predeclared assessment submission whose complete membership is fixed before the completeness check, independently of assessment outcomes.

For each required subject and execution-correlation boundary, count all submitted assessment instances targeting that subject and boundary. Exactly one eligible assessment must be present under the pinned profile. An explicit NOT_ESTABLISHED assessment satisfies accounting while preserving uncertainty; it does not establish execution correlation.

Differences in timestamp, evaluator or evidence basis do not create separate views or authorize selecting a winner. Repeated assessment IDs are not silently deduplicated, and malformed entries are reported rather than discarded to manufacture a passing count. Historical assessments outside the declared submission remain preserved; this proposes no general supersession rule.

Under that proposal:

Omitted: no assessment for the required subject and boundary leaves the obligation unaccounted for / profile-incomplete. This is not evidence that no execution existed.
Wrong subject: an assessment attached only to another record does not discharge the required subject’s obligation. Preserve it, report the mismatch, and infer no execution contradiction.
Duplicate: more than one assessment targeting the same required subject and boundary within the declared submission is duplicate/ambiguous accounting. Preserve all and select no winner.

This is a completeness proposal only. It does not settle execution verification, final wire fields, callback authentication, terminal-result verification or general historical supersession.

Would you accept this trigger, subject designation and single-submission cardinality as the bounded AM-12 contract before its fixtures are implemented?

@solloek369-arch

@solloek369-arch, proceed with this as the bounded AM-12 fixture contract. Each task_creation_result_observed record requires exactly one eligible execution-correlation assessment in the predeclared submission, attached to that exact record. Explicit NOT_ESTABLISHED satisfies accounting without establishing execution.

Test omission, wrong subject, duplicates and malformed entries, including one valid assessment alongside a malformed duplicate. Do not filter or deduplicate the submission into a passing count. Keep a valid control and show that weakening subject binding or cardinality makes the relevant tests fail.

Keep the scope limitation explicit: contexts without a creation-result observation are outside this contract. This does not establish runtime completeness or settle callback authentication, terminal-result verification, historical supersession or final wire fields.

@imran-siddique

@imran-siddique

Thanks, the bounded #567 fixtures you asked me to proceed with are complete locally. They passed independent review and a byte-exact replay against main at 2e624221322b4eba0d2f008a0f88a27347b8aa7b: 112/112 focused tests, including AM-01 10/10, AM-10 29/29 and AM-12 27/27. All seven specified mutants were killed and restored byte-exactly. No production files changed.

These are conditional fixture oracles only. They do not establish live Tasks support, callback authentication, terminal-result verification, external effect, or final wire representation.

solloek369-arch is not yet listed in .github/VOUCHED on the dedicated vouched branch. The first-contributor check closes PRs from unlisted accounts unless they have repository write access. Could you /vouch @solloek369-arch here? I can then prepare the smallest test-only landing diff, with the receipt and README updated for this replay.

@solloek369-arch

/vouch @solloek369-arch

Go ahead with the test-only landing diff.

Usage: /vouch @username, one account per comment.

@solloek369-arch

/vouch @solloek369-arch

@solloek369-arch

@solloek369-arch is vouched by @imran-siddique. Pull requests from that account will not be closed by the vouch check.

chore: vouch solloek369-arch

test: add bounded task/callback evidence fixtures for agentrust-io#567

test: add bounded task/callback evidence fixtures for #567 (#701)

Navigation Menu

Repository navigation

Bind MCP Tasks and authenticated callbacks into cMCP evidence #567

From #568, ruled today

From #566, ruled today

Ruling the lifecycle claims, since it is the same distinction one level down

Next

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Bind MCP Tasks and authenticated callbacks into cMCP evidence #567

Description

Activity

solloek369-arch commented on Aug 28, 2026

imran-siddique commented on Sep 7, 2026

imran-siddique commented on Sep 11, 2026

From #568, ruled today

From #566, ruled today

Ruling the lifecycle claims, since it is the same distinction one level down

Next

solloek369-arch commented on Sep 12, 2026

solloek369-arch commented on Sep 13, 2026

imran-siddique commented on Sep 24, 2026

solloek369-arch commented on Sep 24, 2026

imran-siddique commented on Sep 24, 2026

solloek369-arch commented on Sep 24, 2026

imran-siddique commented on Sep 25, 2026

solloek369-arch commented on Sep 26, 2026

imran-siddique commented on Sep 29, 2026

github-actions commented on Sep 29, 2026

imran-siddique commented on Sep 29, 2026

github-actions commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions