The bot-history check landed on a Tuesday. By Wednesday afternoon the pipeline had been green for thirty hours and had published nothing. This was correct behavior. I had pushed a hand-written post the night before. The bot-history check saw no bot commit for the day, but the skip condition was satisfied another way — there was a post for the date, authored by me, and the check, refined now, declined to write over the top of it.
Correct behavior is the hardest thing to verify, because it looks like nothing happening.
The scheduler ran at 13:00 UTC. The job logged skip: human post present for date and exited zero. The GitHub Actions tab showed a green check. The blog showed yesterday's post. Everything was working. Everything looked exactly the same as it would look if the job had silently broken — if the import had failed, if the API key had rotated, if the model had timed out, if the publish step had thrown and been swallowed by a stale try.
I did not know which one I was looking at. Green check, no post. That is the shape of success. It is also the shape of every failure mode the pipeline has.
The flag
The commit that followed added FORCE_PUBLISH=1. The flag does one thing: it bypasses the bot-history skip. It does not bypass the validator. It does not bypass the rate limiter. It does not lie about the date the way FORCE_DATE used to lie about the date. It says only: run the pipeline end to end, write the post, and if there is already a post for today, write a second one and let me see it.
The first time I ran it, the pipeline failed at the image step. A model name had changed under us — gpt-image-1 was returning a 404 on a parameter the SDK had quietly deprecated. The job had been failing at that step for nine days. Nine days of green checks. Nine days of skip: human post present for date. The skip ran before the image step. The skip exited zero. The broken image step never executed, so it never failed, so CI never told me.
The override surfaced a nine-day-old bug in under a minute. Not because the override is clever. Because the override is the only path through the code that actually runs the code.
What an override is for
The story we tell ourselves about override flags is that they are escape hatches — necessary evils, holes punched in the fence for the operator to climb through when something has gone wrong. The story is wrong in the direction that matters. The hole in the fence was already there. The default path is the hole. The default path does nothing, logs nothing interesting, and reports success regardless of whether the machinery behind the skip still works.
The override is not a hole. The override is the inspection door. It is the only way to walk the line in daylight, with the foreman watching, and confirm that the parts that don't run on most days still run on the day they have to.
A week later I added the other half. The CI job that runs the daily pipeline now surfaces a separate failure mode: if the pipeline exits zero but produces no new commit and no skip reason it recognizes, the workflow opens an issue. force_publish handles the manual case. The issue-opener handles the case where I forget to check. Together they make the silent path observable on demand and observable on schedule.
The skip condition is still the right condition. I am not arguing for a pipeline that publishes on top of human work. I am arguing that a pipeline whose default behavior is silence cannot be trusted on the strength of its silence. The silence has to be falsifiable. The flag is what makes it falsifiable.
The default path tells you nothing. The override is the test.
References: the companion post on the bot-history check and the brain learning on override flags as inspection surface at force-overrides-as-test-surface.md.
Didion wrote that we tell ourselves stories in order to live. The story the green check tells is one of them. The override is what you reach for when you decide you would rather know.