Unthought.

The automation register

Six fields per automation, kept with the code, so that what runs is knowable and switching something off is possible.

The state most businesses arrive in is a collection of processes that ran dependably until whoever built them moved on. Nobody can say what sets them off, what they write to, or what breaks if they stop — so nobody is willing to switch them off, and nobody is able to change them.

Every automation is recorded with six things: what triggers it, what it reads, what it writes, what it sends, where its failures surface, and who is accountable for it. Six fields is small enough that they get filled in and specific enough that the entry is worth reading, and the last two are the ones invariably missing when this is attempted informally.

The register lives with the code instead of in a document beside it. A separate document is updated when somebody remembers; an entry in the repository is updated when the automation changes, because the change and the record are the same commit and the same review.

Accountability names a person, not a team. Teams do not read alerts, notice silence, or make the decision to retire something, and an owner field containing a department name is functionally identical to an empty one.

Blast radius is recorded as two plain answers: what happens if this runs twice, and what happens if it does not run for a week. Both are cheapest to answer while the automation is being built and its behavior is fresh, and both are what somebody actually needs during an incident, when neither is derivable at speed from the code.

The credentials each automation depends on are listed, because credential rotation is among the most common reasons a working automation stops. The connection between a key rotated on Tuesday and a job that has been quietly failing since Tuesday is rarely made quickly, and the list is what makes it a lookup instead of an investigation.

Decommissioning is a supported operation, not an act of courage. An automation is switched off, with the date recorded, before it is deleted — so that whatever depended on it surfaces while the change is still fresh and reversing it is one action, not an archaeology exercise.

The register is reviewed on a cadence: what has not run, what is failing quietly, what no longer serves a purpose anybody can name. Without a standing review it becomes another artifact that describes the system as it was understood at the moment it was written.

The count itself is the most useful thing the register produces. A business that can see it has eleven automations, and can name what four of them are for, is in a position to retire the other seven. A business that cannot see the number will keep adding to it, since every individual addition is small and the total is invisible.

Exclusions

What this does not cover.

  • Automations with no named person accountable for them.
  • Registers maintained as a document separate from the code they describe.
  • Deleting an automation outright without first disabling it and observing what depended on it.