SEP-2624: chain-free consolidation of the interceptors SEP (draft)

[wi-ski]

What this revises

This revises the SEP body to complete the removal of the "chain" concept the Interceptors WG agreed to on the 2026-07-23 call, while keeping all of its mechanics. Chain execution had already been downgraded from a protocol method to a utility; this finishes the job: the wire protocol carries only unit operations (interceptors/list + interceptor/invoke), and multi-interceptor behavior is expressed as an invoker-local execution plan — never a protocol object.

Credit where due: Ukjae Jeong proposed removing the chain concept; Kurt Degiorgio and Peder Holdgaard Pedersen agreed to "eliminate the chain concept but keep the mechanics." Logged as a WG action item.

What it does (and does not)

• Strictly subtractive on the concept — removes the four chain pseudo-interfaces and the Chain Execution section; the ordering, atomicity, and failure-routing guarantees are preserved as invoker obligations in one self-contained Execution Model section (the sole normative home).
• Adds no wire surface — no new JSON-RPC method, request/response shape, pseudo-interface, or schema.
• Changes no mode naming — active / audit only, fail-closed default; audit never blocks.
• Removes attestation — the reserved signature field is gone; attestation is a separable design for a future track (per the July scope discussion).
• Net normative improvements (so this reads as tightening, not weakening): direction is now separated from phase with a MUST NOT infer direction from phase (the fix for the C#/Go divergence and the ordering bug flagged on-call); equal-priority ordering uses locale-independent Unicode comparison instead of ambiguous "alphabetically"; failure routing (mode × failOpen × severity, cancelled invocations, aggregate deadline) is made internally consistent; and every Execution Model MUST is wire-observable at a mock host, so the SEP-2484 conformance story maps onto it one-to-one.

Open questions for the WG (please weigh in)

These are decisions the SEP deliberately does not make unilaterally — flagging them for the group rather than silently choosing:

1. Error-response governance. v1 scopes the trust-boundary guarantee to successful result payloads; JSON-RPC error responses (carrying error, no result) are not intercepted, and are listed under Not specified with a SHOULD-not-smuggle note. Should v1 govern error payloads, or is deferring correct? (Governing them adds surface; the honest v1 position is to scope the claim and not overpromise — but this is the group's call.)
2. SEP-2133 reference-implementation gate — process ruling needed. The gate ("a reference implementation in an official SDK prior to review") is not yet met: the work is in flight as #13 (TypeScript SDK, draft) and #31 (conformance suite, draft). Does SDK code merged in the extension repository discharge the gate, or must it land in the official SDK repository proper? The SEP names the intended landing target and self-blocks advancement until this is resolved.
3. llm/completion payload schema. The one non-MCP event in the v1 union has no pinned schema yet. The SEP carries a self-resolving fallback: if the schema is not pinned when formal review begins, the event drops out of the v1 union and remains expressible as a custom event, changing no other rule. Pin the schema or accept the drop?
4. Track: Standards → Extensions. The header now reads Extensions Track (SEP-2133 designates extension SEPs as such, and the promotion-to-core endgame only parses this way). PR #2624 currently declares Standards Track — flagging so the sponsor ratifies or vetoes the change in review rather than discovering it.
5. Extension Maintainers. SEP-2133 requires the SEP to name the responsible WG and Extension Maintainers. The Consensus section names the Interceptors WG and points at SEP-2148 for appointment; individual maintainers still to be named by the group.
6. Pure-discovery fail-closed posture. Discovery-failure fail-closed applies to policy-designated interceptors; a pure-discovery invoker cannot be fail-closed by construction, so the SEP SHOULDs policy designation for security-critical boundaries. Should this be strengthened to a MUST for security-critical governance?

Status / ask

This is a Draft-stage revision. The ask today is feedback + the one process ruling (Q2) — not a formal-review trigger: the SEP-2133 reference-implementation gate is genuinely unmet and the document self-blocks on it (Q2/Q3/Q5). Pushing the revision to the Draft PR is safe and correct; advancing past Draft is gated on the items above.

Housekeeping

• AI-assisted drafting disclosure (per CONTRIBUTING): portions of this revision were drafted with AI assistance and reviewed by the author.
• An independent conformance run of the Initial implementation of TypeScript SDK #13 TypeScript SDK against the shared SEP-2624 fixtures is available (24/24) as supporting evidence for the reference-implementation track.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Copilot wasn't able to review any files in this pull request.