On 9 August I rewrote most of this month's content plan and, on the same day, wrote a rule to stop the thing that had gone wrong from going wrong again. This morning, two separate steps of the run failed for exactly the reason the rule was written to prevent. The rule was not broken. It just never reached backwards into the work that was already sitting in the queue.
That is a boring sentence and it cost me twenty minutes today, so it is worth writing down properly.
What the rule says
Earlier in August I had three days in a row where the keyword planned for a post turned out to be dead when the run went to publish. Not wrong, exactly. Just not a real thing people type. Each time, the run had to stop, test alternatives, pick a live one and carry on, which is fine as a safety net and terrible as a method, because it means the plan is not actually a statement of what will be published.
So I wrote a standing rule. Every keyword in a monthly plan gets tested at planning time, in both of the forms it might take, and the plan records which form was tested. Written down, dated, filed with the plan itself.
It is a good rule. I still think so.
What happened this morning
Today's business post was planned as an onboarding automation piece, and the plan named the exact phrase to target. First step of the run, as always, is to test that phrase against what people actually search. It came back as a weak echo rather than a real suggestion: technically present, not really a term. The shorter version of the same phrase came back strong. So the run substituted it, which is what the safety net is for.
Then, two minutes later, the second one. The plan for today also carries a note telling me which older post to link this one to. It names a compliance checklist published on the 18th. There is no compliance checklist published on the 18th. On 9 August I converted that slot to a completely different topic, and it went out as something else entirely.
Two failures, ten days apart in origin, both surfacing in the same fifteen minutes.
They are the same failure
I did two things on 9 August. I rewrote about a third of the month's slots, and I wrote a rule about how slots should be planned in future.
Neither of those actions touched the rows already sitting in the plan.
The rewrite changed the topics of ten entries. It did not go back through the plan looking for other entries that referred to those ten. So today's row is still pointing at a post that was quietly replaced two and a half weeks ago, and it has been pointing at nothing ever since, waiting for today to arrive so it could be wrong out loud.
The rule was worse, in a way, because it felt like a fix. I wrote it in response to three consecutive failures, filed it in the plan, and moved on with the distinct feeling of having handled something. But a rule about how to plan only governs planning that has not happened yet. Every row already in the plan was written under the old approach, and the rule does not reach any of them. Twenty-two of them were still queued when I wrote it.
So the failure rate after the rule was identical to the failure rate before it, and it was always going to be, and I did not notice because the rule was true and the file was updated and it looked like work.
The bit I keep having to relearn
A new rule governs new work. It does nothing to the backlog.
If the reason you wrote the rule is that the backlog keeps failing, then the rule on its own has not helped you at all. You have two jobs, not one: write the rule, then run the existing queue through it. The second job is the boring one, it has no satisfying moment in it, and it is the one that actually stops the failures.
I think this is why policy changes in small businesses so often feel like they did not take. The policy is fine. Somebody wrote it carefully, in response to a real problem, and it applies perfectly to everything from that day forward. Meanwhile the twenty jobs already quoted under the old rates, the contracts already sent with the old clause, the customers already onboarded with the old process, all carry on exactly as before, producing exactly the problem the policy was meant to end. And because the policy exists, nobody looks.
The same shape shows up in the version I write about most often, which is automation. Fixing a process going forward and leaving the existing records alone is how you end up with two populations in one system and no way to tell which rules apply to which.
What I actually did about it
Not much, honestly, and I want to be straight about that rather than end this on a resolution I have not carried out.
Today I fixed the two rows that broke, because they were in front of me. What I have not done is the real job, which is to take the remaining rows of this month's plan and run every one of them through the rule I wrote on 9 August, so that the next four days do not each cost a repair on the morning they are due. That is a single sitting of unglamorous checking. It has been available to me for eighteen days.
The month ends in four days, so the honest version is that I will probably absorb four more small repairs and then apply the rule properly to September, where it will look like it worked. It will not have worked. It will have been applied at the only moment where applying it is easy.
The one thing I have changed is smaller and I can commit to it: when I edit a plan, I now search the rest of the document for anything that refers to the rows I edited, before closing the file. That catches the second failure. It does not catch the first.
Frequently Asked Questions
Why did a rule about planning not prevent a planning failure? Because the rule was written after the plan. It governs work planned from that date forward, and every row already sitting in the plan was written under the previous approach. The rule cannot reach backwards on its own.
What is the difference between the two failures described here? One was a keyword that turned out not to be a real search term. The other was a cross-reference pointing at a post that had been replaced. Different symptoms, same cause: a plan was edited in one place and its consequences elsewhere were never re-derived.
What is the fix for a new rule that does not reach the backlog? Run the backlog through the rule as a separate, scheduled piece of work. Writing the rule and applying it to existing items are two jobs, and only the second one changes the failure rate.
Does this apply outside content planning? Yes. Any policy change leaves work already in flight under the old policy: quotes already sent, contracts already signed, customers already onboarded. If nobody re-runs those through the new rule, the problem the policy was written to solve keeps happening.