#ByteOr Enterprise Runtime Model

ByteOr Enterprise exposes the byteor execution substrate through a small number of operator verbs and tuning profiles. The important choice is the execution model: SingleRing for compact, tightly bounded flows, or LaneGraph for larger topologies with explicit lanes and roles.

#SingleRing

Use SingleRing when the deployment is a linear, tightly constrained path:

• the pipeline fits within the v1 staged ring limits,
• the producer model is single-producer,
• low-latency local execution matters more than topology flexibility.

SingleRing is the simplest operational path. It is the model behind one-shot bring-up (run --sp), direct ring snapshots, and the most mature runtime path for enterprise product apps.

#LaneGraph

Use LaneGraph when the deployment needs explicit ingress, egress, fanout, merge, or multi-role topologies.

LaneGraph adds flexibility, but the operator contract is narrower than the type system suggests. The current enterprise/runtime stack treats Events and FanoutBroadcast as the main production-facing lane families. Journal and SequencedSlots appear in the broader type system and snapshot tooling, but they should not be treated as default production choices without verifying the exact feature set and executor path in use.

#Operator verbs

The runtime surface is intentionally consistent across binaries:

• validate, describe, and dot inspect the spec.
• run executes a long-running runtime or one-shot bring-up.
• doctor checks host readiness for the requested tuning posture.
• snapshot captures ring or lane state.
• incident-bundle exports the reproducible bundle used for triage and replay.
• replay re-runs captured inputs under policy controls.

The product binaries reuse the same shape and then add their own stage or adapter resolution.

#Tuning profiles

The runtime recognizes three practical tuning postures:

• default: no privileged tuning assumptions; safest choice for local development and smoke tests.
• low-latency: asks for spin wait, balanced CPU placement, and mlockall, but may degrade when the host cannot honor those requests.
• isolated-core: assumes isolated CPUs, RT scheduling, and locked memory; this is the intended production posture when hard latency isolation matters.

Always pair a requested tuning profile with doctor on the target host. The runtime reports requested, applied, and degraded tuning separately so operators can distinguish a bad request shape from a host-readiness failure.

#Environment and policy

Enterprise execution is environment-aware:

• dev is permissive enough for iteration.
• staging and prod are where side-effecting stages are expected to require approval.
• replay policy is designed to default toward dry-run safety until a caller intentionally promotes execution.

That policy layer is described in ../guides/policy-and-approvals.md.