Operators under pressure focus on the forward action — push the config, restart the node, reroute the traffic — and treat rollback as an afterthought to figure out if needed. But many RAN changes are not cleanly reversible: a parameter that took effect on reselection won't un-take-effect until UEs cycle, and a botched software activation may have no downgrade path at all. Discovering this mid-P1 turns a 10-minute fix into an hours-long crisis.
The discipline an agent should internalize: before any change, capture the exact prior state, confirm the reverse operation is supported and idempotent, and define the explicit signal that says 'roll back now' (a metric threshold, not a feeling). Only then execute forward. This makes the change reversible-by-construction and bounds worst-case blast radius.
Caveat: some actions are genuinely one-way (hardware swaps, irreversible migrations). For those, rollback discipline becomes pre-change validation and staged canarying instead — the principle is the same: never cross a one-way door without a verified exit or a deliberate decision that there isn't one.