After a session, memory produces a tidy story: what you noticed, what you expected, what happened. Most of it is reconstructed. A session journal replaces that story with a record — automatic events from the monitor, interleaved with short notes you wrote at the time. This article covers what to log, how to structure entries, and how to review the journal so it changes your next session.
Why a journal, and why during the session
Two practices from outside trading are useful here.
In incident response, the Google SRE book's chapter on managing incidents (external site) describes the incident commander's most important responsibility as keeping "a living incident document". It can be messy, but it must be functional, and it is retained for postmortem analysis afterwards. The point is that it is written while things happen, not reconstructed later.
The same book's chapter on postmortem culture (external site) adds the second practice: review focused on contributing causes, not blame. "You can't 'fix' people, but you can fix systems and processes." A research journal is reviewed the same way — you are diagnosing rules, thresholds and routines, not grading yourself.
Supervisors also treat records as part of operating automated systems. ESMA's guidelines on automated trading (external site) ask investment firms to keep records of key decisions, testing methodologies, test results and periodic reviews of their trading algorithms, and FINRA's algorithmic trading guidance (external site) lists review of trading activity after a strategy is in place among effective practices. Those rules apply to regulated firms, not to an individual researcher, but the reasoning carries over: if you cannot reconstruct why a rule changed, you cannot evaluate it.
Two streams: automatic events and your notes
A useful journal has two streams sharing one timeline.
Automatic events are written by the monitor, never edited:
- rule firings, with rule name, instrument, value, threshold and severity;
- suppressed firings during a cooldown;
- session markers: replay start, pause, speed change, end;
- configuration changes: rule added, threshold edited, watchlist membership changed.
Your notes are short and timestamped:
- what you expected before something happened;
- what you checked when an alert fired, and what you concluded;
- anything you noticed that no rule caught;
- decisions about the setup ("will widen cooldown after session").
Keep the streams visibly distinct. The value of the journal comes from comparing them: what the system saw versus what you saw.
A structure for each entry
Consistent fields make review fast. A minimal schema:
| Field | Auto events | Notes |
|---|---|---|
| Time | Replay bar and wall-clock time | Same |
| Source | Rule or system | "Note" |
| Instrument | Yes | If relevant |
| Content | Value, threshold, severity | One or two sentences |
| Tag | Rule severity | One of: expectation, check, miss, decision |
| Link | — | Optional reference to the event it responds to |
Four note tags cover most needs. Expectation is written before an event. Check records what you looked at after an alert. Miss records something relevant no rule flagged. Decision records an intended change. During review, the tags become filters.
Sample journal excerpt
The excerpt below is from a demo replay on synthetic instruments. All values are illustrative, not market data.
DEMO REPLAY · synthetic session S-031 · speed 4×
bar 001 09:30 SYSTEM Replay started. Watchlists: Contraction (9), Regime watch (6)
bar 004 09:33 NOTE [expectation] SYN-12 range 98.00–102.00; expect quiet first hour.
bar 058 10:27 RULE SYN-12 volatility_above ATR 0.61 > 0.60 severity=medium
bar 059 10:28 NOTE [check] Range intact, price 100.40. Volatility rule may be too tight.
bar 071 10:40 RULE SYN-12 volatility_above suppressed (cooldown 20 bars)
bar 140 11:49 RULE SYN-12 volatility_above ATR 0.72 > 0.60 severity=medium
bar 141 11:50 NOTE [check] Card C condition met: wider range, no direction.
bar 197 12:46 NOTE [miss] SYN-07 dropped 1.1% in 6 bars; no rule on Regime watch covers this.
bar 251 13:40 RULE SYN-12 level_cross close 102.14 > 102.00 severity=high
bar 252 13:41 RULE SYN-12 volume_spike 1.7× 20-bar avg severity=medium
bar 253 13:42 NOTE [check] Card A conditions met. Regime label unchanged.
bar 390 16:00 SYSTEM Replay ended. 4 firings, 1 suppressed, 0 config changes.
bar 390 16:00 NOTE [decision] Raise SYN-12 volatility threshold to 0.65; add % move rule to Regime watch.In thirteen lines the excerpt contains a confirmed expectation, a rule that is possibly too sensitive, a gap in coverage and two concrete configuration changes. None of that would survive a memory-only review.
Reviewing the journal after a session
Review within a day, while context is fresh, and use a fixed set of questions so reviews are comparable across sessions.
- Firings versus actions. How many alerts fired, and after how many did you record a check that led somewhere? In the excerpt: 4 firings, 3 checks, 2 of which matched a scenario card. One firing (bar 058) was early noise.
- Misses. List every miss note. Each one is a candidate rule or a reason to change a watchlist. Bar 197 is one.
- Expectations. Compare each expectation note with what happened. Not to score accuracy, but to see whether your expectations are shaping which alerts you take seriously.
- Suppressions. Were suppressed firings genuinely redundant? If a suppressed event mattered, the cooldown is too long.
- Decisions. Turn each decision note into a single, specific configuration change, and make it before the next session so the change is logged automatically.
A useful summary line for the session: "S-031: 4 firings / 3 checks / 1 miss / 2 changes." After ten sessions those lines form a small dataset about your own monitoring.
Common journal mistakes
- Logging everything manually. If you type rule firings yourself, you will stop. Let the system write events; keep your notes for judgment.
- Writing notes only after the session. That brings back reconstruction. A three-word note at the time beats a paragraph later.
- Editing old entries. Correct with a new, timestamped note instead. The record of what you thought then is the useful part.
- Reviewing without changing anything. A review that ends without a decision, or with a deliberate "no change", has not finished.
- Blaming yourself. Following the postmortem principle, ask what in the setup made the miss likely, not who missed it.
Fitting the journal into an automated research workflow
If you are developing an ai trading bot or rules-based strategy elsewhere, a monitoring journal gives you an independent record of market conditions during the same period, against which strategy logs can be compared. Export the journal as CSV or JSON and keep it with the rule configuration that produced it.
Noctivex keeps this journal inside the workspace, on synthetic data, with in-app notifications only. It does not connect to a brokerage, hold funds or execute trades. For how the alerts in the journal are designed, see Designing Alerts That Reduce Noise.