Replay jobs

Replay is a supporting tool for validation when you want to ask:

• What would this policy have done on historical traffic?
• Did a change improve or break behavior?
• Can I validate safely before trusting live results?

Replay job structure

Current replay jobs expose:

• job_id: The unique identifier for the replay job.
• job_type: The kind of replay job Esper is running.
• encoding_version: The encoding version used during replay.
• rule_version: The rule or policy version used during replay.
• time_range_start: The beginning of the replay time range.
• time_range_end: The end of the replay time range.
• status: The current replay job status.
• events_processed: The number of events replayed successfully.
• events_failed: The number of events that failed during replay.
• created_at: When the replay job was created.
• completed_at: When the replay job finished.

This is still a lower-level operational surface and may evolve further as the builder model becomes first-class across more of the backend.