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)

@solloek369-arch

#701 landed on 30 September as b769e17: nine test-only files under tests/unit/task_evidence567/, 112 tests, and seven mutations that each fail a named assertion. No production code changed, so this stays open.

Still uncovered from the acceptance list: callback authentication and cancellation authority, replay and out-of-order callbacks, and terminal-result binding. @solloek369-arch if you want the next slice, I would take callback authentication and cancellation authority, with the bounded matrix posted here before code, as #701 was.

@imran-siddique

@imran-siddique Yes, thank you. I’ll take the slice and congrats on your move 🙏.

Below is a bounded, conditional matrix for review before fixture code. No production, wire-format or conformance change is proposed.

Coverage gap. In #701’s AM-03, authentication and request provenance are fixture premises. requester, task, scope and instant are supplied fixture values; the method guard precedes the fixed task_cancel action passed to Cedar. The fixture therefore tests policy applicability, not the independent provenance of those operands.

Smallest proposed control. Under an identity/Cedar profile, keep the operands and matching permit unchanged. Supply a valid requester-to-authenticated-principal binding, then remove that binding while leaving authentication itself valid. With every other required relation E and none contradicted: the raw Cedar decision is permit in both worlds; the requester binding goes E→N; composite cancellation authority goes E→N. An evaluator that reports the missing binding but still establishes authority fails.

Consequence. Policy agreement alone must not establish cancellation authority when a required operand-binding relation is missing. This is a proposed fixture-coverage control, not an executed reproducer or a runtime-defect claim.

Cancellation composition control. For the selected identity/Cedar profile, the positive control must establish composite cancellation authority. In each selected negative, any required relation assessed as NOT_ESTABLISHED—including joint applicability—must make composite cancellation authority NOT_ESTABLISHED when no verified contradiction is present. A Cedar permit cannot override a missing required relation. Assert both the named relation and the composite result.

Conditional matrix

E = ESTABLISHED, N = NOT_ESTABLISHED, C = VERIFIED_CONTRADICTION — #701’s fixture terms, not wire values — each for the named relation, not automatically the whole request.

Each contrast changes one relation while holding the other premises fixed. Missing, unverifiable or inapplicable evidence gives N. C requires eligible, comparable evidence that actually contradicts the relation.

Case / boundary	Evidence, trust premises and contrast	Expected relation result
CB-01 — delivery source	Fix the trusted verification basis and expected source X outside delivery D. Compare authenticated evidence binding X to D, missing/unverifiable evidence, and eligible same-D evidence establishing an incompatible source under the selected profile.	E / N / C. A failed signature alone is N.
CB-02 — delivered bytes	Require an authentic commitment independently bound to D and comparable with its exact delivered bytes. Compare a match, missing or wrong-delivery evidence, and a verified same-D commitment that disagrees with those bytes.	E / N / C. Signature failure alone does not establish a byte contradiction.
CB-03 — delivery→task	Fix the task-membership rule. Compare verified D→T evidence, missing evidence or evidence not covering D, and verified D→U evidence where the profile makes those same-D memberships incompatible.	E / N / conditional C. Matching `taskId` text alone is insufficient.
CB-04 — reporting authority	Fix the applicable reporting policy and its actor/task/context bindings. Compare permission for authenticated X to report about T, missing/inapplicable authority evidence, and an applicable explicit exclusion.	E / N / C. Source authentication can remain E throughout.
CB-05 — subscription acceptance (if A selects native delivery)	Bind an authentic, complete acknowledgement to the selected `subscriptions/listen` exchange. Compare T included in its accepted-task list, missing exchange/acknowledgement binding, and T absent from that complete list.	E / N / C only for “T was accepted in this acknowledgement.” This says nothing about other subscriptions or subscriber authorization.
CB-06 — subscriber authority (if A selects native delivery)	Fix the selected access policy and bind authenticated subscriber S, the listen request and T to applicable authority evidence. Compare permission, missing/inapplicable evidence and an applicable explicit exclusion.	E / N / C. Server authentication and subscription acceptance may remain E throughout; neither substitutes for this relation.
CB-07 — delivery→listen context (if A selects native delivery)	Fix the selected listen exchange L and authenticated subscriber S. Compare D bound to L and S, D with no binding to L, and D bound to another exchange L2 while the acknowledgement and authority evidence for L remain valid.	E / N / N for D’s applicability to L and S. The acknowledgement and subscriber-authority results for L may remain E; they do not carry over to D.
CAN-01 — cancellation operand bindings	Under the selected identity/Cedar component, pin policy documents and trusted context sources. Use separate positive/negative pairs for principal, action, task/resource, scope and evaluation instant. Keep operand values and the permit fixed; remove exactly one required provenance/applicability binding per negative case.	That binding changes E→N and, with the other required relations E and none contradicted, composite cancellation authority changes E→N. A matching permit cannot repair either.
CAN-02 — joint applicability	Using those same trusted sources, compare operand evidence jointly applicable to one cancellation evaluation with individually valid evidence that does not establish a common evaluation context.	E / N for joint applicability. Older evidence remains usable where its scope and validity genuinely cover that evaluation.

Authority evidence states the evaluation context and validity period it covers. Whether a later delivery needs reauthorization is a profile choice, not a requirement inferred from the draft specification.

For cancellation, tasks/cancel supplies params.taskId; the profile must identify the trusted context supplying the other required operands. I would retain AM-03’s distinction between an inapplicable permit and an applicable explicit forbid, and keep acknowledgement separate from completion or external effect.

Every selected negative has a positive twin. An evaluator returning N everywhere must fail those positive controls.

Proposed completeness contract

For your ruling—not an automatic inheritance of AM-12:

Freeze the fixture’s source-record population and required boundary set before assessment. A captured delivery or candidate cancellation-request record triggers its selected obligations independently of whether authentication or binding later succeeds.
Identify the subject by its source-record reference, not by successful authentication or matching taskId text. Callback assessments attach to delivery D; the listen request, acknowledgement and subscriber context are supporting evidence. Cancellation assessments attach to the captured cancellation-request record.
Propose reusing test: add bounded task/callback evidence fixtures for #567 #701’s accounting statuses: per required subject/boundary, count every targeted attempt before eligibility. None is UNACCOUNTED; more than one is AMBIGUOUS_ACCOUNTING; one malformed attempt is MALFORMED_ACCOUNTING; exactly one eligible attempt is ACCOUNTED. No applicable subject is OUTSIDE_BOUNDED_CONTRACT. In the wrong-subject-only control, moving the sole assessment attempt away from its required subject leaves that subject/boundary with no targeted attempts (UNACCOUNTED); the row remains visible in wrong_subject_positions for that subject/boundary.
Explicit N satisfies accounting, not the substantive relation. A valid assessment beside a malformed duplicate does not pass. Preserve unassignable or malformed attempts; do not filter or deduplicate them into apparent completeness.

The frozen population bounds this fixture only. It does not establish that every real delivery or request was captured.

Two profile decisions before code

A — Callback carrier. Should the first fixtures profile native subscriptions/listen delivery, or the webhook route named in cMCP’s docs/spec/mcp-2026-roadmap-impact.md? Which evidence basis should establish the selected relations? One witness may support several relations, but the assertions would remain separate.

B — Cancellation authority. The ext-tasks draft at 7b8e2bd permits task IDs as bearer tokens for a server’s stored state while requiring authentication and authorization for each task-related request. What role should task-ID possession have alongside authenticated-client and context bindings in this first profile? CAN-01/02 conditionally test an identity/Cedar component; they do not presume that component is the universal authorization model.

Source-reading basis: cMCP 19895e49f81aad401f071fd16c3bacee3cc855c4 and the pinned draft above. No new fixtures have been executed. Replay/out-of-order callbacks, terminal-result verification, external effects, Tasks runtime and final wire representation remain outside this slice.

Does this conditional matrix and completeness contract match the slice you want? I would bind the fixtures to your profile ruling before writing code.

@solloek369-arch

@solloek369-arch the matrix and the completeness contract match the slice, including reuse of #701's accounting statuses. Your two decisions:

A. Profile native subscriptions/listen first, against the ext-tasks draft at 7b8e2bd, so CB-05 to CB-07 are in. The webhook route has no wire definition yet, so it waits.

B. A task ID is a lookup key, never authority. Possessing it establishes no relation in CAN-01 or CAN-02; cancellation authority needs the authenticated client and the context bindings, and a matching permit without them stays NOT_ESTABLISHED.

Go ahead with fixture code.

Proposed complementary slice for review: replay, delivery ordering and terminal-result binding. This leaves the approved CB-01–07/CAN-01–02 work with its current owner and adds no runtime or wire representation.

Case	Positive control	Negative / unknown control	Observed obligation
R1 occurrence identity	Independently bound same occurrence delivered twice	Equal bytes with no occurrence binding; distinct bound occurrences with equal bytes	Preserve both receiver records. Classify duplicate/distinct/not-established from occurrence evidence, never payload equality alone.
R2 delivery applicability	Authenticated delivery bound to the selected task/listen context and valid profile window	Replay outside that bound context/window	Earlier cryptographic validity cannot establish current applicability; preserve the earlier observation. Requires the profile to choose any window, not a guessed timeout.
O1 source order	Two deliveries with independently bound source order, arriving in reverse	Arrival order alone; missing/inapplicable source-order evidence	Report bound order or not-established without overwriting either observation. Source order alone does not establish precedence or truth.
T1 exact result binding	Authentic, applicable commitment to the exact task and terminal-result bytes	Correct signature but wrong task/context; altered bytes; absent/unverifiable evidence	Assess exact-result binding separately from callback authentication and claimed status. Missing/inapplicable evidence is not-established; contradiction requires eligible comparable evidence.
T2 terminal conflict	One bound terminal observation	Two eligible conflicting terminal observations, in both arrival orders	Preserve both; no latest-arrival winner or inferred external effect.

Proposed accounting: retain #701's frozen source-record population and required relation set; count targeted attempts before eligibility, retaining malformed and duplicate attempts. A record cannot disappear because a binding failed. Each negative needs a positive twin and a single-boundary mutation; tests returning not-established everywhere must fail positives.

Before fixture code, please rule on R2's applicability/validity profile and T1's authoritative result commitment/source. I propose native subscriptions/listen at the already selected ext-tasks 7b8e2bd, without assuming subscription acceptance establishes result truth. R1/O1/T2 must extend the existing AM-04/05/06/09 controls rather than duplicate them. This is a proposed matrix, with no new execution results or production guarantee. Prepared with Codex.

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

Conditional matrix

Proposed completeness contract

Two profile decisions before code

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

imran-siddique commented on Oct 15, 2026

solloek369-arch commented on Oct 16, 2026

Conditional matrix

Proposed completeness contract

Two profile decisions before code

imran-siddique commented on Oct 16, 2026

dinakarjs commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions