[PederHP]

Adds a third interceptor type — sink — to the working copy of the SEP (docs/sep.md).

What

A sink is a non-blocking, non-mutating interceptor that reacts to a context operation without affecting the interaction. It MUST NOT block execution and MUST NOT modify the payload — it exists to drive concurrent UX, workflow state, or downstream pipelines based on what the agent is doing.

Use cases: avatar/character animation from conversation mood, voice-mode / TTS switching, real-time UI affordances, background context indexing, secondary-agent triggers. The C# reference impl already demonstrates the avatar case end-to-end in AvatarMoodInterceptorSample.

Changes to docs/sep.md:

• Type union extended to "validation" | "mutation" | "sink" (all sites)
• New Sink section parallel to Validator / Mutator, with SinkResult
• Execution model: sink as a third stage (parallel, fire-and-forget) on each phase; Type Behaviors table updated
• Sinks exempt from aggregate timeouts, failOpen, and fail-closed requirements
• New avatar-mood sink example in discovery (audit-logger stays an audit-mode validator, since compliance logging must also capture rejected operations)
• Rationale restructured: separation of the three types, why sink vs mode: "audit", and why "sink" and not "observability" (avoids implying OpenTelemetry overlap)

Sinks are additive to the validator/mutator split and mode: "audit": audit mode disables enforcement while preserving a validator/mutator's interface; sinks are structurally non-enforcing and cannot be promoted to affect the interaction. Implementations MUST reject sinks declared with mode: "audit".

Why here

This re-homes the proposal from Degiorgio/modelcontextprotocol#1 — which targeted the SEP author's personal fork — onto this repo's working copy of the SEP. #21 established docs/sep.md as where the WG maintains and reviews the SEP, so the sink proposal belongs here. Once the WG agrees, it folds upstream into SEP-2624 along with the rest of docs/sep.md.

🤖 Generated with Claude Code

[Degiorgio]

@PederHP This is looking great, the sink/audit distinction is really clearly argued. One small thing I wanted to check my understanding on:

The Sink section notes that a sink MUST return a SinkResult, while the execution model describes sinks as
parallel, fire-and-forget. I might be missing something, but I wasn't totally sure how those fit together in
practice, if the runtime doesn't wait for the sink, when does it collect the SinkResult for ChainExecutionResult.results?

[PederHP]

@PederHP This is looking great, the sink/audit distinction is really clearly argued. One small thing I wanted to check my understanding on:

The Sink section notes that a sink MUST return a SinkResult, while the execution model describes sinks as parallel, fire-and-forget. I might be missing something, but I wasn't totally sure how those fit together in practice, if the runtime doesn't wait for the sink, when does it collect the SinkResult for ChainExecutionResult.results?

Yeah, the point of this one just to ensure that the request has been "sinked" - it is not a guarantee that the sink has actually been processed. One could argue that the sender can't really do anything with this - which is true - it is not supposed to be blocking, but it might still be useful in some cases to be able to send an error message back. But purely for observability - not something to build logic around. We could have a void-ish type instead - I wouldn't mind.

[Copilot]

🟡 Changes recommended

The documentation still subjects sinks to blocking result aggregation, aggregate timeouts, and fail-closed requirements, contradicting their required non-blocking behavior.

2 open issues

• Exclude sink calls from blocking aggregation and aggregate timeouts · New
• Exempt sinks from fail-closed behavior and ignore failOpen · New

What changed in this PR

This PR reintroduces sinks in the working-copy interceptor SEP, adding a non-blocking, non-mutating type for context-reactive workflows alongside validators and mutators.

Changes:

• Defines the sink contract and SinkResult, with audit-logger and avatar-mood examples.
• Adds fire-and-forget sink execution to the trust-boundary-aware execution model.
• Explains how sinks differ from audit mode and observability tooling.

File	Description
docs/​sep.md	Adds sink definitions, execution semantics, examples, and design rationale.

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The documentation claims complete compliance logging even though validation failures skip the sink-based logger, leaving rejected operations unlogged.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Sink logger omits rejected operations from compliance auditing

docs/​sep.md:590

Changing this logger to a sink means it will not run when a receiving validator rejects a request: the new execution model skips sinks on validation failure. As a result, it no longer satisfies the adjacent description, “Logs all MCP operations for compliance,” and omits rejected attempts even when the logger is healthy. Please label this as best-effort post-validation logging rather than a complete compliance audit, and make clear that rejected-operation auditing must be handled separately.

2 resolved since last review

• Exempt sinks from fail-closed behavior and ignore failOpen
• Exclude sink calls from blocking aggregation and aggregate timeouts

_{Review effort: Balanced}

[PederHP]

@PederHP This is looking great, the sink/audit distinction is really clearly argued. One small thing I wanted to check my understanding on:

The Sink section notes that a sink MUST return a SinkResult, while the execution model describes sinks as parallel, fire-and-forget. I might be missing something, but I wasn't totally sure how those fit together in practice, if the runtime doesn't wait for the sink, when does it collect the SinkResult for ChainExecutionResult.results?

The orchestration change now makes this clear - so sink results are read in the background and never delay the operation.

[PederHP]

Re the Copilot finding on audit-logger (docs/sep.md:590): fixed in 9a85746 by restoring it as an audit-mode validator, matching main and the other examples in the SEP (execution ordering, invoker overrides, context passing). Compliance logging that must capture rejected operations belongs in the validate stage; avatar-mood remains the sink example.

[Copilot]

🟡 Changes recommended

The documentation at docs/sep.md:1571 still uses “an” before mode, which should be corrected to “a.”

1 open issue

• Use “a” before the mode flag · New

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

No active review issues remain for the documentation changes introducing sink interceptors.

No open issues 🎉

1 resolved since last review

• Use “a” before the mode flag

_{Review effort: Balanced}