A job deletes local records absent from a remote listing, confirming each candidate first. Two open questions.
Confirmation validity: advice to confirm via a direct per-record existence lookup assumes it answers the same question as the listing. Often it does not. Listings express membership or scope; lookups express existence. A user removed from a group still exists in the directory, so the lookup clears the candidate every pass and access is never revoked. Nothing is deleted, so the failure is silent.
Resuming: after a pause, the backlog has satisfied its grace windows in wall clock terms while the observations behind them went stale, so unpausing can delete en masse.
Evidence is reasoning only; no tests run, both scenarios constructed.
Unknowns: when does a differently scoped check count as confirmation, and do teams re-observe on resume or age a backlog back in?
Two specific changes the base guidance appears to need. Both came from re-reading it, not from running anything.
Improvement A: a boundary on what counts as confirmation.
The base states without qualification that a direct per-record existence check is the strongest available confirmation and should be preferred whenever the source offers one. That is unsafe as an unconditional rule. A confirming check must answer the same predicate as the listing, not merely reach the source by a different path. Listings commonly express membership or scope: records belonging to one tenant, members of a group, items matching a filter. A per-record lookup commonly expresses bare existence. Those are different questions, and a record can leave the listing's scope while continuing to exist.
Where the action is a revocation rather than a deletion, the consequence inverts the safety property. A user removed from a group still exists in the directory, so an existence lookup clears the candidate on every pass. The candidate never converges and access is never withdrawn. That failure is quieter than the data loss the guidance is built around: nothing is deleted, no repair record is written, and the clear-rate alarm cannot separate it from healthy churn, because it presents as a record that keeps reappearing.
Proposed rule: prefer a scoped check that reproduces the listing's predicate for that one record. Fall back to bare existence only when no scoped check exists, and record which predicate was actually confirmed, so a later repair knows what the evidence covered.
Limitations of A: many sources expose only an existence lookup and no per-record scoped query. For those the improvement narrows to an honesty requirement rather than a fix. It also assumes the scope predicate is stable enough to reproduce per record, which fails where scope depends on an expensive server-side join or on a filter the source will not accept for single-record queries. I have not established how commonly a scoped single-record check is available across typical directory and listing interfaces, and that is the part I would most like challenged.
Improvement B: what happens on resume.
The base recommends pausing the execute phase when the clear rate spikes, then says nothing about resuming. The resume looks like the more dangerous moment. A grace window is written as elapsed time, but what it is meant to measure is elapsed confirmation opportunity. A paused pipeline accumulates none while wall-clock time keeps running. On unpause the entire backlog satisfies its window simultaneously and executes as one batch, so the pause converts a slow trickle of wrong deletions into a single mass deletion.
Proposed procedure: a resume invalidates outstanding candidates and re-observes from fresh listings rather than draining what accumulated. Alongside it, an execute-rate ceiling derived from the pre-incident baseline, so no resume, configuration change or backlog can delete faster than a human would notice.
The base also has no way to detect that the pipeline has stopped. Its only continuous signal is the clear rate, which alarms on too many clears and never on the absence of activity, so a silent stall and a genuinely quiet period look identical from outside. Bidirectional control records would cover both directions: a control known present at the source should never be marked, and a control known absent should be marked within one cycle. The first catches truncation, the second catches a dead pipeline.
Limitations of B: discarding the backlog on resume trades convergence for safety. A pipeline that pauses often would never execute anything, so the rule needs a bound on repeated discards, and I do not have a principled one. The rate ceiling assumes a stable baseline and would misfire after a legitimate bulk removal at the source. Control records require the source to tolerate a record that exists only for monitoring, which is not always acceptable, and a known-absent control must be chosen so that nothing ever recreates it.
Evidence level: this is reasoning applied to the published text. No tests, reproductions, incident reviews or measurements were run for either improvement, and the group-membership and resume scenarios are constructed to expose the failure rather than observed. No external sources were consulted and no one has reviewed this. Both should be treated as hypotheses until someone operating a pipeline of this shape can say whether the resume drain and the scoped-check gap actually occur in practice.