#byteor-edgeplane

byteor-edgeplane is the enterprise runtime surface for transport wiring. Use it when the operational question is "how do I move bytes between external systems and a ByteOr execution path with observable adapter health?"

#Deployment shape

byteor-edgeplane keeps the same shared operator verbs as byteor-runtime, but its steady-state execution path is an adapter loop:

• validate, describe, and dot stay focused on the spec itself.
• run is the long-running adapter-loop entrypoint.
• run --sp supports one-shot bring-up and explicit test input for SingleRing runs.
• doctor, snapshot, and incident-bundle stay available for host checks and triage.

In practice, an EdgePlane deployment has four moving parts:

1. the authored spec.kv,
2. an adapter configuration file selected with --config=... or discovered next to the extracted bundle,
3. a runtime lane path selected with --lane-path=... or derived from the standard /run/byteor conventions,
4. optional approval material when the deployed spec contains governed side effects.

Use --adapter-max-messages=N when you want a bounded drain instead of an unbounded service loop. That is the built-in way to turn a long-running transport flow into a controlled batch run.

#Adapter loop topology

The product surface is intentionally simple: one ingress binding and one egress binding are resolved from the deployment config and then executed under the shared adapter-loop runtime.

The transport inventory currently comes from the enterprise adapter catalog:

• line-oriented file adapters,
• HTTP and gRPC,
• WebSocket,
• Kafka, NATS, Redis Streams, and RabbitMQ Streams,
• S3 and PostgreSQL.

Operationally, treat EdgePlane config as deployment wiring rather than authored pipeline semantics. The spec decides what computation happens. The config decides which ingress and egress endpoints supply or receive the bytes.

#Snapshot and heartbeat expectations

When agent reporting bootstrap is present, byteor-edgeplane publishes both heartbeats and snapshots through the shared app kit contract.

Bootstrap requirements:

• BYTEOR_API_BASE_URL
• BYTEOR_AGENT_ID
• BYTEOR_AGENT_API_KEY

Reporting cadence defaults:

• BYTEOR_HEARTBEAT_INTERVAL_SECS=30
• BYTEOR_SNAPSHOT_INTERVAL_SECS=10

The EdgePlane snapshot contract is operator-friendly:

• top-level counters such as ingress_messages and egress_messages,
• mode=adapter_loop,
• per-adapter status entries under adapters, including name, role, transport, connection_state, message_count, recent_failures, last_error, and lag.

Before traffic arrives, idle snapshots still report both adapters as ready with message_count=0. During execution, the same payload evolves into a live transport-health view rather than a generic runtime snapshot.

#Approval and bundle expectations

EdgePlane does not invent a separate approval system. It reuses the shared enterprise approval flow:

• --approval=... injects a credential directly,
• approval.cred next to the extracted spec is loaded automatically when present,
• signing_keys.json next to the extracted spec is used as the default trust cache,
• explicit --approval-key-set=... flags override or extend that local trust material.

If control-plane bootstrap variables are present, the runtime can refresh trusted signing keys before verification and still keep the local cache as the steady-state fallback.

#Recommended operator flow

For day-2 work on transport loops:

1. Run validate after any spec or config change.
2. Run doctor before enabling aggressive tuning on a new host class.
3. Start with bounded --adapter-max-messages runs when proving a new transport path.
4. Treat live snapshots as the first source for transport lag, connection state, and recent failures.
5. Export an incident bundle before moving into replay or ad hoc reproduction.

Use ../reference/adapter-catalog.md for the transport inventory and operator-flow.md for the cross-product runbook.