Track every automation in a registry — function, tool, last verified, failure signals
Maintain an automation registry listing each automation's function, tool, last verification date, failure indicators, and review cadence to prevent automation debt accumulation.
Why This Is a Rule
Automations are invisible infrastructure — they run in the background, doing work you've forgotten about, until they silently break. A broken automation produces no error in many cases; it simply stops delivering its output, and the absence goes unnoticed until the downstream consequence becomes visible (a report stops updating, a backup stops running, a notification stops firing).
An automation registry makes the invisible visible by documenting every active automation with five required fields: function (what it does), tool (what runs it), last verification date (when someone confirmed it still works), failure indicators (how you'd know it broke), and review cadence (how often to check it).
Without a registry, automations accumulate like unmonitored infrastructure: each one works when created, slowly drifts as conditions change, and eventually breaks silently. The registry prevents this by scheduling verification and defining what broken looks like for each automation.
When This Fires
- After creating any new automation (script, workflow, integration, scheduled task)
- During quarterly infrastructure reviews
- When an automation silently fails and you realize you had no monitoring
- Any time you wonder "do we still run that thing?"
Common Failure Mode
Creating automations without documenting them. Six months later, no one remembers what the cron job does, whether it's still needed, or how to tell if it's broken. The automation becomes orphaned infrastructure — running, consuming resources, potentially producing stale or wrong output, but invisible to everyone who should be monitoring it.
The Protocol
For every automation: (1) Add it to the registry immediately upon creation. (2) Record five fields: function (one sentence), tool/platform, last verification date, failure indicators (specific observables that mean it's broken), review cadence (monthly/quarterly). (3) On each review date: verify the automation is still running and producing correct output. Update the verification date. (4) If an automation's function is no longer needed → remove it from both the registry and the system. Dead automations that keep running are waste; dead automations that keep running wrong are hazards.