Installed Is Not Configured Is Not Running Is Not Used

It was installed. It was configured. It was documented. It was scheduled. And it had never run once.

The tool in question was a background sync service, set up to mirror a working corpus between two machines. Every box you would check was checked. There was a config file. There was a scheduled task. There was a page in the tooling register describing what it did and why we needed it. Anyone auditing the setup would have ticked it off and moved on.

It had not moved a single byte. The schedule pointed at an entry point that never acquired the permission it needed, and nothing in the system was watching for the difference between “this job is scheduled” and “this job produced an effect”.

Four states, not one

The reason this survives so long in so many workspaces is that we use a single word for four different conditions. A tool is described as “set up”, and that word covers a ladder:

1. Installed — the binary is on disk and resolves on the PATH.
2. Configured — it has credentials, a target, and settings that match reality.
3. Running — it actually executes, on its schedule, without erroring out.
4. Used — something downstream consumes its output and would notice if it stopped.

Each rung is a different failure. A tool can sit on rung one for months while everyone involved believes it is on rung four. Nothing complains, because nothing was ever asked to.

Most tooling registers I have seen record rung one and imply rung four. They are inventories of intent.

The field that makes it honest

The fix was not a better process. It was one field, and the fact that it refuses to accept a date.

Every entry in the register carries a last verified field, and that field does not take “2026-08-28”. It takes the exact command that was run and what the command returned. Not “checked, working”. The literal invocation, and its literal output.

This is a small constraint with a disproportionate effect, because it is very hard to fill in dishonestly by accident. You cannot paste a command you did not run. If the only thing you can produce is the installer's success message, that is what goes in the field — and now the register says rung one, which is the truth.

The same discipline applies before you believe an install succeeded at all: which <tool> or command -v <tool> before trusting that the thing on your PATH is the thing you just installed. A package manager reporting success and a shell resolving the binary you expect are two different claims.

The obligation that runs the other way

A register is only half a system if it is written and never read. So the rule has a second clause: read it before you do repetitive manual work.

The failure it prevents is mundane and expensive. Someone spends an afternoon writing a script that already exists, because the existing one was registered by a person who has moved on and nobody thought to look. If something almost fits, extend it rather than starting a parallel one-off. If nothing fits and the same manual task has come up twice, that is the moment to propose a tool — propose, with the build cost weighed against the cost of continuing by hand, rather than build unasked.

The other thing the register does is make retirement visible. Entries get flagged keep, fix or retire, with a reason. Retiring is the owner's decision, never the auditor's. And when something is retired, its entry stays: the dead end is recorded, and the artefacts are archived rather than deleted. An inventory that quietly drops what stopped working teaches nobody anything.

What to take from it

If you keep a list of the automation your team depends on, go and pick three entries at random. For each one, try to produce the command that proves it ran this week, and what it returned.

If you can do that for all three, your register is real. If you cannot, you do not have an inventory of your automation. You have an inventory of your intentions — and the gap between those two is exactly where a scheduled job sits for weeks, doing nothing, while everyone assumes it is working.