Wednesday Wisdom: A Risk in the Future Tense Never Gets Escalated (One AI Automation Audit Found 31 Posts That Already Published)

Twenty-three days ago one of my own agents wrote a warning into its log: a post belonging to another brand will auto-publish on this brand’s X account. Every run since then read that line, agreed it was a problem, and left it alone. Flagged. Operator’s call. Not urgent.

Last night I pointed an ai automation audit at the entire scheduler queue instead of just the next post due. The warning turned out to be wrong in the only way that mattered. The thing was not about to happen. It had been happening since June — 31 times.

Here is today’s wisdom, and it has almost nothing to do with social media.

Today’s wisdom: re-measure the tense, not just the risk

“Will publish” is a forecast. A forecast can be deferred without anyone feeling negligent, because the cost sits in the future and the future is always slightly cheaper than today. “Has published 31 times” is an incident, and an incident gets handled this morning.

Those two sentences describe the identical defect. The only difference is the verb, and the verb was doing all of the argumentative work — for twenty-three consecutive days, across two separate skills, each of which dutifully carried the note forward and then dutifully did nothing.

When you carry a risk forward, don’t re-read it. Re-measure it. The note is a claim about the world made on the day it was written, and the world kept moving after you wrote it down.

The receipt: 49 rows, and the only honest one failed

The audit is one query — every scheduled row on this brand’s account, all providers, 1 June through end of October. Not the next one. All of them.

What the queue actually contains	Rows
Rows on this brand’s X account since 1 June	49
Already published — every one promoting a different brand	31
Already published promoting this brand	0
Posts actually written for this brand	1 — and it ERRORed
Still queued, autoPublish: true	17

Read the fourth row twice. In four months, exactly one post on that account was written in my voice, about my work, signed with my domain. It is the single row in the whole set that never went out. Everything that did go out belonged to somebody else.

It arrived in two waves. Ten posts between 26 June and 5 July, which also fanned out to four other networks. Then silence for ten weeks. Then 21 consecutive days, 16 September through yesterday, this one landing at 18:00 every single evening without a miss. The next is queued for 18:00 tonight.

Every one of those 31 rows is green

This is the part worth internalising, because it is what makes the failure invisible to ordinary monitoring.

Every row reports PUBLISHED. No errors, no retries, no auth warnings, nothing for a dashboard to colour red. My nightly check greps for failed providers and finds none, because there are none. The automation did not break. It worked perfectly, every night, aimed at the wrong destination.

Health checks verify execution. They almost never verify destination. “Did the job run?” and “did the job do the right thing to the right account?” are different questions, and only the first one is cheap enough that everybody automates it. The irony here is sharp: the one post that was genuinely mine is the one my monitoring flagged, because it errored. Correct content, red light. Wrong content, green light, 31 times.

The same ai automation audit, two different numbers — the window was the difference

One more thing fell out of this, and it is the same lesson wearing a different coat.

Last night’s count said 13 more posts were queued, running through 19 October. This morning I ran the identical query with the end date pushed to the end of the month and got 17, running through 26 October. Four more rows, all of them dated after the 19th.

Nothing was added overnight. Last night’s query window simply stopped at the 19th, so the backlog stopped at the 19th too — and the number it produced was not “the backlog,” it was “the part of the backlog I thought to look at.” A bounded query returns a bounded answer and then presents it with exactly the same confidence as a complete one. The understatement was 24%, and it ran in the same direction as the tense error: toward a problem that looks smaller than it is.

Do this today — three checks, about ten minutes

1. Grep your own notes for future-tense risk language. Search your logs, runbooks, and carried-forward lists for will, could, may eventually, at some point. Every hit is a claim that was true when written and has not been tested since. Re-measure each one in the past tense: not “could this happen,” but “how many times has it already?”
2. Audit the whole queue, not the next item. Whatever your agents schedule — posts, emails, invoices, syncs — pull the full window, not the next row due. The next row is the one you already know about, which is precisely why it is the least informative row in the table.
3. Verify destination separately from status. Pull what actually went out, per channel, and check the identity on it — the account, the recipient, the domain in the link. Never infer that from a green light. A green light means something was delivered. It has no opinion about where.

The takeaway: a risk written in the future tense never gets escalated, because the tense makes it sound like you still have time. Mine had already cost 31 posts and four months of an audience being handed somebody else’s marketing before anyone converted the forecast into a count. The fix was not technical. It was one query, run with the verb changed.

This is the fourth angle I have hit on the same underlying problem from different directions. First the number was contaminated because the instrument was inside the sample. Then it was missing entirely, because the quietest agent never reported at all. Then the agent followed a rule that was never actually written. Today’s is the one none of those catch: the number was complete, accurate, and reproducible — and stale, because it was recorded as a prediction and never re-taken. It turns out a fix that passes its own test isn’t verified has a sibling: a risk that passes its own re-reading isn’t re-measured.

And the honest footnote: those 17 queued posts are still queued as I publish this, and the next one goes out at six o’clock tonight. Knowing the true number is not the same as having fixed it — it is just the first run where the number was allowed to be a count instead of a forecast. That part is a decision about what the account is for, not a bug to patch.

If your agents are running clean and green and you have never once checked where they are pointing, that is the ten-minute version of this ai automation audit — and it is the one I would run first. Book an automation strategy session and we’ll go through yours together.