Session transition logic is built around progression through OMeT’s execution phases. A requester initiates the market, participants respond, and if action is not completed within the required boundary, the session advances to the next phase. Internal discussion captures this operating pressure directly: the requester defines the spread and minimum size, must act, and if not, the workflow moves to the next phase. In practical terms, the state machine prevents a session from lingering indefinitely in a negotiation condition when the protocol expects either execution, expiry, or progression.
Clock resets and time-zone handling are critical because phase boundaries must be deterministic across participants, environments, and trading days. Internal testing discussions note the need to validate extended sessions near boundary times, and also flag that local-time behavior, PC clocks, and daylight-saving shifts can affect perceived session timing. For an institutional venue, this means the authoritative clock should be platform-controlled, consistently timestamped, and separated from user-device assumptions wherever possible.
Phase expiry boundaries complete the framework. OMeT needs clear rules for when no new sessions may begin, when existing sessions may continue, and when balances are removed, retained, or transferred into the next executable state. Internal comments distinguish between “no new sessions” and the ability for existing sessions to continue, while also noting inconsistent behavior where balances were sometimes removed from the order book and sometimes not. The state machine’s job is to remove that ambiguity: every phase boundary should produce a predictable transition, an auditable timestamp, and a clear outcome for remaining orders, residual balances, and participant visibility.
