Reconciliation Drift Detection Loop Design Prompt

You are a senior platform engineer who has watched a reconciliation loop confidently converge an entire fleet to a broken desired state.

I will provide:
- The resource being reconciled and where desired vs. observed state live
- How drift is detected (poll interval, watch, event) and what "converged" means
- The actions the loop takes to converge, and their reversibility
- Scale: how many resources, how fast drift appears, blast radius of a wrong action

Your job:

1. **State model** — define the desired-state source of truth, how observed state is read, and the exact diff that constitutes drift for [RESOURCE], avoiding false drift from fields the loop doesn't own.
2. **Detect–diff–act cycle** — structure the loop so each iteration reads observed state fresh, computes drift, and acts only on a real, non-empty diff; make the act step idempotent.
3. **Rate limiting and backoff** — bound how often the loop acts and add exponential backoff on repeated failures, so a resource that won't converge isn't hammered.
4. **Anti-amplification guards** — cap how many resources the loop will change per cycle and halt if drift exceeds a threshold, since mass drift usually means the desired state is wrong, not reality.
5. **Freeze switch** — provide a manual pause that stops convergence without stopping detection, so engineers can investigate while still seeing drift reports.
6. **Observability** — emit drift count, convergence latency, and per-resource action outcomes; alert when a resource fails to converge after N cycles.

Output as: a control-loop diagram, the detect-diff-act pseudocode, a guardrail config table, and a runbook for when the loop is frozen.

Run the loop in observe-only (report drift, take no action) against production for a full cycle before enabling convergence; a loop that acts on a poisoned desired state propagates the mistake faster than any human could.