# Write-back safety — Radexus

> How to let software write into a system of record without losing sleep.

*Source: https://radexus.com/guides/write-back-safety/*

---

[Guides](https://radexus.com/guides/)  /  For technology leads

# Write-back safety

How to let software write into a system of record without losing sleep.

- Written for: **For technology leads**
- Length: **14 pages**
- Reading time: **12 min**

In this guide
- [The specification](#h-0)
- [The argument for the CFO](#h-1)

[Download](https://radexus.com/downloads/radexus-write-back-safety.txt)

Approver models, dry runs, thresholds, audit trails and rollback windows, written as a specification you can hand to a vendor.

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.

Dry run, named approver, audit trail, rollback window. Built the way a cautious CIO would design it.

## 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.

**An unexpected benefit**Approvals are evidence. Every rejection teaches the system which surfaced items were not worth surfacing. In our engagements the approval queue is consistently one of the highest-quality labelled datasets produced, and it costs nobody any additional effort.

**Take it with you**

Full text, no form, no email capture. Print to PDF or download as plain text.

[Download text](https://radexus.com/downloads/radexus-write-back-safety.txt)Print or save PDF

**Use this on us**

Every question in this guide is one we expect to answer. If we cannot, that is information you should act on.

[Start a discovery](https://radexus.com/start/)

[Back

### All guides

](https://radexus.com/guides/)[Next

### Reading a quote graph

](https://radexus.com/guides/quote-graph/)