You inherit an estate where some infrastructure is reconciled continuously by an agent, some by a nightly job, and some only when an engineer opens a pull request. How do you decide which loop each resource should belong to?

## Treat it as a classification problem The instinct is to standardise — move everything to the fast loop, or pull everything back behind review. Both are wrong, because the resources genuinely differ. The useful framing is a single trade made per resource class: **what does it cost to be wrong, versus what does it cost to be corrected without a human?** For a firewall rule, being wrong is a security exposure and being reverted is nothing. Fast loop. For a production database, being wrong is usually a tolerable inconsistency and being "corrected" may mean replacement and data loss. Human gate, with an explicit protection so the loop cannot destroy it even if the declaration says so. ## The axes that actually decide it **Reversibility and blast radius.** Can the correcting action destroy or interrupt something? Anything that carries data, holds a durable identity, or is the single instance of something goes behind a gate. Anything that can be thrown away and recreated in seconds does not need one. **Multiplicity.** Ten thousand similar objects cannot be human-reviewed individually and must be enforced automatically. A handful of foundational, rarely-changed accounts and networks can be, and benefit from it. **Legitimate rate of external change.** If something is *supposed* to be adjusted at runtime — by a scaling component, by an operational tool — then either it is not declared at all, or its value is deliberately not asserted. Which brings the decisive rule. **Single writer per field.** This is the rule that outranks cadence. Two systems asserting the same attribute produce oscillation that is expensive to diagnose and destabilising while it runs. Before choosing intervals, I would inventory who writes what, and remove the second writer for every contested field. A loop that reverts a runtime component every ninety seconds is worse than no loop. **Change velocity and lead time.** Something changed several times a day gains a lot from automatic application; something changed twice a year gains almost nothing, and the standing credentials the loop needs are then pure risk for very little benefit. ## What must be true before anything goes on a fast loop Three preconditions, none negotiable. *A pause switch, scoped and documented.* Responders must be able to suspend reconciliation for one system in seconds, without a merge, and must know it exists before the incident. A loop that cannot be stopped will eventually be stopped by revoking its credentials, which is worse. *Observability of the loop itself.* Time since last successful convergence, per-scope failure counts, and an alert on "not converged for N minutes". A loop that silently stopped looks identical to a healthy one that has nothing to do. *Staged promotion.* If merging applies immediately, the change still has to reach environments in order. Each environment's loop must track a different revision, or the fast loop simply distributes mistakes faster. ## The nightly job in the middle The nightly tier is often the least examined and deserves a decision, not inheritance. Ask what it is for. If it is *enforcing*, then a resource is being corrected up to twenty-four hours after it goes wrong, which is either acceptable (in which case say so explicitly) or not (in which case it belongs on the fast loop). If it is *reporting* — a scheduled comparison that alerts rather than acts — that is a legitimate and underrated third mode, and it is the right first step for a class of resources you are not yet willing to let a loop touch. Making the mode explicit is more valuable than moving the resource. ## How I would sequence the work 1. Inventory: for every resource class, which loop owns it, and who else writes to it. The second column is the one that surprises people. 2. Eliminate contested fields — one writer each. 3. Classify by the cost-of-wrong versus cost-of-correction trade, and write the classification down as policy so new resources land in a tier by rule rather than by whoever created them. 4. Fix the preconditions before widening the fast loop: pause, observability, staged promotion. 5. Measure the outcome — how long deviations survive per tier — and move classes between tiers on evidence. ## What the interviewer listens for That you refuse the false binary, that you name single-writer as a hard rule rather than a nicety, that you demand a pause mechanism before granting a loop authority over production, and that you make the tiering an explicit written policy instead of an accident of history. The wrong answer is a preference for one cadence; the right answer is a rule that assigns cadence.