Enterprise Adapters
Enterprise adapters sit at the system boundary. They translate between deterministic ByteOr execution and external ingress or egress systems without collapsing the distinction between transport, execution, and governed operations.
Adapter inventory and exact contract detail stay in the synced Enterprise docs. This page explains how to think about the adapter surface from the public hub.
Adapter Boundary
Enterprise adapters exist so external systems do not leak directly into the deterministic runtime core.
- EdgePlane owns transport-facing ingress and egress loops.
- Action-style side effects stay separate from transport attachment and replay policy.
- Adapter configuration belongs in runtime config, bundle posture, and deployment wiring, not in hidden stage behavior.
What Sits Behind The Boundary
The public surface already spans line-oriented I/O, HTTP, gRPC, WebSocket, Kafka, NATS, Redis Streams, RabbitMQ Streams, S3, and PostgreSQL patterns. Those integrations are useful precisely because they remain explicit about where buffering, transport retry, and external side effects live.
The practical design rule is simple: adapters may connect ByteOr to external systems, but they should not erase the difference between transport plumbing, deterministic pipeline execution, and governed enterprise actions.
Bounded Loop Model
EdgePlane-style loops are intended to stay bounded and inspectable. That means operators should be able to reason about which adapter owns ingress, which runtime surface owns execution, which policy layer owns approval, and which artifact path records what happened after the fact.