Time Model

Purpose and scope

The Time Model defines how temporal ordering and causality are represented within the infrastructure.

It specifies:

which temporal domains exist and what they mean;
which domain determines internal causal order;
how deterministic replay is guaranteed;
how time-dependent behavior is expressed without introducing hidden time-driven State.

This document does not redefine Event semantics, State derivation, or Queue semantics; it provides the temporal foundation that those models rely on. Capitalized terms are used as in Terminology.

Temporal domains

The infrastructure distinguishes two temporal domains. They represent different aspects of reality and must not be conflated.

Domain	Meaning	Role in causality
Event Time	When an occurrence happened externally (in a market, feed, or Venue)	External semantics only; does not determine internal State ordering
Processing Order	The strict internal sequence in which Events are applied	Canonical causal order for all State derivation and replay

Event Time

Event Time is a property of an Event that records when the corresponding occurrence happened in an external or market context.

Typical sources:

Venue-assigned timestamp;
market feed timestamp;
Venue-generated execution time.

Normative rules:

Event Time is metadata carried by an Event. It describes external semantics; it does not cause State changes by itself.
Event Time does not determine Processing Order. Two Events with the same Event Time are still ordered by their Event Stream position (Event Model).
Venue timestamps never override internal ordering. Processing Order is always determined by Event Stream position under the infrastructure's processing rules.

Processing Order

Processing Order is the strict, total internal ordering of Events within the Event Stream. It is the sole determinant of how State Transitions are applied.

Normative rules:

State Transitions occur strictly in Processing Order. No transition occurs before, after, or outside the sequential application of Events in Event Stream order.
Processing Order is independent of Event Time. A later-arriving Event that carries an earlier Event Time is still processed in its Event Stream position; it does not retroactively mutate prior derived State.
Processing Order is not determined by wall-clock time, thread scheduling, or OS timers. It is determined by the logical ordering rules applied to the Event Stream under Configuration.

Typical realizations of Processing Order:

monotonic sequence identifiers assigned at Event Stream recording;
deterministic replay indices from historical datasets;
causal ordering rules defined in Configuration.

Temporal separation

Event Time and Processing Order are not guaranteed to align.

Network latency, buffering, feed jitter, replay from historical data, or ordering rules may introduce divergence between when an Event occurred externally and when it is processed internally.

This separation is intentional and explicitly modeled. The infrastructure preserves external market semantics through Event Time (carried in Events) while guaranteeing deterministic internal behavior through Processing Order.

Causality rule

Every State Transition must be caused by a single processed Event in Processing Order.

Normative prohibitions:

No spontaneous State changes.
No implicit time-based mutations.
No background updates driven by wall-clock time, sleep intervals, or scheduler events outside the Event Stream.
No hidden state that evolves independently of Event processing.

All internal evolution is event-driven. Time observations may be carried inside Events (as Event Time or as data fields), but they do not bypass Processing Order as the causal mechanism.

Time-dependent behavior and deterministic replay

Some infrastructure behaviors are conceptually time-dependent—for example, rate-limit capacity recovery or the re-eligibility of pending outbound work after a delay.

Such behavior must be expressed in a way that remains compatible with deterministic replay under identical Event Stream and Configuration.

Normative rules:

Time observations that affect State must enter as Events or as Configuration. If a timestamp or elapsed-time computation is needed for a State transition, it must be carried in an Event already on the Event Stream (e.g. as a field of an existing Execution or Control Event) or encoded in Configuration-level rules—not derived from a private wall-clock read at runtime.
Rate-limit rules and capacity recovery must be expressed as deterministic functions of prior Event Stream history and Configuration. For example, a token-bucket rule whose replenishment rate is defined in Configuration and whose consumption is tracked through prior Events is fully deterministic and replayable. An independent timer that fires outside Event processing is not.
Future re-evaluation obligations must be expressed through canonical Events. Where current State and Configuration imply a future relevant control-time re-evaluation point—such as a rate-limit window that will recover while allowed outbound work remains pending—the Core may derive a Control Scheduling Obligation (see Terminology: Control Scheduling Obligation). This obligation is non-canonical: it does not enter the Event Stream and produces no State Transition by itself. The Runtime realizes the obligation by injecting a Control-Time Event into the Event Stream at the appropriate future position (see Terminology: Control-Time Event). The Core does not perform hidden wall-clock-driven State mutations; canonical State change arises only from processing injected Events in Processing Order.

Time and Execution Control

Queue Processing—the deterministic reevaluation of pending outbound work—runs within Event processing, not on an independent clock or timer loop.

Normative rules:

There is no separate runtime tick that advances Execution Control State independently of Event processing.
Queue Processing is reevaluated whenever an Event advances the Processing Order position in a way that is relevant to Execution Control (e.g. an Execution Event clearing an inflight slot, a market update, a Control-Time Event).
Time-dependent Execution Control constraints (e.g. rate limits) are enforced through deterministic rules applied during Event processing, not through background timers that mutate state outside the Event Stream.
Where current State and Configuration imply a future relevant control-time re-evaluation point, the Core may derive a Control Scheduling Obligation—a non-canonical, runtime-facing signal that produces no State Transition. The Runtime realizes this obligation by injecting a Control-Time Event into the Event Stream. That Event is then processed within Event processing exactly as any other Event.
Control-Time Events are sparse and deadline-style: each corresponds to a specific obligation derived from State + Configuration, not to a periodic timer, polling loop, or background callback. They are Control State semantics, not Venue semantics.

See Queue Processing for Execution Control evaluation rules.

Ordering principles (summary)

Rule	Statement
Market semantics	Preserved by Event Time carried in Events
Internal causality	Defined by Processing Order (Event Stream position)
State evolution	Follows Processing Order strictly; no retroactive mutation
Determinism	Same Event Stream + Configuration ➝ same derived State at every position
Wall-clock independence	Runtime timing must not define canonical infrastructure behavior

Deterministic replay

Given:

an identical Event Stream;
identical Configuration;
the same Processing Order;

the infrastructure must produce identical State Transitions at every Event Stream position, including all Execution Control derivations.

The Event Stream and Configuration together constitute the canonical input. No private runtime state, wall-clock read, or scheduler timing may influence replay outcomes.

Live and Backtesting contexts

The same temporal model applies in both Runtimes.

Runtime	How Processing Order is established
Live	Emerges from real-time Event delivery in arrival order under infrastructure recording rules
Backtesting	Reconstructed deterministically from historical datasets under the same ordering rules

In both contexts, State Transitions depend solely on Processing Order, and time-dependent behavior is expressed through Events and Configuration rather than through runtime timing.

Relationship to other documents

Terminology — canonical terms including Event Time, Processing Order, and State Transition.
Event Model — how Events carry Event Time as metadata; Processing Order as the canonical sequence.
State Model — State = f(Event Stream, Configuration); State Transitions in Processing Order.
Queue Processing — Execution Control reevaluation as part of Event processing, not a separate tick.