spec: expose OpenAI request lifecycle to plugins

[ndizazzo]

Status: Draft specification

Related umbrella: #1233. This issue specifies the plugin-platform prerequisite exposed by the Capsule Emit sidecar experiment and its findings on #1233.

Summary

Add an opt-in, permissioned OpenAI exchange lifecycle contract for installable mesh-llm plugins.

A plugin that declares this contract must be able to:

1. inspect the original OpenAI request envelope before model dispatch;
2. return a bounded pre-dispatch policy decision;
3. observe the effective request and selected serving route before execution;
4. observe the terminal response, error, denial, or cancellation;
5. correlate every phase without becoming an HTTP reverse proxy.

The contract must cover chat completions, legacy completions, and Responses, including streaming requests. It must preserve ordinary OpenAI streaming rather than forcing the host to buffer a response.

Motivation

The current plugin architecture is primarily provider-oriented: plugins contribute operations, HTTP/MCP surfaces, external inference endpoints, and mesh capabilities. It does not let an installable plugin observe or make a policy decision about traffic arriving at mesh-llm's own OpenAI API.

The native serving plugin ABI exposes generation token lifecycle data, but not the original OpenAI request or the client-visible response. It therefore cannot compute a receipt over the API request/response pair.

OpenAiHookPolicy is a useful in-process seam, but it is compiled into the backend wrapper, currently invokes only the before-chat hook, and is not available to an installable out-of-process plugin.

The Capsule Emit experiment consequently had to run as a reverse-proxy sidecar. That proved the record format but introduced a second port, changed the request topology, buffered/re-synthesized SSE, and could only describe itself honestly as an external collector. Other policy, audit, DLP, guardrail, routing, and compliance plugins will hit the same limitation.

Goals

• Make the request envelope available to explicitly authorized plugins.
• Allow an authorized plugin to allow, abstain, or deny before dispatch.
• Expose both what the client submitted and what mesh-llm actually dispatched.
• Expose what mesh-llm actually returned to the client.
• Preserve exact byte-level commitments alongside parsed OpenAI semantics.
• Support streaming without changing response bytes, chunk order, or latency characteristics beyond bounded hook overhead.
• Make evidence absence, hook failure, policy denial, backend error, cancellation, and successful completion distinct terminal states.
• Keep the contract generic; Capsule Emit is one consumer, not a core special case.
• Let explicitly authorized plugins consume the node's public identity/attestation bundle and obtain a narrowly scoped owner-signed delegation for a plugin signing key.
• Preserve existing plugins and mixed plugin-protocol deployments.

Non-goals

• Arbitrary request mutation in v1.
• Giving a plugin raw Authorization, Cookie, API-key, or owner-control headers.
• Giving a plugin owner-key, node-key, keystore, passphrase, keychain, or other private-key material.
• Providing an arbitrary-byte signing oracle backed by the owner or node transport key.
• Claiming that an API-boundary observation proves model execution.
• Replacing the native generation lifecycle or future TEE/runtime attestation.
• Making every plugin an observer by default.
• Requiring an HTTP sidecar or sending core inference through a plugin endpoint.
• Exposing these host-private lifecycle operations through MCP or public plugin HTTP projection.

Proposed contract

Declaration and authorization

Add an optional manifest declaration for an OpenAI exchange hook. A possible shape is:

openai_exchange_hook:
  contract: mesh.openai.exchange.v1
  endpoints: [chat_completions, completions, responses]
  phases: [request_received, backend_selected, exchange_finished]
  request_body_access: buffered
  response_body_access: streamed
  sanitized_headers: [x-capsule-client-nonce]
  decision_mode: admit
  response_metadata: true

The manifest is a request for access, not the grant itself.

Host configuration must explicitly grant:

• endpoint and phase subscriptions;
• request/response body access;
• sanitized header names;
• permission to make admission decisions;
• permission to add response metadata;
• failure policy and deadline.

Installing an ordinary plugin must not implicitly expose prompts or completions. The console/CLI should clearly warn when a plugin requests body access.

Prefer an additive manifest plus host-private service invocations over a new parallel plugin runtime. Existing InvokeService and side-stream transport can carry the control messages and large bodies. If protobuf additions are needed, they must be additive and feature-negotiated.

Lifecycle phases

1. request_received

Runs after mesh-llm has accepted and bounded the HTTP body but before routing, guardrail execution, or backend dispatch.

The envelope includes:

• exchange_id: stable for the full exchange;
• request_id / trace_id where available;
• endpoint kind and API version;
• HTTP method and normalized path;
• observation point and origin class: local ingress, tunneled ingress, internal retry, or other explicit value;
• sanitized allowlisted headers;
• exact decoded request body bytes or a side-stream reference, according to the grant;
• SHA-256 of those exact bytes, computed by the host;
• parsed OpenAI request JSON when parsing succeeded;
• parse status and content type;
• receipt/correlation metadata already attached by the host.

Allowed synchronous result:

• abstain: no policy opinion;
• allow: explicitly permit this plugin's policy;
• deny: stop before dispatch and return a stable OpenAI-shaped error;
• annotations: plugin-namespaced, bounded metadata carried to later phases;
• response metadata reservation: bounded, allowlisted response headers such as a provisional receipt ID.

V1 does not allow a plugin to rewrite the request. Mutation would require separate original/effective commitments, ordering semantics between multiple plugins, and a clearer security model.

A plugin's allow result never bypasses mesh-llm's own validation or another plugin's denial.

2. backend_selected

Runs after routing and core request transformation, but before the selected backend is invoked.

It includes:

• the original exchange_id;
• effective parsed request and its host-computed digest;
• selected public model ID;
• provider/backend kind;
• local or remote serving target;
• retry/attempt number;
• available model/package/runtime identity descriptors;
• core transformations that materially changed the request;
• accumulated namespaced annotations.

A plugin with admission permission may deny here as well, allowing policies to require a particular model identity, provider, peer, or evidence level before bytes reach a backend.

The contract must distinguish a route claim from verified artifact or runtime evidence. Missing identity fields are represented as unavailable, never inferred.

3. exchange_finished

Exactly one logical terminal event is attempted for every accepted request:

• completed;
• policy_denied;
• request_invalid;
• backend_error;
• transport_error;
• client_cancelled;
• timed_out;
• evidence_unavailable/internal_hook_failure.

It includes:

• exchange_id and attempt history;
• HTTP status;
• exact response-body bytes for buffered responses, or an ordered response transcript/side-stream for streamed responses;
• SHA-256 of exact client-facing bytes computed at the final host emitter;
• parsed/reassembled semantic response when available;
• usage and timing fields;
• selected route and model descriptors;
• whether any bytes were sent to the client;
• terminal evidence completeness and any dropped observer data.

For streaming, the byte tap must sit after all host transformations and immediately before socket emission. The plugin receives a copy; it is not placed inline between the emitter and client.

A streamed transcript must define whether it covers SSE frame payloads, complete encoded SSE frames, or both. The format and digest rules require published test vectors.

Streaming and payload transport

Large request bodies, multimodal inputs, and streaming outputs must use the existing negotiated side-stream mechanism rather than the long-lived control connection.

Requirements:

• control traffic remains responsive;
• every stream is correlated to exchange_id and phase;
• byte order is preserved;
• cancellation closes the observer stream;
• bounded queues report truncation or loss explicitly;
• best-effort observation never silently claims a complete transcript;
• required mode applies backpressure only when the operator selected it;
• no hook may force the host to buffer a complete SSE response merely to compute a receipt.

The host should compute wire digests while forwarding, so an observer can verify completeness without being trusted to report the digest correctly.

Multiple plugins and failure policy

Pre-dispatch decisions should execute concurrently under one host-owned deadline because v1 has no mutation ordering.

Aggregation rules:

• any successful deny wins;
• allow and abstain do not override a deny;
• annotations are namespaced by plugin ID;
• a required plugin timeout/disconnect produces a fail-closed service error;
• a best-effort plugin timeout/disconnect allows execution and records evidence unavailable;
• required/best-effort is host policy, not something a plugin can impose on installation;
• repeated failures trigger a circuit breaker and visible degraded state.

No plugin may block health checks or the control plane while a request hook is running.

Response metadata

A plugin may request bounded response metadata only through an explicit grant.

• Header names must use an approved namespace.
• Security, hop-by-hop, CORS, content-length, content-type, and authentication headers cannot be replaced.
• Streaming plugins may reserve a provisional correlation/receipt ID at request_received because final headers are sent before the final capsule exists.
• Non-streaming hooks may optionally return final metadata before headers are committed, within the same deadline.
• A response header is a reference, not evidence by itself.

Privacy and security

• Never expose Authorization, Proxy-Authorization, Cookie, Set-Cookie, owner-control credentials, or transport secrets.
• Header access is allowlist-only and case-normalized.
• Inline data URLs and multimodal request bodies count as sensitive body access.
• Logs and plugin summaries must not contain raw prompt/completion bodies.
• Body limits, stream limits, timeouts, and concurrency limits are host-owned.
• Host API/status surfaces must show which plugins currently have request/response access.
• Plugin removal or permission revocation takes effect without leaving a hidden traffic path.
• Request digests are commitments, not confidentiality; documentation must warn about dictionary attacks on low-entropy content.

Observation points and duplicate records

The envelope must state where it was observed. At minimum:

• gateway_ingress;
• serving_host_ingress;
• backend_dispatch;
• client_egress.

A routed mesh request may be visible at more than one node. exchange_id, hop_id, attempt, local_peer_id, and observation_point must make those records distinguishable. The host must not present a gateway observation as proof from the serving target.

Host identity and signing delegation

Receipt/audit plugins need to connect their statements to mesh-llm's existing identity hierarchy without reading private keys.

mesh-llm currently keeps these concepts separate:

• owner identity: the Ed25519 identity created by mesh-llm auth init;
• node identity: the QUIC/iroh endpoint key;
• SignedNodeOwnership: a short-lived owner-signed certificate binding owner identity to node endpoint identity;
• release build attestation: trusted release-signer evidence about the packaged mesh-llm executable, separate from ownership and remote runtime attestation.

Add an explicitly permissioned host service with two narrow operations.

ReadIdentityBundle

Return public, bounded evidence already held by the host:

• local node endpoint ID;
• SignedNodeOwnership and its local verification summary;
• owner ID and owner signing public key when present;
• release build attestation and verification summary when present;
• host version/build/artifact digest carried by the release attestation;
• installed plugin ID, version, source, and artifact/package digest when available;
• freshness and evidence-source metadata.

The response must preserve distinctions between missing, present-unverified, verified, expired, revoked, and invalid. It must not forward a boolean such as owner_verified without the signed evidence needed to verify it.

DelegatePluginSigningKey

The plugin supplies an Ed25519 public key and requests one registered signing scope. The host constructs and signs a fixed-shape PluginSigningDelegation; it does not sign plugin-provided arbitrary bytes.

Suggested claim:

PluginSigningDelegationV1 {
  delegation_id,
  owner_id,
  owner_sign_public_key,
  node_endpoint_id,
  node_ownership_cert_id,
  plugin_id,
  plugin_version,
  plugin_artifact_digest?,
  delegated_signing_public_key,
  scope,
  issued_at_unix_ms,
  expires_at_unix_ms
}

For Capsule Emit, the initial scope is mesh.inference.capsule.sign.v1.

Requirements:

• authenticate plugin_id from the live plugin connection, not request JSON;
• bind installed plugin version/artifact identity from host-owned metadata;
• bind the current node endpoint ID and owner certificate ID;
• use canonical serialization with a fixed domain tag such as mesh-llm-plugin-signing-delegation-v1:;
• sign only when the owner key is already available to the running host;
• cap validity and scope through host policy;
• make delegation issuance/renewal an explicit manifest permission;
• return unavailable when no owner identity is loaded rather than prompting during inference;
• never expose owner signing bytes, node secret bytes, keystore paths, passphrases, or keychain material;
• never allow a plugin to choose arbitrary claims, owner/node IDs, plugin identity, validity beyond policy, or signing domain;
• renew before expiry outside the request path;
• invalidate/reissue on plugin artifact, plugin key, node identity, owner identity, or relevant certificate change;
• include a delegation ID so revocation can be added or enforced explicitly;
• expose bounded status and audit events without logging public keys or IDs into OTLP metrics.

The existing owner key signs delegations only at plugin startup/renewal. Per-request statements are signed by the delegated plugin key, avoiding high-frequency use of the owner key.

A verifier chain is:

1. verify the receipt/COSE statement with the delegated plugin public key;
2. verify PluginSigningDelegation with the owner public key;
3. verify owner_id is derived from that owner public key;
4. verify SignedNodeOwnership binds the same owner and node endpoint ID;
5. apply expiry and local owner/node/delegation revocation policy;
6. verify release build attestation independently when supplied.

The release attestation remains build provenance. Linking it into the evidence bundle does not convert it into remote runtime attestation.

A software plugin key remains exportable and can be misused until delegation expiry. The delegation improves attribution, scoping, rotation, and revocation; it does not prove that the key was used only on the named node. A future host-managed, TPM/TEE-backed, or non-exportable delegated key can strengthen the same chain.

Fallback and policy

Identity mode is host policy:

• self_attested: plugin uses an independent key and labels it accurately;
• owner_delegated: require a valid PluginSigningDelegation and SignedNodeOwnership;
• owner_delegated_required: fail plugin readiness/required evidence when delegation is unavailable;
• hardware_delegated: reserved for future attested/non-exportable keys.

No mode silently upgrades its assurance label.

Compatibility requirements

The plugin protocol is currently generation 2 and initialization checks exact equality. This feature must not strand existing plugins.

Acceptable approaches include:

1. express the hook through existing v2 capability/service invocation and side streams, with a new optional manifest field and a package-level minimum mesh version; or
2. introduce protocol generation 3 while changing negotiation so a new host continues to run generation-2 plugins.

Whichever path is chosen:

• old plugins continue to run without modification;
• a new hook plugin fails startup clearly on a host that cannot provide the declared contract;
• unknown phases/fields are ignored only when the plugin marked them optional;
• required permissions cannot degrade silently to no observation;
• conformance tests cover new-host/old-plugin and unsupported-host/new-plugin behavior.

Implementation areas

Expected ownership:

• crates/mesh-llm-plugin: manifest types/builders, lifecycle DTOs, author-facing handlers, side-stream helpers, identity-bundle/delegation DTOs, conformance fixtures;
• crates/mesh-llm-identity: canonical PluginSigningDelegation claim and verification primitives, without plugin-runtime dependencies;
• crates/mesh-llm-host-runtime/src/plugin: subscription registry, grants, invocation, deadlines, health/circuit-breaker integration, identity bundle projection, and constrained delegation service;
• crates/openai-frontend: generic lifecycle seam covering chat, completions, Responses, errors, cancellation, and final emitters;
• crates/mesh-llm-host-runtime/src/network/openai: attach origin/route context and cover local plus tunneled paths;
• mesh-llm-config: explicit grants, failure policy, limits, and validation;
• docs/plugins: author contract, privacy model, lifecycle state machine, and exemplar plugin.

Do not special-case Capsule Emit by plugin name.

Acceptance criteria

• An installed test plugin can inspect a chat-completions request before backend invocation and deny based on its parsed body.
• A denied request never reaches the backend and returns a stable OpenAI-shaped policy error.
• An allowed request reaches the backend byte-for-byte unchanged by the plugin contract.
• The same plugin receives the effective request and selected route before dispatch.
• The terminal event covers non-streaming success, streaming success, validation error, policy denial, backend error, timeout, and client cancellation.
• Host-computed request and response byte digests match independent test calculations.
• Streaming remains live passthrough; the host does not buffer the full response and the plugin cannot reorder or rewrite chunks.
• An observer overflow or disconnect is represented as incomplete evidence rather than a successful complete observation.
• Authorization and cookie headers are absent from plugin fixtures and integration tests.
• Body access is disabled without an explicit host grant.
• A plugin without identity/delegation permission cannot read identity evidence or request a delegation.
• An authorized plugin can read the full public identity bundle and verify it independently.
• An authorized plugin can obtain an owner-signed delegation for its public key without receiving owner/node private material.
• Delegation claims bind the authenticated plugin, current node endpoint, current owner certificate, scope, and bounded validity.
• Arbitrary bytes/claims and unregistered scopes cannot be signed through the delegation service.
• Delegation renews outside request handling and is invalidated by plugin-key/artifact, node, owner, or certificate changes.
• Self-attested, owner-delegated, missing, expired, revoked, and invalid states remain distinct.
• Multiple hook plugins obey deterministic deny/failure aggregation.
• Local ingress and inbound tunneled serving paths are covered and identify their observation point.
• Existing generation-2 plugins continue to initialize and operate.
• An unsupported host rejects a plugin that requires this contract with an actionable error.
• A maintained exemplar demonstrates observe-only and admission-policy modes.
• Plugin architecture and security documentation are updated.

Alternatives considered

Keep using a reverse-proxy sidecar

Works without host changes, but changes ports/topology, only sees wire traffic outside the trust boundary, complicates streaming, and cannot distinguish internal routing/dispatch facts.

Use the native serving plugin ABI

Useful for authoritative token-generation evidence, but it does not contain the original API envelope or final client representation. It is complementary, not interchangeable.

Compile OpenAiHookPolicy into custom binaries

Provides an in-process seam, but is not installable and requires product forks. The goal is a stable capability contract.

Send every request through a plugin-provided inference endpoint

Reverses ownership and makes an observer become the backend/proxy. It also prevents the plugin from observing native and remotely routed backends generically.

Follow-up

The first consumer should be a separately scoped Capsule Emit prototype linked to #1233. That prototype must describe its evidence as API-boundary, self-attested collector evidence until a future compute-boundary or hardware-bound receipt is linked.

[StevenMih]

Read this properly. It removes every limitation the sidecar had, and generically rather than by special-casing one consumer — the same seam serves audit, DLP, guardrail and routing plugins, none of which should need a fork or a second port either.

The section I did not expect and want to call out: the identity and signing delegation service. ReadIdentityBundle plus DelegatePluginSigningKey, with an owner-signed delegation binding owner → node endpoint → ownership certificate → plugin artifact → receipt key → scope → expiry, and the plugin never touching owner or node private material. That closes the key-binding requirement from #1233 — "the signing key must be bound to a trusted node identity, owner policy, or hardware attestation" — using a hierarchy you already have. It is a better construction than the one I would have proposed: the owner key signs short-lived delegations rather than becoming a high-frequency signing oracle, and a compromised plugin does not become a compromised node.

The thing I want to raise, because it gets harder every week: there are now three assurance vocabularies in flight. This spec and #1332 carry one, #1346 carries another, and the trust model I drafted on #1233 carries a third. They describe overlapping axes, none is normative, and they are already inconsistent. Vocabulary divergence is worse than format divergence because it stays invisible until two records disagree about what "verified" meant.

A proposal, written as a proposal:
https://github.com/action-state-group/capsule-emit-mesh/blob/dcb3b3f/docs/ASSURANCE-VOCABULARY.md

The short version: these diverged because each was written for one job, and for that job collapsing several axes into one label was harmless. So the fix is a shape rule rather than a naming preference — every value belongs to exactly one axis — and five axes cover all three vocabularies: observation point, recorder role, evidence status, assurance rung, terminal outcome. The document maps every existing label onto them, which is the test of whether the scheme is real rather than merely tidier.

Two places I think you are right and I am not:

self_attested, your spelling, over self_asserted from #1346. One spelling, chosen once, and yours is in a milestoned spec.
Your evidence-status set beats mine. missing / present-unverified / verified / expired / revoked / invalid distinguishes states that genuinely matter for credential-shaped evidence — an expired delegation is not a missing one and a revoked one is neither. My three-state minimum is a floor, and the proposal adopts yours.

The one I would push back on is #1346's self_asserted | tee_attested | cryptographically_verified — not the terms but the packaging. Those span three axes: identity, execution, confidentiality. As a single enum they read as a ladder, inviting the conclusion that a TEE-attested record is more identified than a self-asserted one. It is not; they vary independently.

Two smaller notes on the spec itself:

The streamed transcript definition needs vectors, and you say so. Whether the digest covers SSE frame payloads, complete encoded frames, or both is exactly the decision that is obvious to whoever implements it first and invisible to everyone after. I can publish the vector format and a reference set so both sides of a conformance test have something to point at.

Observation point deserves to be load-bearing. You have the enum; what is worth stating normatively is that a gateway observation is never evidence about the serving host, and that a record which cannot say where it was observed should not be treated as either.

On canonicalization more broadly — #1332 asks for published test vectors showing exactly how JSON numbers enter a digest, and that is the right requirement. I would rather that declaration and its golden vectors exist before a native implementation makes those decisions by accident. Say where you would like them to live and I will put them there.

[StevenMih]

@ndizazzo Two pieces of prototype work against this spec turned up 20 underspecified corners — 11 from a development rig exercising the lifecycle state machine, 9 from an offline delegation-chain verifier. None of these are objections; the contract reads as sound. They're the precision gaps a downstream implementer hits first.

From the lifecycle mock host (11)

1. Terminal state count — eight or nine? The spec lists terminal states as ..., evidence_unavailable/internal_hook_failure. The / notation is ambiguous: are evidence_unavailable and internal_hook_failure two distinct terminal states (nine total) or is internal_hook_failure a sub-reason of evidence_unavailable? If nine, the spec text should say so explicitly.

2. Side-stream kinds aren't named anywhere. spec: expose OpenAI request lifecycle to plugins #1331 defines the negotiated side-stream mechanism generically (correlated to exchange_id and phase, ordered, cancellable) but doesn't enumerate specific stream kinds. We modeled three candidates for our own use case — anchoring, delegation-chain verification, evidence collection — but that's our inference, not something the spec specifies. If there's a canonical set of stream kinds (or Experiment: Capsule Emit inference receipts as a plugin #1332 has settled on some for the Capsule Emit plugin specifically), publishing that would keep independent implementations from diverging silently.

3. Host-integration test coverage — is there a published suite? We built our mock rig around nine integration scenarios (the eight terminal states + the observation-point integrity check), on the assumption that mirrors your own test surface. We don't have visibility into whether mesh-llm has a specific test suite — if one exists (or is planned), naming it would let downstream implementations target the same acceptance bar instead of each inferring their own.

4. Gateway↔host coordination is unspecified. The contract covers the serving host's view; the gateway has its own lifecycle. How does the gateway's gateway_ingress record relate to the host's serving_host_ingress record — one compound trace, or two records joined by a correlation ID? The integrity rule says a host must not present a gateway observation as its own, but the enforcement mechanism isn't specified.

5. backend_error vs transport_error at the boundary. Clear at the extremes (backend responded with an error vs. network died before any response). Unclear for mid-stream failures — backend started streaming, then the connection dropped. Which terminal state, and does backend_error require a response digest?

6. Same question, narrower. If dispatch happened and streaming began before the reset, is that transport_error or backend_error? backend_dispatch would have a payload digest (the sent request) but client_egress would have none. A rule for this specific case would resolve New UI #5 for the streaming path.

7. client_cancelled — which phase can it interrupt, and what happens to the backend? If a client disconnects during backend_selected while tokens are streaming, does the host abort backend generation, let it complete, or something else? Matters for billing and for evidence completeness.

8. timed_out scope — whose deadline? Exchange-level, per-phase, or per-hop TTL on split inference? If a backend hangs and the host kills it, is that timed_out or backend_error? A state-transition diagram with timeout edges would settle this.

9. evidence_unavailable — hook crash, genuinely absent evidence, or both? If the hook threw, that's an internal fault. If a node has no TEE and evidence was never going to exist, that's an expected outcome, not an error — it should render as evidence_present: false, not a failure. Conflating the two obscures the absent/present-unverified/checked discipline the trust model needs.

10. Phase names are given as prose headers, not a wire encoding. request_received, backend_selected, exchange_finished are clear as section names, but the spec doesn't say how they're represented on the wire — snake_case string enum, integer, protobuf field name matching the header exactly, or something else. We used the prose spelling verbatim; worth confirming that's also the intended wire value before it's load-bearing in two implementations.

11. Observation-point integrity — enforcement mechanism unspecified. The MUST-NOT ("a gateway observation is never proof from the serving target") is stated but not how it's enforced: is observer_role set by the producer, derived from the observation point, or are gateway and host records always structurally separate objects (which would make the forgery case impossible rather than requiring a runtime check)?

From the delegation-chain verifier (9) — already on docs/SPEC-FEEDBACK-1331.md in capsule-emit-mesh main https://github.com/action-state-group/capsule-emit-mesh

12. SignedNodeOwnership has no defined fields or encoding. We built a working shape (owner_id, owner_sign_public_key, node_endpoint_id, issued_at/expires_at, cert_id, signature) to unblock the verifier — happy to align to whatever the actual shape is.

13. owner_id derivation is unspecified. We assumed SHA-256 of the raw Ed25519 public key. What does mesh-llm auth init actually use?

14. Canonical serialization for PluginSigningDelegationV1 — JSON or CBOR, and is the domain tag literally prepended to canonical bytes or a separate signing-envelope field?

15. Public key encoding in the delegation struct — hex, base64, or the mesh identity layer's existing encoding (e.g. iroh's base32 NodeId)?

16. Release build attestation (step 6) — shape, signer, and trust-anchor distribution are all undefined. Our verifier stubs this step entirely.

17. delegation_id format — UUID, hash of the delegation bytes, or a plugin-scoped sequence number?

18. Revocation list shape and distribution — signed CRL, live endpoint query, or host-managed list? If signed, which key?

19. Offline verification's plugin-id check. The spec says authenticate plugin_id from the live connection, not request JSON — correct for the live host, but an offline verifier (checking a chain after the fact) has no connection. What's the canonical source of the expected plugin_id in that case? Is offline verification an intended use case at all?

20. Identity mode ↔ cross-party rung: the axes are orthogonal, and no mapping exists. owner_delegated improves attributability but does not grant a higher rung on the unilateral_fallback → acknowledged_receipt → full_bilateral ladder — those require counterparty co-signing, which is independent of how the plugin's key is delegated. Our verifier always emits rung: null for every identity mode with an explanatory note. Consistent with the assurance-vocabulary axes from the earlier comment on this issue — flagging because it's an easy place for an implementation to accidentally imply an evidentiary upgrade that isn't earned.

Happy to open PRs against #1331/#1332 text for any of these once you've got a read on which are real gaps vs. things we should just be reading more carefully.

[StevenMih]

Two more things sitting on our side that might be useful to you directly, separate from the feedback above:

A development rig (mock_lifecycle_host.py + tests) that exercises the full lifecycle state machine — the terminal states, observation points, and side streams — as a scripted scenario harness. It's explicitly not a conformant implementation of anything; it's what we built to find the 11 gaps above. If it's useful as a starting point for your own test fixtures or for a neutral conformance-test repo, it's Apache-2.0 and we're happy to hand it over or re-home it wherever makes sense — mesh-llm itself, a shared fixture repo, whatever you'd prefer.

An exemplar plugin demonstrating both observe_only and admission_policy modes against the mock rig — the one acceptance box in #1331 explicitly reserved for an external consumer ("a maintained exemplar demonstrates observe-only and admission-policy modes"). It surfaced 6 more spec-feedback items (body-access signaling, decision-mode enforcement, sanitized-header semantics, phase-subset subscription, and deny-at-wrong-phase handling) — happy to send those over once you've had a chance to look at the first 20, or now if you'd rather have everything at once.
Both in this: https://github.com/action-state-group/capsule-emit-mesh

Also — where are things on the host-runtime side? The issue's acceptance boxes are your Rust host-runtime work and we're not attempting those; we've been building downstream against the mock rig so we'd have something concrete to hand you rather than staying purely theoretical. If there's a branch or a rough timeline, it'd help us know whether to keep building against the mock or wait.

[StevenMih]

Following up from the capsule-emit sidecar experiment (#1233) — we built the out-of-process plugin against the real mesh-llm-host-runtime, and that surfaced a concrete finding about the hook model this spec should assume.

Hook-model finding. OpenAiHookPolicy in crates/openai-frontend/src/hooks.rs is the right seam conceptually, but as it stands it's compiled into the backend wrapper and only the before-chat hook is actually invoked — the effective-request/route and terminal/streaming phases this spec calls for aren't reachable by an installable out-of-process plugin today. Separately, MeshEvent is topology-only; the path a plugin actually registers through is exact-name inference::provider() registration, not a lifecycle event stream. So the request_received → backend_selected → exchange_finished shape in the draft is the right intent, but isn't buildable as drawn against main — the contract in this issue is precisely the missing piece.

What we could already validate against the real host (observe-only + admission modes):

• ✅ inspect a chat-completions request before backend invocation and deny on its parsed body
• ✅ denied request never reaches the backend; stable OpenAI-shaped policy error
• ✅ allowed request reaches the backend byte-for-byte unchanged
• ✅ observation point identified (local ingress vs tunneled)
• ✅ a maintained exemplar demonstrates both observe-only and admission-policy modes
• ✅ plugin/security docs written up (our DELTA.md + PROTOCOL-NOTE.md)

What the current hook model blocks — i.e. what this spec needs to expose:

• 🚧 effective request + selected route delivered to the plugin before dispatch
• 🚧 terminal event covering non-streaming success, streaming success, validation error, denial, backend error, timeout, cancellation
• 🚧 live streaming passthrough without host buffering
• 🚧 delegation surface (owner-signed delegation for the plugin key without private material)

Net: everything gated on pre-dispatch inspection works today; everything gated on effective-request / terminal / streaming needs the contract in this issue. Happy to align the contract's phase names to what inference::provider() + the host runtime actually expose if that's useful.

[StevenMih]

Update on the hook-model finding above: we built a concrete reference implementation of the missing phases and opened it as #1437 (in review) — so there's now something buildable to react to, not just the finding.

What #1437 wires against the real openai-frontend seam:

• effective-request + selected-route delivered pre-dispatch — on_effective_chat_completion(request, route) fires post-mutation, before dispatch (the 🚧 "effective request + route" item).
• a terminal event for the non-streaming chat path (success / error / denial) — a first cut of the 🚧 terminal event, not yet the full matrix.

Precise about what it is and isn't: a reference slice — non-streaming chat on the typed in-process path, proven by tests — deliberately a concrete proposal for the contract shape, not a finished feature. Still open, and where we'd value your steer on the contract:

• streaming success + live passthrough (no host buffering) and the rest of the terminal matrix (streaming success, validation-vs-backend error, timeout, cancellation) — these need the streaming byte-tap the contract should define.
• manifest/negotiation s a plugin requiring thiscontract with an actionable error.
• the delegation surface the plugin key) — asflagged, a separate identity subsystem; happy to keep it out of the core lifecycle contract and srefer.

The offer stands to aligerence::provider() + thehost runtime actually expose — #1437's route is currently just {model, exchange_id}, and we'd r_selected descriptors thaninvent our own. Clean-room from the contract + our conformance fixtures remains fully supported.