Batch Is Not a Loop: Batch Consistency and Vectorized Execution Semantics

Why for-loops Are Not Batch Processing

Document Statement

This is not a Rust tutorial.

This is the fourth article in the Rust Quant Operator series, focused on defining batch execution as a first-class semantic constraint.

Author

yuer
Author of EDCA OS
Proposer of controllable AI standards

Repository: https://github.com/yuer-dsl

Contact: [e-mail]

1. Why batch ≠ loop

Batch execution is often implemented as:

for x in data {
operator.apply(x);
}

This is semantically incorrect once consistency matters.

1. Definition: Batch Consistency

Batch Consistency means:
under identical time semantics and inputs,
batch execution and step execution must be semantically equivalent.

Equivalent does not mean identical execution paths.

1. Why loops break consistency

Implicit assumptions:

commutative state updates

per-step time progression

irrelevant intermediate states

These assumptions fail for windowed and stateful operators.

1. Batch as a semantic object

pub struct BatchInput {
pub values: &[T],
pub times: &[Time],
}

1. BatchOperator interface

pub trait BatchOperator {
fn apply_batch(
&mut self,
input: BatchInput,
) -> OperatorResult;
}

Batch execution is not a wrapper—it is a semantic commitment.

1. Time semantics are preserved

Batch execution must not weaken time ordering.

1. Vectorization under constraints

Vectorization is an implementation strategy.
Consistency is non-negotiable.

1. Invariants

step ≡ batch semantics

time ordering preserved

no hidden state shortcuts

1. Artifacts frozen

Batch Consistency

BatchInput

BatchOperator

Vectorization invariants

1. Roadmap hook

The final article will generalize the operator model beyond quant systems.

If someone argues that
“batch execution should behave differently,”
then this document has succeeded.