#Execution Models

ByteOr supports two execution models: SingleRing and LaneGraph. Both are authored through the same source contract (PipelinePlanV2) and compiled through the same validation and lowering pipeline. The execution target is an explicit choice, not an implicit consequence of the spec shape.

#SingleRing

SingleRing is ordered linear execution. Stages run in topological order with explicit dependencies, and the runtime guarantees ordering within a single shard.

#When to Use SingleRing

• Straightforward ordered processing pipelines
• Cases where stage ordering is the primary correctness requirement
• Lower complexity requirements where branching and fanout are not needed

#SingleRing Source Contract

A SingleRing plan contains:

• Ingress and egress boundaries — one of each
• Stages in topological order — with explicit dependency lists
• Execution constraints — shard count, ordering mode, producer mode, scheduling mode, shard key

#SingleRing Constraints

SingleRing does not use per-edge lane intents. Ordering and data flow are expressed through stage dependencies and execution constraints.

#LaneGraph

LaneGraph is a directed graph of lanes and roles supporting branching, fanout, merge, and richer boundary routing.

#When to Use LaneGraph

• Complex topologies with branching or fanout
• Pipelines that need fan-in (merge) patterns
• Cases requiring explicit lane-kind selection per connection
• Richer boundary routing policies

#LaneGraph Source Contract

A LaneGraph plan contains:

• Graph connections — stage-to-stage, ingress-to-stage, and stage-to-egress
• Lane intents — per-connection lane-kind selection
• Boundary lane policy — routing behavior at ingress and egress boundaries
• on_full policy — backpressure behavior (Block or Drop)

#Lane Kinds

#Compiler-Inserted Infrastructure

During lowering, the compiler may insert additional infrastructure to satisfy lane-kind constraints:

• Bridges — inserted to preserve lane-kind boundaries between stages
• Routers — inserted for fanout patterns
• Merges — inserted for fan-in patterns

These are transparent to the spec author. The source contract describes intent; the compiler produces the execution plan.

#Shared Authoring Surface

Both models use PipelinePlanV2 as the source contract:

• Pipeline name — identifies the pipeline
• Execution target — explicit SingleRing or LaneGraph selection
• Stage catalog — shared across both models
• Boundary catalog — shared across both models
• Target-specific payload — SingleRing constraints or LaneGraph connections

The Cloud editor can project the same underlying plan as a linear SingleRing canvas or a LaneGraph topology canvas, switching projection without changing the draft document.

#Validation and Lowering

Both models pass through the same validation and compilation pipeline:

1. Parse — decode the source plan
2. Validate — check structural and semantic rules for the chosen target
3. Lower — compile into the canonical execution format
4. Emit — produce the immutable pipeline version

Validation catches errors like self-dependencies, invalid constraint combinations, unsupported lane kinds, and topology violations before any execution begins.