diff --git a/docs/eve-migration-roadmap.md b/docs/eve-migration-roadmap.md
index f96d140..4a08cda 100644
--- a/docs/eve-migration-roadmap.md
+++ b/docs/eve-migration-roadmap.md
@@ -58,6 +58,9 @@ advertisements and typed command/receipt documents are the boundary.
 - CultLib emits a verified NuGet dependency closure for `GameCult.Mesh` and a
   clean package-reference consumer, while Unity consumes the corresponding
   `org.gamecult.cultlib` UPM assembly closure.
+- CultLib publishes transport-neutral `cultnet.operation_request.v0` and
+  `cultnet.operation_response.v0` envelopes in TypeScript, C#, and Rust. These
+  carry Eve plugin ABI documents without moving plugin semantics into CultLib.
 - EveElectron owns its shell, security lifecycle, captures, and runtime witness.
 - EveFlutter owns the generic Flutter clients and platform lifecycle.
 - Sai and Norn publish independent sidecar plugins. A Sai surface may request
@@ -98,9 +101,10 @@ advertisements and typed command/receipt documents are the boundary.
 
 - Publish the verified CultLib NuGet and Unity package artifacts from tagged
   releases and consume released versions in runtime CI.
-- Replace development `stdio-ndjson` transport where appropriate with the
-  published CultNet/CultMesh sidecar transport while preserving the same plugin
-  ABI operations.
+- Replace development `stdio-ndjson` transport with the published CultNet
+  operation sidecar transport while preserving the same plugin ABI operations.
+  CultNet TS still needs an owner-grade RUDP service host; CultNet Rust
+  verification must first integrate its current RUDP reset work.
 - Graduate graph semantics fully to Norn and VN/Ink semantics fully to Sai once
   no Eve fixture is their semantic owner.
 - Keep nested plugin availability explicit and non-transitive: Sai does not own
diff --git a/docs/plugin-architecture.md b/docs/plugin-architecture.md
index ef2bb18..29ded06 100644
--- a/docs/plugin-architecture.md
+++ b/docs/plugin-architecture.md
@@ -136,6 +136,14 @@ provider or renderer to bypass the contract because the plugin happens to be in
 the same language today. The standard shape is an executable plugin runtime with
 a typed request/response ABI.
 
+CultNet carries that ABI through the generic service envelopes
+`cultnet.operation_request.v0` and `cultnet.operation_response.v0`. The outer
+message owns service routing, operation name, correlation, runtime identity,
+status, and transport diagnostics. Its `payloadSchema` names the Eve plugin ABI
+request or response, and `payload` carries that document as base64 MessagePack.
+CultLib owns this transport envelope; Eve owns the inner plugin ABI; each plugin
+owns its handler and semantic state.
+
 Allowed implementation forms:
 
 - process sidecar;
@@ -183,7 +191,7 @@ Example ABI request:
 
 ```json
 {
-  "schema": "gamecult.eve.plugin_invocation.v1",
+  "schema": "gamecult.eve.plugin_abi.request.v1",
   "pluginId": "sai.vn",
   "operation": "apply",
   "requestId": "cmd-123",
@@ -203,7 +211,7 @@ Example ABI response:
 
 ```json
 {
-  "schema": "gamecult.eve.plugin_result.v1",
+  "schema": "gamecult.eve.plugin_abi.response.v1",
   "pluginId": "sai.vn",
   "operation": "apply",
   "requestId": "cmd-123",
@@ -459,11 +467,11 @@ Sai surface deploys with nested Norn or TeX, Sai composes the slots and keeps VN
 stage authority; Norn and TeX still publish and validate their own semantic
 contracts. Each plugin advertises only the ABI operations it actually owns.
 
-The carrier does not define the plugin. The first executable Norn proof uses
-UTF-8 NDJSON over stdio: one request document per line, one response per
-request in order, blank lines ignored, diagnostics on stderr. A future
-CultMesh daemon transport must carry the same typed request and response
-documents; it must not create a second semantic API.
+The carrier does not define the plugin. UTF-8 NDJSON over stdio remains a local
+debug adapter: one request document per line, one response per request in
+order, blank lines ignored, diagnostics on stderr. The production sidecar path
+uses CultNet operation envelopes carrying the same typed request and response
+documents; it does not create a second semantic API.
 
 Nested availability is a composition fact, not a Sai dependency story. A Sai
 surface can be deployed with a nested Norn or TeX surface only when that other