What has to be logged during a trading day so the day can be replayed instead of remembered? This note lists that record, using one session of the E-mini S&P 500 future as the public example, and says which omissions make the replay impossible.
A memory is not a log
After a session, people remember a chart and a mood. A replay needs the messages, the order of the messages, the clocks that stamped them, and the versions of the code that read them. If any of those are missing, the team can still tell a story about the day. It cannot reproduce the story. The difference matters the moment two participants disagree. The log is the way the disagreement becomes a question with an answer, rather than a contest of recollections.
The log is also the way a later test avoids peeking. A signal replayed in March should see the March log as it was, not a log rewritten after a specification was better understood. Corrections can be stored beside the original. Replacing the original destroys the ability to ask what the system actually saw. A day that cannot be replayed is a day that cannot be audited, no matter how carefully someone describes it in prose.
A replayable log contains the messages, their order, the named clocks that stamped them, and the versions of the code that consumed them, so a later run can reproduce what the system saw.
One futures session on disk
Take a single session in the E-mini S&P 500 future. A usable log of that session can name the feed, the channel, the sequence numbers, the raw messages or a lossless encoding of them, and the receipt stamps with the clock identified. It can also name the build of the decoder that ran. With those pieces, another build can be aimed at the same bytes and compared. Without the sequence numbers, a gap can be smoothed over and the comparison will look better than the day was.
Internal products belong in the log when they are part of what a strategy saw. If the strategy read a normalized top of book rather than the raw update, the normalized record is part of the day. Logging only the raw feed and hoping to recreate the normalization later works only if the normalization code is the same version and is deterministic. Hope is not a log. Write the record the consumer saw, and write the version. The E-mini session is a good example because the feed is specified and the book can change many times between two trades. A log of trades alone cannot explain a signal that read quotes.
What can be left out should be decided in advance, not at midnight when disks are full. Heartbeats that carry no market information might be summarized rather than stored verbatim, but the summary has to preserve the ability to see a stall. A stall that is deleted from the log becomes a smooth tape. The policy belongs in the same note as the replay procedure. A session is not replayable because the files are large. It is replayable because a second run can ask a precise question and get a determinate answer.
A log does not bless the day
A complete log of an E-mini session does not mean the session was handled well. It means the handling can be examined. Examination may find a gap that was ignored, a clock that degraded, or a decoder version that does not match the specification. Those findings are the reward for having logged. A culture that logs only the flattering fields will replay a flattering day. The replay will agree with itself and disagree with the venue.
Logging a day so it can be replayed is an engineering requirement that sits under any later argument about signals. The argument may be abandoned. The log should still exist, because the abandoned argument is exactly the one people will misremember. The futures session is the example. The standard is the ability to play it again.
This piece does not claim that a logged day was handled correctly, that a futures session can be predicted from its log, or that storage by itself is a review. It lists what the record must hold before the word replay is honest.
