Skip to content

Knowledge base

Automation catalog

Why a software factory writes its standing automations down as a catalog, and what the auditor job in that catalog checks.

Written by

Updated:

Glossary 33

A software factory is more than the agent that writes code. Around it run standing jobs that nobody starts by hand: a reviewer that reads every pull request before a person does, a verifier that checks what actually landed after a merge, an incident responder, an auditor. The automation catalog is that set, with each job defined in a file in the repository: its trigger, the work it does and what it may change.

Why write the automations down as a catalog?

With each automation in a file, a person can see what runs, when and with which rights, and a change to it goes through review like code. The catalog and the harness together are the platform a factory team builds, and the same trap applies as to any platform: build the smallest set that removes real friction.

What does an auditor in the catalog do?

It inspects the other automations on a schedule and improves the instructions they run on. A weekly auditor pulls the week’s pull requests, the issues automations filed and the bugs verifiers raised, then asks whether each automation finished its job, failed repeatedly on the same change or did unnecessary work. A useful rule from a factory built in the open: the auditor saves each audit under a dated name and never overwrites the previous one, so every past verdict stays readable. Where the auditor rewrites another automation’s instructions, treat the rewrite as a proposed change: a person reviews the diff before it goes live.

Resources

Tools and repositories