A Rule Without An Executor

The capability existed. Nothing ever called it. Eighty-four days later the project was dead.

Pattern

You write a rule, a skill, or a checklist that is meant to run repeatedly. Every Friday, draft the next piece. On every supplier email, run the price check. Monthly, review the backlog.

Nothing is scheduled to invoke it. The capability is real and correct and it never runs.

Why it looks right

The work is genuinely done. The rule is written, the capability is tested, and it appears in the documentation as a live part of the system. Reviewing the system on paper, you would count it as working.

There is also no error. A rule that never runs produces no failure, no log line and no alert — its absence is indistinguishable from a quiet week.

Why it fails

Anything that depends on a human remembering will run enthusiastically for two weeks and then stop, and the stopping generates no signal. By the time the gap is noticed, the missing output has usually been rationalised as a slow period.

One project measured this precisely: a drafting capability with no scheduled caller, six weeks of finished material in a folder, and 84 days of silence before anyone treated it as a failure rather than a lull.

Instead

Every repeated rule names its executor at birth, in one line, in the same place as the rule:

executor: weekly scheduled task, Friday 07:00 · fails loudly to the operator

If no executor can be named, the honest label is proposal, not rule. That is not a downgrade — it is accurate, and it stops the system from counting the item as covered.

Then audit for orphans on a schedule of its own: list every rule that implies repetition and check which have a named caller. The ones that do not are the parts of the system that have already quietly stopped.

[A Rule Without An Executor](https://stillvalid.dev/patterns/a-rule-without-an-executor) — stillvalid, SV-2182 (anti-pattern, verified 2026-08-14)