Ralph Loop Note: Replay Dedup By Observation Time

Date: 2026-03-16 Focus: data quality

Bottleneck

research/prepare_replay.py was pairing duplicate rows for the same ticker from the same scan timestamp as if they were sequential observations. That created replay rows with _horizon_seconds = 0, which diluted the replay set with non-moves and made the input quality look better than it was.

Change

1. Added same-timestamp collapse in pair_next_observation() so each ticker is paired only across distinct observation times.
2. Added zero_horizon_rows to the replay input summary so this failure mode is visible in future loop status checks.
3. Added focused tests covering duplicate-timestamp collapse and the new summary field.
4. Documented the replay dedup rule in research/README.md.

Validation

Commands:

PYTHONPATH=. pytest -q tests/test_prepare_replay.py tests/test_research_search.py
python3 research/prepare_replay.py --db data/unicorn.db --out research/replay_rows.jsonl

Results:

8 passed in 0.39s
replay_rows: 1280
zero_horizon_rows: 0
unique_tickers: 36
actionable_signal_rows: 0
review_signal_rows: 0

Before this fix, the current replay file contained 396 zero-horizon rows caused by same-timestamp duplicate pairs.

Why This Matters

This does not create trades. It removes a source of replay noise so future sleeve and eventful-observation work is measured on distinct market observations rather than duplicate journal artifacts.

The next visible bottleneck is now cleaner: replay quality is limited by having zero actionable or review rows in the current replay input, not by duplicate pairing.