State Is Not a Variable: Defining State Semantics for Quant Operators in Rust

Document Statement

This is not a Rust tutorial.

This is the second article in the Rust Quant Operator series, focusing on defining state as an explicit engineering object rather than an implementation detail.

All code exists only to validate definitions.

Author

yuer
Author of EDCA OS
Proposer of controllable AI standards

Engineering repository:
https://github.com/yuer-dsl

Contact: [e-mail]

1. Why state cannot remain implicit

Once operators are defined as schedulable execution units, a fundamental question emerges:

Where does information across executions live?

Common practices today include:

struct fields without semantic contracts

hidden globals

embedding state into inputs

All of these make state semantics implicit, which breaks down for:

replay and backtesting

batch vs step-wise execution

operator reuse

failure recovery

1. Core definition: State

In this document, State is defined as:

Data that persists across executions and whose lifecycle is constrained by execution semantics.

State is not a variable, cache, or input fragment.

1. Ownership of state

This article makes a conservative choice:

State responsibility belongs to the operator, not the execution environment.

Execution environments should not interpret business semantics.

This defines responsibility, not storage location.

1. Minimal state model (v0.1) OperatorState trait pub trait OperatorState { fn reset(&mut self); }

StatefulOperator extension
pub trait StatefulOperator: Operator {
type State: OperatorState;

fn state(&mut self) -> &mut Self::State;

}

1. Minimal stateful example pub struct CountState { count: usize, }

impl OperatorState for CountState {
fn reset(&mut self) {
self.count = 0;
}
}

pub struct Counter {
state: CountState,
}

impl Operator<&[f64], usize> for Counter {
type Error = ();

fn execute(&mut self, input: &[f64]) -> Result<usize, Self::Error> {
    self.state.count += input.len();
    Ok(self.state.count)
}

}

This example demonstrates:

accumulation across executions

output dependence on execution order

explicit state responsibility