Experiment: Capsule Emit inference receipts as a plugin

[ndizazzo]

Status: Draft prototype specification

Depends on #1331. Related umbrella: #1233. Prototype source and prior sidecar evidence: action-state-group/capsule-emit-mesh.

Summary

Build a native Rust, installable Capsule Emit plugin that produces signed, hash-chained Agent Action Capsules for OpenAI inference exchanges served by mesh-llm.

This is a prototype experiment to validate:

• the plugin lifecycle contract in spec: expose OpenAI request lifecycle to plugins #1331;
• a concrete inference-receipt field mapping;
• local signing, verification, chaining, retrieval, and optional transparency anchoring;
• non-streaming, streaming, error, denial, and cancellation behavior;
• composition between mesh-llm inference receipts and agent/tool action capsules.

The plugin must consume host-provided request/route/response lifecycle data over plugin IPC. It must not listen as an HTTP reverse proxy, require clients to use a second port, replace an inference backend, or require a custom mesh-llm binary.

Experiment hypothesis

An installable plugin can create a useful, portable, independently verifiable record that says:

This collector observed mesh-llm accept this request commitment, select this claimed model/runtime route, and return this response commitment.

The prototype does not establish that the claimed model performed the computation correctly. A self-signed capsule can cryptographically seal a false runtime claim. Model artifact verification, native compute receipts, hardware-bound signing, TEE/GPU evidence, statistical fingerprints, and distributed stage receipts remain separate assurance layers.

The experiment succeeds if it proves the integration and evidence-envelope mechanics without overstating the resulting trust level.

Why a plugin

The existing Capsule Emit mesh experiment proved the capsule format against a real mesh-llm node and Goose session, but it had to be a sidecar because plugins could not receive mesh-llm's own OpenAI request envelope.

That architecture had unavoidable limitations:

• clients had to target a second proxy port;
• the collector sat outside the mesh-llm trust boundary;
• streaming was buffered and re-synthesized;
• client-compatibility transformations occurred in the sidecar;
• it could not distinguish gateway, route-selection, and serving-host facts;
• it could not prove whether a refusal happened before dispatch.

#1331 is intended to remove those limitations generically. This issue validates that work with a real consumer.

Scope

In scope

• /v1/chat/completions;
• streaming and non-streaming responses;
• local-model serving for the primary acceptance run;
• successful, invalid, denied, failed, timed-out, and cancelled exchanges;
• host-provided route/model/runtime descriptors when available;
• request and response commitments;
• plugin-managed Ed25519 receipt signing with an owner-signed node/plugin delegation when the host owner identity is available;
• inclusion and independent verification of the existing node ownership and release-build attestation evidence;
• COSE_Sign1 signed statements;
• performance instrumentation, adaptive evidence heuristics, and a comparative benchmark report;
• per-plugin-instance hash chaining;
• local JSONL ledger and signed-statement storage;
• plugin HTTP resources for status, retrieval, and verification;
• optional, explicitly enabled SCITT/transparency anchoring;
• one live Goose integration run.

Stretch scope

• /v1/responses and /v1/completions;
• a request routed over a two-node private mesh;
• linking an inference capsule to a Goose/MCP action capsule;
• ingesting a native Skippy generation receipt as a typed evidence reference.

Out of scope

• claiming proof of correct inference;
• TEE, SEV-SNP, TDX, NVIDIA GPU, or TPM attestation;
• claiming that a software owner-delegated plugin key is non-exportable or proves runtime integrity;
• distributed per-stage activation receipts;
• statistical model fingerprinting;
• reputation or trust scoring;
• arbitrary request/response mutation;
• making Capsule Emit a required mesh-llm dependency;
• replacing the sidecar repository before the experiment is evaluated.

Architecture

OpenAI client
    |
    v
mesh-llm OpenAI ingress
    |
    +-- request_received ------> capsule plugin
    |                              allocate receipt_id
    |                              commit request
    |                              return continue + response header reference
    |
    +-- backend_selected ------> capsule plugin
    |                              bind effective request and route claims
    |
    +-- normal inference path
    |
    +-- response byte tap -----> capsule plugin side stream
    |
    +-- exchange_finished -----> capsule plugin
                                   finalize response commitment
                                   build capsule
                                   sign COSE statement
                                   append chain/ledger
                                   optionally enqueue anchor

The plugin is out-of-process, like other mesh-llm plugins, but it is not a network sidecar. It uses the host control connection and negotiated side streams from #1331 and never occupies the OpenAI request path as an HTTP server.

The prototype must be a native Rust plugin using mesh-llm's public plugin author API. Python reference implementations are interoperability oracles used by development/conformance tests only; Python is not a runtime dependency, subprocess, embedded interpreter, packaging requirement, or fallback execution path.

Native Rust implementation requirements

The experiment should look and behave like an ordinary mesh-llm plugin:

• use the mesh-llm-plugin crate, generated protocol types, plugin runtime, manifest builders/DSL, config schema, lifecycle hooks, and side-stream helpers;
• use the plugin! authoring pattern where it fits instead of implementing a private control protocol;
• declare the spec: expose OpenAI request lifecycle to plugins #1331 lifecycle capability through the generic manifest contract; do not special-case Capsule Emit in the host;
• expose status, receipt lookup, issuer material, and verification through normal host-projected plugin HTTP/resource surfaces;
• use Tokio-compatible async I/O and keep blocking filesystem, model hashing, and cryptographic preparation off control-plane tasks;
• stream request/response commitments incrementally where possible rather than retaining whole SSE transcripts;
• use typed Rust structures for the mesh evidence extension and capsule model, with explicit serde representations and schema/version constants;
• keep AAC, canonicalization, hashing, COSE/CBOR, signing, ledger, and anchoring dependencies inside the plugin rather than adding them to mesh-llm core;
• use reviewed Rust cryptography/serialization crates and pin behavior with golden vectors; exact dependency selection is an implementation decision subject to normal dependency review;
• never invoke Python, shell out to the reference CLI, or use FFI in the serving/runtime path;
• never read the owner keystore, node key, keychain, passphrase environment, or any host private-key file directly;
• consume identity evidence and signing delegation only through the permissioned host contract in spec: expose OpenAI request lifecycle to plugins #1331;
• package native per-platform plugin artifacts through the existing plugin installation/release conventions;
• preserve the normal plugin health, startup, shutdown, configuration, upgrade, and state-directory behavior.

The Rust implementation must produce artifacts compatible with the upstream Python tooling. Development and CI may install capsule-emit, agent-action-capsule, and scitt-cose to verify interoperability, but a released plugin must run and verify local records without them.

Plugin declaration and grants

The plugin declares the mesh.openai.exchange.v1 hook with:

• chat-completions request_received;
• backend_selected;
• exchange_finished;
• buffered request body access;
• streamed response body access;
• access to only X-Capsule-Client-Nonce from request headers;
• response metadata permission for X-Mesh-Receipt-Id;
• read access to the public node identity/attestation bundle;
• permission to request/renew the mesh.inference.capsule.sign.v1 signing delegation;
• observe-only admission behavior.

The host configuration explicitly grants these scopes.

The prototype returns continue/abstain for every request. Admission decisions are tested with the exemplar policy plugin from #1331, not smuggled into Capsule Emit behavior.

The experiment runs best-effort/fail-open by default. If the plugin is unhealthy, inference continues and host status must show evidence unavailable. A separate test may exercise required/fail-closed mode, but that must be an operator decision.

Receipt lifecycle

Provisional receipt identity

For the observe-only Capsule Emit plugin, avoid adding a synchronous plugin round trip solely to allocate an identifier. Prefer the host-generated exchange_id as the provisional receipt_id and return it as response metadata:

X-Mesh-Receipt-Id: <opaque-id>

The plugin binds its pending state and final capsule to that identifier. If #1331 instead requires plugin-generated response metadata, benchmark that synchronous path independently and retain it only if it meets the pre-dispatch overhead budget below.

The header is a correlation reference, not the final capsule ID and not proof.

The plugin exposes a host-projected HTTP resource such as:

GET /plugins/capsule-emit/http/receipts/{receipt_id}

States:

• pending;
• complete;
• failed;
• incomplete;
• not_found.

A complete result includes the final capsule_id, signed-statement reference, local verification result, anchor state, and evidence-strength labels. Prompt and completion bodies are never returned.

Request commitment

The plugin receives:

• exact decoded request bytes;
• host-computed SHA-256 of those bytes;
• parsed OpenAI request;
• endpoint, exchange ID, observation point, and sanitized nonce header.

It computes and records:

1. an exact wire_request_sha256 over the bytes the host accepted;
2. effect.request_digest using the Agent Action Capsule digest contract;
3. the canonicalization/transformation identifier used for that digest;
4. the client nonce and its source.

If the client sent X-Capsule-Client-Nonce, record client_supplied. Otherwise generate a fallback nonce and record plugin_generated_fallback. The fallback must never be described as client anti-replay evidence.

OpenAI requests commonly contain floating-point generation parameters. The implementation must publish test vectors showing exactly how JSON numbers enter the Agent Action Capsule digest. The previous experiment's decimal-string conversion may be reused only if the transformation is versioned and explicitly recorded. The exact wire digest remains available to remove ambiguity.

Raw prompts, messages, inline media, and tool arguments are discarded after the required commitments are computed. They are not written to the ledger or logs.

Route and model commitment

At backend_selected, the plugin binds available facts into the pending receipt:

• requested model;
• effective model;
• local/remote target and observation point;
• provider/backend kind;
• model package or artifact digest;
• tokenizer/template digest if available;
• runtime/release artifact digest if available;
• request attempt number;
• transformations between original and effective requests;
• source and verification state of every identity field.

Rules:

• a display name, URL, or canonical model reference is not a model artifact digest;
• unavailable artifact evidence remains unavailable;
• a configured manifest fallback is labelled configured_claim, not host_verified;
• release/build attestation is build provenance, not runtime integrity;
• a remote route claim is not evidence from the remote compute boundary.

For the primary local-GGUF test, hash the actual resolved GGUF bytes or consume an equivalent host-provided verified artifact digest. For a Skippy package, prefer its canonical manifest/source/artifact digests.

Response commitment

For non-streaming responses, record:

• exact client-facing response bytes and host-computed SHA-256;
• semantic JSON response digest;
• HTTP status and terminal category.

For streaming responses:

• mesh-llm continues to stream original bytes directly to the client;
• the host mirrors the final encoded SSE transcript to the plugin;
• the plugin or host incrementally commits the ordered transcript;
• the plugin may also build a bounded semantic reassembly for effect.response_digest;
• the capsule records which representation each digest covers;
• truncation, dropped chunks, cancellation, or observer overflow makes evidence incomplete.

Unlike the sidecar experiment, the plugin must not buffer and re-synthesize SSE, normalize tool calls, add tool-call IDs, remove mixed content, or otherwise alter the response.

A separate delivered_response_digest is required if the semantic response digest does not cover the exact emitted bytes.

Terminal semantics

Map host terminal states precisely:

Host state	Capsule interpretation
completed	confirmed/executed
policy denied before backend dispatch	denied/no dispatch
invalid request	rejected before dispatch
backend returned an error	failed/errored
transport failure after dispatch	failed/errored with transport context
client cancellation	cancelled, including whether bytes were emitted
incomplete observer transcript	evidence incomplete, never confirmed as complete
plugin absent/unhealthy	no capsule; host reports evidence unavailable

A sidecar cannot know that a refusal occurred before dispatch; the plugin lifecycle can. The prototype must use denied only when the host explicitly confirms that no backend dispatch occurred.

Capsule field mapping

Use the existing proof-of-concept mapping as the starting point:

Receipt fact	Agent Action Capsule mapping
request commitment	effect.request_digest plus x-mesh-poc-v1.wire_request_sha256
response commitment	effect.response_digest plus x-mesh-poc-v1.delivered_response_sha256
client nonce/source	model_attestation.compute_attestation.x-mesh-poc-v1
model package digest/source	model_attestation.compute_attestation.x-mesh-poc-v1
runtime/build digest/source	model_attestation.compute_attestation.runtime and x-mesh-poc-v1
generation parameters	x-mesh-poc-v1 as exact decimal strings
route/observation point	x-mesh-poc-v1
later fingerprint/TEE evidence	typed evidence references, empty in this prototype
node-local history	chain.parent_capsule_id with relation confirms
whole statement signature	COSE_Sign1 EdDSA

Fields not registered by the Agent Action Capsule specification remain under the explicit x-mesh-poc-v1 namespace. Do not present extension fields as standardized.

Publish the full sample schema and golden capsules as prototype artifacts.

Signing, node identity, and key management

The prototype should use mesh-llm's existing identity hierarchy rather than creating an unrelated trust root whenever an owner identity is available.

Existing identities remain separate

• owner identity: the stable Ed25519 key created by mesh-llm auth init;
• node identity: the QUIC/iroh endpoint key;
• SignedNodeOwnership: the existing short-lived owner-signed binding from owner to node endpoint;
• release build attestation: release-signer evidence for the packaged mesh-llm executable;
• receipt key: a plugin-owned Ed25519 key used only for Capsule COSE statements.

The owner and node private keys remain host-owned. The plugin never reads or receives them.

Preferred owner-delegated flow

1. On first start, the plugin generates an Ed25519 receipt key in its plugin state directory.
2. It requests ReadIdentityBundle from spec: expose OpenAI request lifecycle to plugins #1331 and independently verifies all supplied public evidence.
3. It sends only the receipt public key to DelegatePluginSigningKey with scope mesh.inference.capsule.sign.v1.
4. The host authenticates plugin identity from the live connection and returns a fixed-shape, owner-signed PluginSigningDelegation bound to:
   • owner ID/public key;
   • current node endpoint ID;
   • current SignedNodeOwnership certificate ID;
   • plugin ID/version/artifact digest when available;
   • receipt public key;
   • signing scope;
   • issue/expiry time and delegation ID.
5. The plugin verifies the delegation before becoming ready.
6. Per-request COSE_Sign1 statements are signed by the receipt key, not the owner key.
7. The proof bundle includes the receipt public key, PluginSigningDelegation, SignedNodeOwnership, and release build attestation/reference.
8. Delegation renewal happens before expiry on a background lifecycle path, never per request.

This produces:

trusted owner key
    | signs
    +-- SignedNodeOwnership --------> node endpoint identity
    |
    +-- PluginSigningDelegation ----> Capsule receipt public key
                                           |
                                           | signs
                                           v
                                      COSE inference capsule

An offline verifier confirms that the same owner authorized both the node and the scoped receipt key, then applies expiry/revocation/trust policy.

Why not sign every capsule with the owner key

The owner key may represent several nodes and is a high-value, long-lived identity. Using it for every request would:

• increase online exposure and signing volume;
• blur which node produced a receipt;
• couple inference latency to keystore/keychain availability;
• turn the host into a high-frequency signing oracle;
• complicate future hardware-backed receipt keys.

The owner key signs only short-lived delegation claims at startup/renewal.

Receipt key storage and rotation

• private key mode 0600 where supported;
• atomic generation/persistence and fsync policy consistent with plugin state handling;
• secret bytes zeroized where practical;
• no private key in source, packages, ledgers, metrics, examples, status, or logs;
• stable issuer ID derived from the receipt public key;
• explicit key-generation counter/version in local state;
• rotate on operator request, suspected compromise, incompatible key format, or configured policy;
• delegation is invalidated and reissued when receipt key, plugin artifact/version, node key, owner key, or node ownership certificate changes;
• renewal retains the receipt key when safe so ledger continuity does not require key rotation;
• key rotation creates an explicit chain-transition record signed by the old key when available and the new delegated key;
• expired/missing/revoked delegation cannot be represented as owner-delegated.

A software receipt key remains exportable. Owner delegation establishes authorization and attribution, not that signing occurred only on that machine. A future host-managed TPM/TEE/non-exportable key should fit the same delegation/evidence shape.

Identity modes

Configuration supports:

• self_attested: independent plugin key, accurately labelled;
• owner_delegated: prefer owner delegation, fall back to self-attested with an explicit downgraded state;
• owner_delegated_required: plugin is not ready for evidence if a valid delegation is unavailable;
• hardware_delegated: reserved for future attested/non-exportable keys.

No fallback silently preserves the stronger assurance label.

Release attestation composition

The identity bundle may include mesh-llm's verified release build attestation. The capsule records its digest, verification status, signer, build ID, commit, target, and artifact digest as a distinct evidence reference.

Release attestation remains certified build provenance. It does not prove that the running process is unmodified, that the plugin artifact was measured, or that the claimed model executed the request.

Assurance labels

At minimum:

• collector;
• api_boundary_observation;
• runtime_claimed;
• identity_mode = self_attested | owner_delegated | hardware_delegated;
• owner_binding_status;
• node_ownership_status;
• release_attestation_status;
• delegation_id/expiry inside the proof bundle, never telemetry.

Ledger and chaining

Store:

• capsules.jsonl;
• signed-statements/{capsule_id}.cose;
• receipt_id to capsule_id/status index;
• anchor queue/status when enabled.

Requirements:

• append serialization is single-writer and crash-safe enough not to create an invalid chain silently;
• restart recovers the previous chain head;
• a partially written line is detected and quarantined or repaired explicitly;
• signed statements are written atomically;
• a chain fork is reported, not silently selected;
• retention is configurable;
• raw prompts and outputs are never persisted;
• verification can run without network access.

Hash chaining is per plugin issuer/instance. It is not evidence that the node could not maintain a second private chain. Transparency or independent witnessing is a separate assurance.

Anchoring

Anchoring is disabled by default.

When explicitly enabled:

• submit only the intended digest/statement reference, never prompt or output bodies;
• use a durable retry queue;
• distinguish pending, submitted, anchored, rejected, and failed;
• never report anchored merely because submission was requested;
• expose the receipt and verification result;
• make the anchor URL configurable;
• apply bounded retries and backoff;
• provide a way to disable or purge unsubmitted test entries.

The acceptance run should use offline verification. A live public-log write requires a deliberate operator action after reviewing the exact capsule.

Plugin resources and configuration

Suggested projected HTTP/resources:

• GET status;
• GET receipts/{receipt_id};
• GET capsules/{capsule_id};
• GET issuer;
• POST verify for a local capsule/signed statement, if safely bounded;
• GET anchor queue/status.

Suggested configuration:

• ledger directory;
• retention;
• issuer/node label;
• identity mode: self_attested, owner_delegated, or owner_delegated_required;
• receipt key path or generated-key policy;
• receipt key rotation policy;
• delegation renewal window within host-capped validity;
• anchoring enabled and service URL;
• request/response semantic digest mode;
• maximum semantic reassembly bytes;
• evidence mode: full, digest_only, sampled, or disabled;
• sampling rate for explicitly selected sampled mode;
• observer queue capacity and high-water mark;
• best-effort load-shedding thresholds;
• ledger flush/group-commit policy;
• whether configured model/runtime manifest fallbacks are allowed;
• logging level.

Sensitive settings remain owner-only. The web UI is optional and not required for prototype success.

Privacy requirements

• Prompt, completion, tool arguments, inline media, and authorization secrets are not persisted.
• No raw body appears in normal logs, error messages, health details, or plugin status.
• Digest-only records must warn that low-entropy values may be vulnerable to dictionary attacks.
• The plugin keeps body material only for the minimum time needed to compute commitments.
• Test fixtures use synthetic prompts and outputs.
• Any permalink/bundle flow must be reviewed to ensure it contains only intended digest-level evidence.

Performance hypothesis, heuristics, and decision gate

Performance is part of the experiment's validity. Functional capsule generation is not sufficient if the observer materially worsens time-to-first-token, token cadence, throughput, memory use, or request reliability.

Hot-path hypothesis

The expected low-overhead shape is:

• the host allocates exchange_id/receipt_id without waiting for the observe-only plugin;
• owner/node identity evidence and receipt-key delegation are loaded/verified at startup and renewed outside request handling;
• immutable model, package, runtime, delegation, and public-key digests are computed once and cached, never rehashed per request;
• request bytes already buffered by OpenAI ingress are hashed once without an additional full copy;
• response bytes are committed incrementally from the final emitter tap;
• semantic response reconstruction is bounded and performed off the token-emission task;
• capsule serialization, COSE signing, ledger append, and anchoring occur after the final client byte;
• anchoring is always asynchronous and never on the inference or receipt-finalization critical path;
• filesystem work uses a bounded worker and configurable group commit rather than fsync per token or chunk;
• queues are bounded and expose pressure instead of growing with stream duration.

The benchmark must verify these assumptions rather than treating them as true by design.

Evidence modes

The prototype supports explicit, observable modes:

• full: wire commitments, bounded semantic commitments, signing, and durable ledger for every request;
• digest_only: incremental wire commitments and a signed record without full semantic reconstruction;
• sampled: full evidence for a configured random sample; sampling must not use prompt text or prompt hashes;
• disabled: no request body delivery or evidence work.

Mode is operator configuration. Adaptive load shedding is permitted only in best-effort mode and must be recorded per receipt as a downgrade or evidence-unavailable outcome.

In required/fail-closed mode, the plugin must never silently change full to digest_only or sampled. It either produces the required evidence or rejects before dispatch according to #1331.

Adaptive heuristics to evaluate

Implement and compare at least these heuristics:

1. Cache immutable artifact/runtime digests and invalidate only on a verified model/runtime change.
2. Use host-generated receipt IDs so observe-only mode has no identifier-allocation IPC round trip.
3. Hash streaming response bytes incrementally and keep only a bounded semantic reconstruction window.
4. Switch a best-effort request from full to digest_only when its semantic body limit is exceeded.
5. Mark evidence incomplete when the observer queue crosses its hard limit; never claim a complete transcript after dropped bytes.
6. Shed best-effort observation when plugin queue latency or pending receipt count exceeds configured high-water marks.
7. Batch ledger flushes while preserving crash-detection and chain ordering.
8. Keep transparency submission on a separate durable queue.
9. Permit explicit sampling for low-value traffic while retaining full mode for clients that request evidence.
10. Compare out-of-process plugin IPC/copy cost against a minimal in-host digest tap. If IPC dominates, reconsider which portion belongs in core versus the plugin.

Every heuristic decision is represented by a bounded mode/outcome/reason. No heuristic may be inferred later from a missing capsule.

Benchmark configurations

Measure the same build/model/settings in these configurations:

A. no plugin installed;
B. plugin installed with lifecycle/body grants disabled;
C. plugin active in digest_only mode with ledger persistence disabled;
D. plugin active in full mode with local signing and ledger persistence;
E. full mode with anchoring enabled but network submission isolated behind its queue;
F. the previous reverse-proxy sidecar, as an informative comparison rather than the target architecture.

This separates generic hook overhead, IPC/body mirroring, hashing, canonicalization/signing, persistence, and anchoring effects.

Workloads

Use both a deterministic fast mock backend, which makes fixed overhead visible, and a real local GGUF, which shows product impact.

At minimum:

• short non-streaming request/response;
• short prompt with long streaming output;
• long-context request;
• tool-calling request with nested schemas;
• large multimodal-shaped request fixture without private data;
• concurrency 1, 4, and 16 or the largest stable level on the test host;
• successful, backend-error, and client-cancelled streams.

Use fixed prompts, seeds where supported, output limits, model artifact, runtime build, and machine state. Record warm-up policy, repetitions, sample counts, machine profile, and all plugin settings.

Measurements

Report absolute and relative deltas, distributions, and run-to-run variance—not only averages.

End-to-end:

• admission-to-backend-dispatch delay;
• time to first response byte/token;
• inter-chunk/inter-token latency;
• total response latency;
• output tokens per second;
• requests per second at concurrency;
• error, cancellation, timeout, and incomplete-evidence rates.

Plugin/runtime:

• lifecycle IPC round-trip or delivery duration by phase;
• request hashing/canonicalization duration;
• final-emitter tap lag;
• observer queue depth/high-water mark;
• dropped events and dropped bytes;
• semantic reconstruction duration and peak bytes;
• capsule build/canonicalization duration;
• COSE signing and verification duration;
• ledger append, flush, and recovery duration;
• final-client-byte to receipt-complete delay;
• pending receipt count;
• anchor queue depth and attempt outcome;
• plugin CPU time, RSS/high-water memory, bytes copied/allocated where measurable, and disk bytes/fsync rate.

Use p50, p95, and p99 for latency distributions, median and dispersion across repeated trials, and confidence intervals or tolerance-aware comparison where the sample permits.

Provisional performance budget

Agree the final budget before implementation measurements are reviewed. The prototype starts with these provisional gates:

• deterministic mock: p95 admission-to-dispatch overhead no more than 5 ms in full mode and no more than 2 ms in digest_only mode;
• real local model: p95 time-to-first-token and total-latency regression no more than 2%;
• streaming: median token throughput regression no more than 2%, with no systematic p95 inter-token regression beyond baseline variance;
• no observer drops, false-complete receipts, or added request failures within the declared supported concurrency;
• memory remains bounded by configured queues/reassembly limits and does not grow with stream duration;
• p95 receipt completion occurs within 250 ms of the final client byte with anchoring excluded.

A result outside budget is not waived because model execution is slow. Report both absolute and relative effects, and repeat borderline results.

Decision rule

• Pass: full mode meets the agreed budget across the primary workloads.
• Conditional: digest_only meets budget but full does not. Keep the plugin experiment, make full evidence explicit/high-assurance opt-in, and investigate canonicalization/persistence offloading.
• Redesign: hook/IPC/body mirroring dominates. Move only the minimal byte commitment and correlation tap into host core, leaving capsule construction, signing, storage, and anchoring in the plugin.
• Stop: even a minimal digest tap causes unacceptable regression or cannot preserve streaming correctness. Do not graduate the plugin architecture.

The findings report must identify the dominant cost center and recommend pass, conditional, redesign, or stop.

Metrics and telemetry privacy

Detailed benchmark artifacts remain local and contain measurements/configuration only—never request or response bodies.

If runtime metrics are exported through mesh-llm OTLP, export remains explicitly operator-enabled and metrics-only. There is no hard-coded collector. Proposed logical instruments include:

• mesh_llm_capsule_receipt_total;
• mesh_llm_capsule_hook_duration_ms;
• mesh_llm_capsule_request_commit_duration_ms;
• mesh_llm_capsule_response_tap_lag_ms;
• mesh_llm_capsule_build_duration_ms;
• mesh_llm_capsule_sign_duration_ms;
• mesh_llm_capsule_ledger_append_duration_ms;
• mesh_llm_capsule_receipt_completion_delay_ms;
• mesh_llm_capsule_observer_queue_depth;
• mesh_llm_capsule_observer_drop_total;
• mesh_llm_capsule_anchor_queue_depth;
• mesh_llm_capsule_anchor_attempt_total;
• mesh_llm_capsule_identity_delegation_total;
• mesh_llm_capsule_identity_delegation_duration_ms.

Allowed attributes are bounded enums only: phase, evidence_mode, identity_mode, delegation_outcome, terminal_outcome, completeness, stream_mode, pressure_outcome, downgrade_reason, and anchor_outcome.

Do not export prompts, completions, tool arguments, nonces, request/capsule/receipt IDs, raw or hashed prompt data, model paths, ledger paths, endpoint URLs, hostnames, or raw node/device identifiers. Metrics collection and export are bounded and non-blocking.

Any implementation that adds these metrics to mesh-llm's OTLP path must update TELEMETRY_ATTRIBUTE_ALLOWLIST, docs/plugins/telemetry.md, and focused privacy tests as required by the telemetry review contract.

Deliverables

• A native Rust, external, installable mesh-llm plugin package; no mesh-llm fork, Python runtime, or HTTP reverse proxy.
• Rust implementations of the required AAC data model, canonicalization contract, COSE_Sign1 producer/verifier, chaining, ledger, and optional anchor client.
• Cross-language conformance fixtures proving compatibility with the upstream Python reference tools.
• Reproducible development launch and package/install instructions.
• Manifest and configuration schema using spec: expose OpenAI request lifecycle to plugins #1331.
• Request/route/terminal lifecycle implementation.
• Capsule creation and x-mesh-poc-v1 field mapping.
• Ed25519 receipt-key generation, storage, renewal, rotation, and COSE_Sign1 signing.
• Read/verify integration for SignedNodeOwnership and release build attestation.
• Owner-signed PluginSigningDelegation request, verification, renewal, and proof-bundle inclusion.
• Self-attested, owner-delegated, and owner-delegated-required policy modes with honest downgrade behavior.
• Durable local ledger, chain recovery, key-transition handling, and receipt lookup.
• Offline verification command and golden conformance artifacts.
• Optional anchoring with accurate durable status.
• Threat-model/assurance documentation using the required collector/self-attested labels.
• Reproducible benchmark harness and machine-readable raw results.
• Performance report comparing configurations A–F, including percentiles, variance, resource use, and a pass/conditional/redesign/stop recommendation.
• Metrics inventory and telemetry privacy review covering every exported metric and attribute.
• Comparison document showing what improved relative to the sidecar.

Test matrix

Contract tests

• Request byte digest matches an independent SHA-256 implementation.
• Response byte/SSE transcript digest matches an independent implementation.
• JSON canonicalization vectors cover integer, decimal, exponent, Unicode, key order, nested tools, multimodal parts, and null/omitted fields.
• COSE signature verification rejects a mutated capsule.
• Capsule ID verification rejects mutated effect/model fields.
• Restart preserves a valid chain head.
• Partial ledger writes do not create a silently accepted chain.
• No secret headers or raw bodies are persisted.
• Upstream Python verification accepts Rust-produced capsules and COSE statements.
• The Rust verifier accepts committed Python-produced golden capsules and statements.
• Rust and Python implementations produce identical canonical bytes and digest results for the agreed conformance vectors.
• The packaged plugin starts and completes the local verification path on every supported target without Python installed.
• The plugin never opens or reads the owner keystore, node-key file, keychain, or passphrase material.
• An owner-delegated capsule verifies through receipt key -> PluginSigningDelegation -> owner key and through SignedNodeOwnership -> the same owner/node.
• Missing owner identity produces self-attested downgrade or not-ready according to configured identity mode.
• Expired, revoked, mismatched-node, mismatched-plugin, wrong-scope, and bad-signature delegations are rejected.
• Delegation renewal occurs outside request handling and does not change the receipt key unnecessarily.
• Receipt-key rotation produces an explicit, verifiable chain transition.
• Release attestation is verified and presented separately from node ownership/runtime claims.

Host integration tests

• Non-streaming success emits one verifiable capsule.
• Streaming success remains live passthrough and emits one verifiable capsule.
• Backend error emits an errored capsule with the actual error commitment.
• Pre-dispatch denial emits denied only when the host confirms no dispatch.
• Client cancellation records cancellation and transcript completeness.
• Plugin timeout in best-effort mode does not stop inference and reports evidence unavailable.
• Plugin timeout in operator-selected required mode fails before dispatch.
• Receipt ID header resolves pending then complete.
• Plugin restart during an exchange does not produce a false complete capsule.

Performance acceptance

• Benchmark no-plugin, disabled-grant, digest_only, full, queued-anchor, and sidecar configurations.
• Run the deterministic mock workload and a real local-GGUF workload.
• Cover streaming/non-streaming, short/long bodies, tool schemas, cancellation, errors, and declared concurrency.
• Report p50/p95/p99 latency, token throughput, request throughput, resource use, queue pressure, and receipt completion delay.
• Verify immutable artifact/runtime digests are cached rather than recomputed per request.
• Verify owner delegation issuance/renewal, signing, ledger persistence, and anchoring do not run on token-emission tasks.
• Verify memory stays within configured queue/reassembly bounds for long streams.
• Verify every load-shed/downgrade event is explicit and no incomplete transcript becomes a complete capsule.
• Meet the agreed performance budget or classify the result as conditional, redesign, or stop.
• Confirm exported metrics pass prompt/completion/path/ID/URL privacy exclusion tests.

Live acceptance

• Run against a real mesh-llm local GGUF, not only a mock.
• Run a real Goose tool-call session through the normal mesh-llm port.
• Produce independently verifiable inference and tool-action capsule streams.
• Confirm the client receives the original mesh-llm streaming bytes without sidecar normalization.
• Record the actual model artifact digest and its evidence source.
• Keep the acceptance artifacts offline unless anchoring is explicitly approved.

Stretch acceptance

• Route one request over a two-node private mesh and label gateway versus serving-host observations.
• Link one inference receipt to one Goose/MCP action capsule by shared digest/reference.
• Attach a Skippy native generation receipt as a typed evidence reference.

Success criteria

The experiment is successful when a stock mesh-llm build can install the native Rust plugin on a machine without Python, serve a real streaming request on its normal OpenAI port, return a receipt reference, and later provide a locally verifiable signed capsule whose request/response commitments match the host-emitted bytes. When the node has an owner identity, the proof must also verify through the scoped PluginSigningDelegation and existing SignedNodeOwnership without exposing either host private key.

Functional success is necessary but insufficient. Graduation also requires the full mode to meet the agreed performance budget, or an explicit conditional/redesign decision supported by the benchmark evidence.

Success does not depend on proving correct model execution or productionizing the public transparency service.

Evaluation and follow-up decision

At the end of the experiment, publish a short findings report answering:

1. Is spec: expose OpenAI request lifecycle to plugins #1331 sufficient for audit and policy plugins without adding a generic unsafe middleware API?
2. What are the measured p50/p95/p99 latency, token-throughput, CPU, memory, copying, queue, persistence, and receipt-completion costs of each evidence mode?
3. Which heuristic or subsystem dominates overhead, and does the result support pass, conditional, redesign, or stop?
4. Can streaming evidence be complete without meaningful latency or memory regression?
5. Is the Agent Action Capsule profile expressive enough without abusing unregistered fields?
6. Which mesh-specific extension fields should be proposed upstream?
7. Does the Rust producer/verifier interoperate completely with the Python reference implementation, and which reusable pieces should be proposed upstream?
8. What is required to link this API-boundary capsule to an authoritative native generation receipt?
9. Does the owner -> node ownership plus owner -> scoped receipt-key delegation provide the right software identity chain, rotation, and revocation semantics?
10. What is required to upgrade the delegated receipt key to host-managed or hardware-attested/non-exportable storage?
11. Should the prototype graduate, remain experimental, or be retired?

Alternatives considered

Continue the sidecar

Useful as a compatibility demo and independent observer, but it cannot satisfy the in-host policy and provenance goals and changes streaming behavior.

Implement Capsule Emit directly in core

Would couple mesh-llm to one evidence format before the plugin contract and threat model are validated.

Use only native generation receipts

More authoritative about tokens, but does not commit to the original OpenAI request or exact client-visible response. The eventual design should link both layers.

Sign every capsule directly with the owner key

This gives a short verification chain but increases use of the long-lived owner key, obscures per-node attribution when one owner controls multiple nodes, and makes request completion depend on the owner keystore/keychain. Use owner signatures for short-lived delegation only.

Sign directly with the QUIC node transport key

This would bind receipts to the wire identity, but couples transport-key lifecycle to application evidence, expands the transport key's signing surface, and still requires owner/release evidence composition. Keep the node secret inside transport ownership and bind the receipt key through the existing owner/node certificate instead.

Give the plugin the owner or node private key

Rejected. Plugin compromise would become owner/node identity compromise, and it would bypass existing keystore, keychain, passphrase, rotation, and incident-response boundaries.

Use the Python reference implementation as the plugin runtime

This minimizes initial format work, but it would create a second plugin SDK/framing implementation, add interpreter and dependency packaging to every target, diverge from mesh-llm's native plugin patterns, and leave no credible production path. Python remains valuable as an independent conformance oracle, not as runtime architecture.

Embed or invoke Python behind a Rust wrapper

A native launcher around a Python worker would preserve the same deployment and supply-chain problems while adding IPC and failure modes. The prototype must implement the evidence path in Rust and use Python only in development/conformance tests.

[StevenMih]

This is a better specification of the integration than the thing it specifies, and the parts I would have argued for are already in it: out-of-process, no second port, no fork, a generic contract rather than a named special case, streaming as live passthrough with a copy rather than an inline observer, and the honest-labelling discipline carried all the way through — collector, runtime_claimed, "no fallback silently preserves the stronger assurance label," "never report anchored merely because submission was requested." Nothing in the sidecar's evidence deserves to survive contact with a real plugin contract, and this replaces it properly.

On the Rust implementation: I think it should be yours, and I would like to make that easy rather than merely say it.

A native implementation of the record model, canonicalization, COSE production and verification, chaining and ledger is real work, and my instinct was to write it and hand it over. That instinct is wrong, and not for a polite reason. The composition draft's conformance rule holds that a vector freezes only after two implementations maintained by different parties consume the same published bytes and produce matching reports — and it is explicit that sharing a library or a fixture does not count as independent recomputation. There is one implementation today and it is mine, which means the vectors cannot freeze at all until somebody else's exists. A native Rust implementation written by you is not you absorbing work I would rather avoid; it is the second implementation without which none of this becomes conformance. https://datatracker.ietf.org/doc/html/draft-mih-sato-agent-accountability-composition (notes: 1- not an RFC, 2- 01 draft is in co-author review/consent)

What I can usefully do is remove every excuse for it to diverge:

the canonicalization declaration — which bytes each digest covers, how JSON numbers enter it, versioned and explicitly recorded, as this issue requires;
golden vectors covering integers, decimals, exponents, Unicode, key order, nested tool schemas, multimodal parts, and null-versus-omitted;
a cross-language conformance harness, so "the Rust verifier accepts Python-produced capsules and vice versa" is a command rather than an intention;
review of the field mapping, on request and without a claim on the outcome.

One open question I would rather flag than let an implementation answer implicitly. Following on from #1303: the tool-call ids minted by the normalizer carry a wall clock, so digesting the normalized response yields a different value on every run for identical model output. Fine for correlation, which is what it is for — but it means a digest over delivered bytes cannot support anything that verifies by re-running a node's work, and there is no defined place to take deterministic model-produced bytes from. My view is that the record should commit to both, as separately declared fields: an exact digest over what the model produced, and a digest over what the client received. You already have most of this with wire_request_sha256 alongside effect.request_digest; the response side needs the same treatment and a name for the domain each one covers.

Preliminary answers to your evaluation questions, offered now rather than at the end:

Q5 — is the profile expressive enough without abusing unregistered fields? Almost. Four things deserve to graduate into the general format because they are domain-neutral: execution-bundle identity (per #1346 — what a record commits to is a bundle, not a model, and the same field covers container digests, tool binaries, kernel versions, TEE images); multiple witnesses with policy for how many and whose; disclosure expressed as two fields rather than one enum — artifact form and who can disclose it — which is what lets an encrypted-inference implementer adopt the format unmodified; and the authorized-bound versus performed-consumption pair, unit-agnostic, with the units living in your profile.
Q6 — which mesh-specific fields should be proposed upstream? Everything else stays yours: token counts and units, generation parameters, model package specifics, route and backend descriptors, nonce source, FHE scheme parameters, fingerprint confidences, mesh observation points. x-mesh-poc-v1 is the right home, and the graduation test is "is this true of records that have nothing to do with serving a model?"
Q8 — what links this to an authoritative native generation receipt? A typed reference — digest plus declared context — from the API-boundary record to the generation record, which is the same seam your steps 4 and 5 already use for fingerprints and TEE quotes. No wire-format change, and it is the same mechanism that would link an inference record to the agent action that acted on it.

On the profile and the registry. The way this normally works is that the owner of a payload declares its canonicalization and publishes vectors, and the entry is authored and attested by them — an entry written on someone's behalf is not an independent implementation of anything. So rather than draft yours, there is a template in the PR, with a deliberately non-mesh worked example so it stays a template. If it is useful, fill it; if the shape is wrong, tell me what it is missing.

One thing the template will ask that is worth surfacing here: a deployment usually fills more than one slot, and it does that by composing several profiles rather than writing one large entry. On the mesh case my reading is that you fill WHAT and AUDIT, carry a cross-party leg once requester commitments exist, and leave CAN and WHO deliberately unpopulated — CAN wants a declared authority issuing a bounded grant, WHO wants a named accountable human, and neither is what a mesh exchange produces. Saying that explicitly is a stronger statement than claiming a slot you do not fill.

Two smaller notes.

Off by default is right for an experiment, and I would keep it. The distinction worth writing down is that registration is required of the claim, not of the software: a node that has not registered sits at a lower rung and should render as one. What a conformant implementation needs is the capability — able to register, to more than one log, with accurate status — not the act. And because commitments accumulate locally with only periodic publication rather than one operation per record, this adds no latency to a request at all; the cost is paid in freshness, not speed.

A terminology point I've had raised at IETF and think is worth settling before it hardens in three specs. Registration is the act of submitting a Signed Statement; a Receipt (RFC 9942) is what the service returns; witnessing is a separate party co-signing the log's checkpoint so the log cannot present different views to different readers. They are three things, and a perfectly good receipt from an unwitnessed log is a weaker claim than one from a witnessed one. "Anchor" is a useful shorthand between us, but it isn't the vocabulary of the relevant RFCs and it collides with trust anchor, which means a root of trust rather than an act of publication. I've moved my own documents to registration/receipt/witness and would suggest the same here while it's still cheap.

All three documents are in a PR rather than pasted here, so they can be reviewed line by line: https://github.com/action-state-group/capsule-emit-mesh/blob/dcb3b3f/docs/REGISTRY-ENTRY-TEMPLATE.md
Happy to move any of it into your docs/ or into the specification itself if you would rather it live there.

[StevenMih]

One result relevant to the anchoring discussion here, since it went from assertion to artifact today.

A single record now carries registration receipts from two independently operated transparency services, with a verifier that checks each and reports them separately — including the case where one is reachable and the other is not, which renders as one checked and one absent rather than an aggregate pass. That last part is the whole reason to build it: an aggregate would let a partial result read as a complete one.

action-state-group/capsule-emit #57.

The limitation is stated in the README in one sentence and I would rather say it here too: both instances are operated by us, so this demonstrates the mechanism and proves nothing whatsoever about independence — which is precisely the property it exists to argue for. Two logs run by one party are one party.

Which is why the question from my earlier comment is a real one rather than rhetorical: if one organisation runs the only transparency log an ecosystem uses, every property the record claims rests on a party that is not neutral by construction, however well it behaves. Would you operate one? (maybe Block? Its all Apache 2.0, ddonation bound) A second independently operated log is the difference between a neutral record and one whose history rests on a single organisation — and it is worth more than any amount of neutrality language anyone could write about themselves.

Also relevant to this issue specifically: with peaks published on a schedule rather than one operation per record, registration adds no latency to a request at all — the cost is paid in freshness, not speed. That is consistent with keeping it off by default in the experiment, which I still think is right.

[StevenMih]

@michaelneale @ndizazzo Status update. Tis took longer than a straight port, for the following reasons:

Moving from sidecar to plugin. Getting to a trustworthy receipt meant building out three things the original sidecar didn't have:

CLL (Checkpointed Local Log) — the durable ledger layering: capsule (L0) → local MMR append-only log (L1) → a single 32-byte checkpoint root (L2) → witness/anchor (L3). This is what makes "durable local ledger, chain recovery, receipt lookup" real rather than a flat log.
A CPB (Canonical Payload Binding) registry — canonical registered entries for the mesh inference-exchange serialization and the MMR-checkpoint construction, so a receipt's byte-binding is pinned and independently reproducible, not a private convention. Open at scitt-payload-binding#61 — that repo backs the IETF I-D and needs both co-authors to approve before merge. For more on this: https://datatracker.ietf.org/doc/draft-mih-sokolov-scitt-payload-binding/
MMR + MMR_SHA256— the log is a Merkle Mountain Range; the checkpoint commitment is the bagged-peaks root (SHA-256, right-to-left fold), a single commitment with no separate peaks digest. Receipts are verified via the MMRIVER COSE-Merkle profile, run cross-language: the Python reference tools and an independent Go verifier both check the same artifacts. MMR_SHA256 https://datatracker.ietf.org/doc/draft-bryce-cose-receipts-mmr-profile/

I mentioned this on the call — the combination above is the evidence set that lines up with the proposed trust document. Worth laying it out in a few paragraphs how this compares to the pattern most people already know: get a receipt, log it.

A signature alone (receipt = sign(payload)) proves one thing: the holder of that key produced or endorsed this exact payload. It's a single party vouching for itself. Nothing stops that party from signing a different payload for a different counterparty, and nobody being able to tell — no independent record of when it happened, or that it was the only version.

A capsule (seal(payload)) is richer — more structure and context, plus local hash-chaining (the MMR/CLL above) so a producer's own sequence of capsules is internally consistent. But it's still one party sealing something about itself. Better bookkeeping doesn't change who's vouching: a producer can still seal two different capsules and equivocate between counterparties, and nothing outside the producer ever saw either one.

This is where "but we already log the receipt" usually comes in, and it's worth being precise about what that does and doesn't buy. log(receipt), where the same party that produced the receipt also runs the log, is a capsule with hash-chaining under a different name: each entry commits to the ones before it, so the producer can't quietly rewrite an old entry without every later root changing. That's real — it defends against tampering with your own history after the fact. It does not defend against equivocation at creation time. If you're both the only writer and the only one who ever answers "what's the current root," you can maintain two internally-consistent forks and show a different one to each counterparty. Each one looks perfectly hash-chained on its own; nobody who only sees one fork can prove the other exists.

A witness is the one role that removes that assumption, by construction: an independent third party (capsule-anchor, scitt-cose, the SCITT Transparency Service) takes the sealed capsule's checkpoint digest — not the raw log — and hands back its own receipt proving inclusion at a specific position. Concretely, the Checkpoint object's signing body is {v, kind, log_id, mmr_size, root, prev_size, prev_root, key_id, timestamp}; root/prev_root are each one 32-byte SHA-256 digest. Everything upstream of that — however many capsules were sealed locally between checkpoints — collapses into that single digest via the MMR. Anchoring one checkpoint costs the witness exactly one 32-byte commit, whether 10 or 10,000 capsules fed into it, and verifying any individual capsule's inclusion — or that a new checkpoint honestly extends an old one — is a small logarithmic proof against that root, not a re-send of the whole log. And we send it as a capsule :)

That buys three things signing or self-hosted logging can't:

Equivocation resistance someone else can actually check — if the producer later shows a different version to a different party, anyone holding the log root can prove the mismatch, because only one version is in the log.
Non-repudiation against a neutral party, not self-assertion — "this existed at time T" is attested by someone with no stake in the outcome, not just claimed by the producer.
An ordering/existence proof any third party can verify independently — without trusting the producer, or even the witness's good faith on any single request. That's the point of a transparency log: its own consistency over time is itself auditable.

So the ladder is: sign proves authorship, seal adds internal structure and self-consistency, and witness is the only one of the three that removes "trust the producer" from the question of existence and ordering — which is exactly why it has to stay neutral, and why anyone should be able to run one.

On building the Rust plugin. While I was hoping for an independent implementation, we went ahead and built it. The surprise: the interconnect was far more work than the capsule logic — the plugin↔host gRPC SDK wiring, the lifecycle-hook integration (see #1331), and the install/CI/packaging plumbing dwarfed the agentactioncapsue/COSE/ledger logic, which is well-specified and already has reference implementations. If your team would rather clean-room re-implement the Rust plugin from #1331's contract plus our cross-language conformance fixtures, that's a fully supported path — the fixtures + registered constructions are exactly what make it clean-roomable, and we'd rather that than you inherit our integration scaffolding.

Honest gap: the Rust plugin today does the admission decision on the real wire; it does not yet produce capsules in Rust — COSE signing / chaining / ledger is still the Python sidecar (proven end-to-end against the real host, incl. an anchored checkpoint with a rollback-mutant shown red). Porting capsule production into Rust is the main remaining deliverable.

Deliverables status (our markers; transcribe what you accept):

• ✅ native Rust, external, installable plugin — no fork, no Python runtime, no HTTP reverse proxy
• ✅ cross-language conformance vs the Python reference tools (+ independent Go verifier)
• ✅ reproducible launch + package/install instructions
• ✅ durable local ledger, chain recovery, receipt lookup (the CLL)
• ✅ offline verification command + golden conformance artifacts
• ✅ optional anchoring with accurate durable status
• 🟡 request/route/terminal lifecycle — pre-dispatch proven; terminal/streaming blocked on spec: expose OpenAI request lifecycle to plugins #1331
• 🟡 manifest/config schema using spec: expose OpenAI request lifecycle to plugins #1331 — partial, tracks the contract
• ⬜ Rust AAC data model / canonicalization / COSE_Sign1 producer / chaining (proven in the Python sidecar + scitt-cose; Rust port pending)
• ⬜ Ed25519 receipt-key gen/storage/renewal/rotation in Rust
• ⬜ owner-signed PluginSigningDelegation (needs spec: expose OpenAI request lifecycle to plugins #1331's delegation surface)
• ⬜ benchmark harness + A–F performance report

Conformance checks already passing (in the sidecar / scitt-cose today, portable to Rust):

• ✅ request/response byte digests match an independent SHA-256
• ✅ JSON canonicalization vectors (integer/decimal/exponent/Unicode/key-order/nested-tools/multimodal/null-omitted)
• ✅ COSE verification rejects a mutated capsule; capsule-ID rejects mutated effect/model fields
• ✅ restart preserves a valid chain head; partial writes don't create a silently-accepted chain
• ✅ no secret headers or raw bodies persisted

[StevenMih]

Quick progress update since the last note — and yes, we're working through the rest of the #1331/#1332 list, not parking it.

Lifecycle hooks (#1331) — reference implementation is up. The pre-dispatch seam is built and wired: #1437 adds the OpenAI exchange lifecycle hooks (effective-request + terminal, out-of-process, no HTTP reverse proxy), in review. Straight about scope: it's a reference slice — non-streaming chat on the typed path, proven by tests — deliberately something concrete to react to, not the finished contract. Sstate machine +manifest/negotiation are the continued work, and they're what clear the 🟡 lifecycle markers.

Rust plugin digest — nowe caught a real one: theRust admission path was hashing raw wire bytes where the spec/Python refereuse canonical JCS. FixedJCS digest, restoringbyte-for-byte digest equality with the Python tools and the Go verifier. A of the Rust canonicalizae full COSE producer port.

CPB registry — co-authorload-binding (the repobacking the IETF I-D): the co-author's review just landed — CANONICAL-DIGESnow crypto-agile (digestistry entry, nothardcoded), the jcs-n withdrawal is stated precisely (191/203 byte-audit), constructions are selectnot convention. One charter decision remains between the co-authors before -02 merges.

Capsule wire-shape — frozen against a second cross-language reference. The capsule_id / COSE_Sign1 nt-addressed id over thesignature-free payload (chain included), COSE_Sign1 with the raw Ed25519 public key in the protected heachor — agreed against anindependent Go reference implementation. So the ⬜ "Rust AAC data model / COSE_Sign1 producer" now conformance reference tobuild the port against — that Rust capsule-production port is the main remainideliverable we flagged (

On the rest of the list:ts is the observationsubset — streaming byte-tap, request/response digests (already passing in the sidecar), full terminal e #1331 hooks landing. Thedelegation block (owner-signed PluginSigningDelegation, the identity bundle) ia genuinely separate identract; our sidecarself-attests and doesn't need it for the receipt path, so we're scoping it as its own track, not a recoffer stands: #1331's contract + our cross-language conformance fixtures are what make a from-scratch Rust plugin buildable if your team prefers that.

[DSHCorrectover]

Following this experiment closely — we are building the analogous layer for agent tool calls rather than inference exchanges. A few concrete observations from running Ed25519-signed receipts in production that may save time:

1. Canonicalization matters more than the signature algorithm. We chose RFC 8785 (JCS) over naive JSON.stringify because key ordering, unicode escaping, and number representation differences between Python/Node/Rust produce different hashes for semantically identical records. Pick a canonical form early and pin it with test vectors.

2. The sidecar/key-isolation boundary is the whole game. If the signing key lives in the same process as the agent, a compromised runtime can re-sign a forged chain. We hold the key in a separate proxy that the agent cannot access — it receives a canonicalized action envelope, signs it, and returns the receipt. The agent never sees the key.

3. Hash chaining detects truncation but not equivocation. A chain proves no record was altered, but an attacker who controls the signer can produce two valid chains (equivocation). For your transparency anchoring use case, anchoring periodic chain heads to a public log closes this. For local-only use cases, chaining alone is sufficient.

4. Negative controls are non-negotiable. Our test suite includes: tampered field value, wrong signing key, reordered JSON keys, widened scope, and truncated chain — each must fail closed. We have 10 MIT-licensed conformance vectors with an independent ~15-line verifier here if useful as cross-implementation reference: https://github.com/DSHCorrectover/ccs-conformance-vectors

Looking forward to seeing the capsule format spec.