Ten automations in the CRM were switched off, and the system's own dependency check said nothing pointed at any of them. On that evidence all ten looked equally disposable. Half of them still could not be deleted.
- Five were removed and five were kept, for reasons recorded only in written notes. Three of the keeps are the deliberate way back if a replacement turns out to be wrong. One is a retirement that only a person can undo, so deleting it would have taken away a decision that was not the system's to make. One is the sole worked example of how a particular kind of automation is encoded, which is what makes building more of them possible at all.
- Every removed definition was saved in full before anything was deleted, and that precaution came out of the review itself rather than from caution. The sweep turned up an earlier deletion that nobody had recorded, while a design document still named the missing item as the way back. A promised rollback that does not exist is discovered only by someone who has already decided they need it.
- The first pass at the inventory was wrong in a way that looked right. A query capped at a thousand rows returned nine of ten and reported cleanly, because a capped result hides the marker saying more exists. It was caught only because an older summary said three where the fresh query said two, so the stale looking document was right and the new measurement was wrong. The checker now reads to the end and refuses to report at all if the two counts disagree.
- The rule that came out of it is about where the answer lives. A deletion candidate has to clear the written record, not just the system. The platform knows what points at a record. It does not know what a document says you must keep.