Replay jobs and audit

The current console exposes both replay execution and administrative history.

What replay is for

Replay lets you re-run historical traffic through a chosen encoding version and rule version.

This is useful when you want to answer questions like:

Replay jobs are listed with:

Field	Plain-English meaning	Why you care
`job_id`	The unique ID for this replay run	Useful when discussing a specific job
`job_type`	What kind of replay work Esper should perform	Controls the purpose of the run
`encoding_version`	Which encoding plan version to use	Lets you test a specific translation layer
`rule_version`	Which rule set version to use	Lets you test a specific policy state
`time_range_start`	Beginning of the historical window	Defines which past traffic is included
`time_range_end`	End of the historical window	Defines where the replay stops
`status`	Current state of the replay	Tells you whether to wait, inspect, or retry
`events_processed`	How many events were handled successfully	Main progress and throughput signal
`events_failed`	How many events could not be processed	Main signal that something may be wrong
`created_at`	When the replay was requested	Useful for operator history
`completed_at`	When the replay finished, if it has finished	Helps measure duration

Supported job types:

How to think about them:

Job type	Best use
`DryRun`	Safest first test of a proposed change
`StateRebuild`	Recompute saved state from historical traffic
`DecisionOnly`	Focus on decision outcomes rather than broader state rebuilds

Supported statuses:

The current form submits:

POST /tenants/{tenant_id}/replay-jobs

Required fields:

The app currently initializes the form with UTC timestamps and version 1 for both encoding and rules.

Good first replay habit:

The audit page lists tenant-scoped entries with:

The overview page also uses audit entry count as part of the tenant’s operational posture summary.

Field	Plain-English meaning	Why you care
`audit_entry_id`	Unique record of an admin action	Useful when tracing specific changes
`actor`	Who performed the action	Answers ownership questions
`action`	What changed	Quick summary of the mutation
`recorded_at`	When it happened	Helps line up a change with later outcomes

In the current product flow:

This is the cleanest way for a non-technical operator to explain a change: