Define session-independent execution correlation for post-session MCP

[imran-siddique]

Track the MCP 2026 compatibility gap identified in the roadmap impact review. Define a cMCP execution identifier that survives independent requests without implying an MCP protocol session. Acceptance evidence: protocol-version vectors; correlation across retries and multi-request work; explicit collision, replay, and missing-context failures; TRACE records remain offline-joinable.

[Yatsuiii]

I wrote the design this issue now builds against in #574, so here is the implementation shape I would take it in, and a scope boundary I would want checked before starting.

Correlation and durable state. An executable state machine over admission, reservation, invocation, response, audit persistence, retry, recovery and terminal disposition. One authoritative durable record per execution_id, keyed under the authenticated agent identity as ruled on #574. The identifier and the immutable action digest reserved atomically before invocation. Terminal state and audit evidence commit together, or recovery leaves the execution blocked and unable to authorize a replay. Tests for concurrent collision, process restart, persistence failure, mutated action, missing context and terminal replay.

That slice proves only that independent requests can be correlated. It does not make retry safe, and I would not present it as exactly once execution.

Then the three conditions that share the boundary. #567's Task transitions and authenticated callbacks, #568's split between workload identity, represented user and delegated authority, and #566's catalog checkpoint binding. Each has to preserve the same identity boundary rather than grow its own version of it, which is the part that argues for doing them as one sequence. On #566, @solloek369-arch has proposed keeping the discovered schema, the approved checkpoint and the checkpoint attributed to a governed call independently mutable. That is the right shape for the acceptance matrix and I would build against it rather than around it.

Falsification before claims. A stateful harness that generates valid sequences then mutates ordering, identity, action digest, policy hash, tool digest, callback authority and persistence outcome, with crashes injected before and after each durable boundary. Every failure has to produce a stable finding or terminal disposition, never an uncaught exception or a silent evidence gap.

Scope question. I would leave HTTP-native transport out. It is P1 in the roadmap impact document with no issue filed, and #574's own reasoning was that the params._cmcp envelope "keeps the design neutral across transports and avoids depending on future HTTP header design." Same test applied here. If you intend to file it during this work, that changes the scope and I would rather know before starting than after.

I would like to take this sequence: #565 first, then #567, #568 and #566 as each boundary lands, in that order rather than in parallel. If any of it is already spoken for, say so and I will stay out of the way.

[solloek369-arch]

The sequence looks sound to me, and I agree with keeping HTTP-native transport outside this slice.

A few boundaries I’d want to make explicit before #565 implementation:

When you say terminal state and audit evidence “commit together”, do you mean one actual durable transaction boundary? If they are separate writes, the crash exactly between those writes seems worth making explicit in the recovery matrix.

Also, since this slice deliberately does not claim retry safety, I’d want to be clear whether retry/recovery here means classifying a repeated request or can ever lead to another invocation.

And I’d freeze the exact action-digest domain, canonicalization/version and digest recipe before implementation, so “same execution_id, mutated action” has one reproducible meaning and #565 doesn’t accidentally decide pieces of #568 or #566.

Otherwise the sequence looks consistent with #574 and the roadmap. Not spoken for on my end.

[Yatsuiii]

Thanks, and all three are the right boundaries to settle first.

On committing together. One actual transaction boundary, and today that needs work rather than just use. AuditStore.append() at audit/store.py:55 is one insert and one commit() per entry under a lock, so a terminal transition and its audit evidence are currently two separate durable writes. SQLite can give a single boundary, journal_mode=WAL and synchronous=FULL are already set, but reaching it means a store method that writes both inside one transaction, not calling the existing one twice. Where a backend cannot give that boundary, the crash exactly between the two writes has to resolve fail closed rather than be avoided by ordering. #574 already fixes what that means: an execution that never reaches a terminal outcome "is never reusable and never expires", so a crash between the effect and its terminal record leaves a stuck execution holding its identifier, not a replayable one. That is the safe direction and it is also a real cost, so it belongs in the recovery matrix as its own named case rather than as a footnote on process restart. I would rather show that case failing closed than claim the window does not exist. There is precedent for stating it that way here: #575's own description keeps the bounded lost-ack ambiguity, where a store commits and then raises before acknowledgement, as a documented limit rather than presenting the result as global exactly-once.

On what retry means here. Classifying only. This slice never re-invokes. A repeated request carrying a known execution_id is classified against the authoritative record and refused if the binding conflicts, refused after a terminal outcome including outcome_unknown, and refused while the prior attempt is still in flight, since an execution without a terminal is never reusable. Re-invocation would need idempotency and repair semantics that are not in #565 and that I would not smuggle in under "recovery".

On freezing the action digest. Agreed, and it is worse than one recipe needing a version tag. There are already four independent canonicalizations in this repository and they do not agree:

• startup.py:98, sort_keys and separators, returns raw bytes
• audit/chain.py:86, adds ensure_ascii=True, returns hex
• catalog/scanner.py:20, adds default=str and omits ensure_ascii, returns hex
• catalog/loader.py:132, ensure_ascii=True, returns a sha256: prefixed string

scanner.py's default=str is the one I would not build on: it coerces non-JSON values through str(), so its digest depends on repr rather than on the value. trace-tests canonicalizes with rfc8785 JCS, which this repository uses nowhere.

So "same execution_id, mutated action" has no single reproducible meaning today. I would want the domain, canonicalization and version frozen in the spec before implementation, not chosen inside #565. It also has to stay the identity of the call, not of the tool schema, which is #566, and not of the identity claims, which is #568, exactly as you say.

@imran-siddique, that last one is a spec question rather than an implementation choice, since #574 deliberately did not add a wire field for the binding. Which recipe should it be, and should it be versioned from the start?

[solloek369-arch]

Small donor from current main: merged #532 already established an RFC 8785/JCS canonicalization precedent for catalog approvals. It handles UTF-16 key ordering and UTF-8/non-ASCII correctly, and rejects values that this profile cannot canonicalize safely.

I would not reuse that helper directly for #565 because it deliberately rejects floats, while the current tools/call path accepts finite fractional JSON numbers.

One useful test before choosing the action-binding recipe may be {"x":1} versus {"x":1.0}. Under JCS, both canonicalize to {"x":1}. But cMCP currently passes them to Cedar differently: the integer stays 1, while the float becomes "1.0".

So a JCS-based action binding could assign them the same binding value while policy evaluation sees different values. It seems worth deciding that explicitly: either that collapse is intentional and downstream policy semantics should agree, or the binding needs to preserve the distinction.

#532 narrows the canonicalization side of the question without deciding the #565 preimage. Just offering the existing precedent and this differential as donors for that spec decision.

[Yatsuiii]

Confirmed both halves against current main:

{"x": 1}    JCS -> b'{"x":1}'   _cedar_safe -> {'x': 1}
{"x": 1.0}  JCS -> b'{"x":1}'   _cedar_safe -> {'x': '1.0'}

_cedar_safe at mcp/proxy.py:156 gives the reason in its own docstring: "Cedar has no float or null type: a single float anywhere in the request context makes cedarpy reject the whole request, which fails closed and denies the call. Floats are preserved as strings." So the two requests are one value to JCS and two values to policy.

That is worth more than a spec footnote, because it inverts the rule #574 exists to enforce. #574 refuses a reused execution_id whose binding conflicts, on the grounds that a changed binding means a different operation. The float case would be the same failure with the sign flipped: identical binding, different authorization input, and a binding built on JCS has nothing to refuse it with. A retry classified as the same logical operation could have been evaluated under different policy values than the attempt it claims to repeat.

So I do not think the collapse can be adopted as intentional unless policy is made to agree, and the current context path has no way to make it agree: a fractional number would have to reach Cedar in a form it can compare as a number rather than as the string _cedar_safe produces.

The constraint I would want stated is that the action binding must be at least as discriminating as the value policy actually evaluated. JCS alone is not, for exactly this input. Which of the two ways to satisfy it is chosen looks like a spec call rather than an implementation one.

Of the two ways to satisfy it, binding over the post-coercion form coincidentally satisfies it but puts a Cedar-specific detail inside an artifact meant for offline verification, and an external verifier would have to reimplement _cedar_safe to check it. I would rather follow the #532 precedent. _canonical_members already raises on floats and on integers outside the exactly-serializable range, so the shape of the answer exists: refuse at admission what the profile cannot canonicalize without losing a distinction policy can see. That keeps the binding a pure function of the request, and it makes the refusal visible at the boundary instead of surfacing later as a retry that was never the same call.

Happy to turn the differential into a vector if that helps settle it.

[solloek369-arch]

One acceptance property may still be missing beneath the byte-level vectors already listed here.

The 1 versus 1.0 vector above shows one instance of it: under a JCS-based binding, canonical byte agreement does not necessarily imply that the equivalence class is adequate for the request behavior the action identity is meant to represent.

A more general requirement may be:

Holding the relevant non-action context fixed, for binding-equivalent inputs, no request-derived authorization, gating, or invocation-input interpretation covered by the action-identity claim may still depend on which member of that equivalence class was supplied.

Current main appears to contain a second downstream witness. parameter_headers() accepts a value for an x-mcp-header declared as integer only when the supplied value is an actual Python int; a float is rejected. Under that schema, 1 can therefore produce the header while 1.0 raises, even though JCS gives the two values the same canonical number representation.

I am treating that as a reachable current-main differential, conditional on that schema shape, not evidence of a deployed incident.

Would it make sense for the acceptance evidence to include one check at this equivalence-class boundary itself: holding the surrounding non-action context fixed, if two admitted inputs receive the same action binding, every request-derived authorization, gating, or invocation-input interpretation covered by that identity claim must also treat them equivalently?

That would make byte-level interoperability and semantic adequacy of the binding equivalence class two explicit properties of the contract, without absorbing policy, catalog/schema, authority, or target identity into the action digest.

[Yatsuiii]

Confirmed on current main, with {"properties": {"n": {"type": "integer", "x-mcp-header": "Count"}}}:

{"n": 1}    JCS=b'{"n":1}'  ->  {'Mcp-Param-Count': '1'}
{"n": 1.0}  JCS=b'{"n":1}'  ->  ValueError: x-mcp-header value for 'n' does not match integer

parameter_headers is called at mcp/proxy.py:557 with the approved input schema and the live arguments, so the path is reachable on the schema shape you conditioned it to.

This witness is sharper than the Cedar one. There both members proceed and policy evaluates different values. Here the raise happens at line 557, before the try that wraps client.post, so the upstream call does not occur for one member of the class and does for the other. A single binding equivalence class spans admitted and not-attempted.

Worth noting where that same function already agrees with JCS rather than diverging: it refuses integers beyond 2**53 - 1, the same safe range RFC 8785 serializes exactly, and it excludes bools from the integer branch. The divergence is specifically the int/float distinction that JCS collapses and parameter_headers does not.

On the property as you have stated it, I think that is the right shape and I would want it in the contract. Byte-level interoperability and semantic adequacy of the equivalence class are different claims about the binding, and the two witnesses bracket the second one: same binding with different authorization input, and same binding with different admission outcome.