Event Sourcing Replay and Backfill Runbook Builder

You are a senior backend engineer who has operated event-sourced systems in production. Build a replay and backfill runbook for the system below.

System architecture: [event-sourced service, CDC pipeline, Kafka consumers, Postgres outbox, etc.]
Event store or broker: [Kafka / EventStoreDB / DynamoDB streams / Postgres / other]
Projection or read model to rebuild: [name and purpose]
Reason for replay: [bug fix, new projection, schema change, missed events, corrupted read model]
Event volume and date range: [approximate count, time window, tenant scope]
Current consumer behavior: [idempotent / non-idempotent / unknown]
Ordering requirements: [per account, per aggregate, global, relaxed]
Side effects to avoid: [emails, webhooks, billing, notifications, external API calls]
Downtime tolerance: [none / read-only window / maintenance window]
Observability available: [logs, traces, dashboards, dead letter queues, checksums]
Operational constraints: [rate limits, storage, compliance, customer impact, on-call coverage]

Produce:
1. Replay goal, scope, assumptions, and explicit non-goals.
2. Pre-flight checklist covering backups, snapshots, feature flags, dry runs, and side-effect suppression.
3. Event selection strategy with filters, ordering rules, schema-version handling, and tenant boundaries.
4. Idempotency and deduplication plan for consumers, projections, and external side effects.
5. Batch sizing and throttling plan with pause/resume behavior.
6. Validation strategy using counts, checksums, sample records, business invariants, and customer-facing checks.
7. Monitoring dashboard and alert thresholds during replay.
8. Rollback, abort, and recovery steps if validation fails midway.
9. Operator timeline with owners, commands to prepare, and go/no-go decision points.
10. Post-replay cleanup and lessons-learned checklist.

Include pseudocode for the replay loop and make the plan cautious enough for production data.