Write-back safety

You are usually the person asked to make somebody else's idea safe, on top of a job you already have. This is the specification we would want if we were in your chair, and you are welcome to hand it to any vendor including us.

The specification

• Approver granularity. Per play, per field, and per value threshold. A change to a delivery date and a change to a price are not the same risk and should not share an approval path.
• Dry run mandatory. Every write path runs in shadow first, producing the exact diff it would have applied, for a period you specify. Nothing is enabled until you have read one.
• Prior value retention. Thirty days minimum. Without the prior value, rollback is a rumour.
• Rollback window. Any approved write reversible within the retention window, in one action, by your team, without the vendor.
• Role separation. Builder and approver roles strictly distinct. Vendor engineers hold builder only. Enforce it in the identity provider, not in policy.
• Rate limits. A cap on writes per play per day, so a misconfiguration is a small incident rather than a large one.
• Complete audit. Who approved, when, on what evidence, what changed, and what it was before. Exportable to your SIEM.

The argument for the CFO

Insight that cannot become an action is entertainment. A deployment that produces a weekly export is a deployment that will be abandoned by month six, because the cost of acting on it falls entirely on people who did not ask for it. Write-back is what converts analysis into outcome, and the controls above are what make it acceptable.