How would you convince a team to invest time in an idempotency retrofit when the playbook "already works"?

Reframe the case around concrete, already-happening costs rather than abstract correctness — quantify actual instances of unnecessary handler-triggered restarts, time wasted by engineers second-guessing noisy "changed" output during real incidents, or a specific past incident where inaccurate check-mode output led to a wrong decision — since "it already works" is only true in the narrowest sense (it accomplishes its configuration goal), and the real argument is about the ongoing, measurable cost of noise and reduced trust in the tooling, not abstract idempotency purity.

"Already works" is true but incomplete: the playbook does successfully configure the target state — that's real and worth acknowledging, not dismissing. But "accomplishes its configuration goal" and "has no real cost" are different claims, and the case for investment rests on making the second, more specific cost visible, not re-litigating whether the playbook works at all.

Quantify concrete, already-happening costs: rather than an abstract argument about idempotency being "more correct," gather specific evidence — how many times has a handler-triggered restart happened unnecessarily due to a false "changed" report, how much engineer time has been spent during incidents second-guessing whether a noisy plan output reflects something real, has there been a specific incident where inaccurate check-mode output contributed to a wrong decision. Concrete numbers and specific incidents are far more persuasive than a general appeal to best practice.

Tie the case to something the team already cares about: if the team already cares about deploy velocity, frame the noise as slowing down confident deploys (having to manually verify a "changed" report is really meaningful); if the team cares about incident response time, frame it as noisy signal during exactly the moments clear signal matters most. Anchoring the argument to an existing priority is more effective than introducing "idempotency correctness" as a new, unfamiliar priority.

Propose the lowest-cost version of the fix first: per the earlier staged-retrofit approach (cheap changed_when fixes first, full module replacement only for high-priority tasks), leading with "this is a small, low-risk, incremental investment, not a big rewrite" removes the most common objection to this kind of work — that it sounds like a large, risky undertaking with unclear payoff. Making the actual ask small and concrete is often what actually gets it approved.

Offer to demonstrate value on one high-visibility task first: rather than asking for broad buy-in upfront, fixing one specific, well-chosen task (ideally one causing visible, recognized pain — a noisy handler restart people have already complained about) and showing the concrete before/after difference is a more convincing pitch than an abstract proposal, since it's evidence rather than a promise.

• "It already works" is true only in the narrow sense of accomplishing configuration — the case for investment is about a separate, ongoing cost (noise, reduced trust, wasted time) worth making concrete and specific.
• Quantifying actual instances of unnecessary restarts or wasted investigation time is far more persuasive than an abstract correctness argument.
• Tying the case to a priority the team already holds (deploy velocity, incident response clarity) is more effective than introducing idempotency as a new, unfamiliar priority.
• Proposing a small, low-risk first step (or demonstrating value on one high-visibility task) removes the most common objection that this sounds like a large, uncertain undertaking.

• Ansible: Controlling how modules report changes