The Feature We Assumed We Had

We wrote thirty blog posts to go out over seven days, dated one to seven days ahead, and pushed them.

All thirty went live immediately.

None of our five websites could schedule a post. Every blog route filtered on a draft flag and nothing else — no date comparison existed anywhere in any of them. A post dated next Friday published the moment it was pushed, because the date in the frontmatter was decoration.

The shape of this kind of gap

Nobody removed the feature. It was never built, and it was never noticed missing, for a reason worth naming.

Publishing had always been manual. Somebody finished a post and pushed it, and it appeared. That workflow never asks the system to hold anything, so the absence of holding is invisible. The date field existed, was populated correctly, and was used for sorting and display — which is exactly enough use to make it look functional.

It only surfaced when the workflow changed. The moment we wrote ahead rather than writing and publishing, the assumption became load-bearing and immediately failed.

That is the general form: a capability you have never exercised is indistinguishable from one you have. Not because anyone is careless, but because the evidence for both states is identical — nothing has gone wrong.

★ Insight ───────────────────────────────────── The tell, in hindsight, was that a field existed and was populated with care. A date: on every post, correct, in ISO format, sorted by. That is a strong signal of a working feature and it is not one — the field was being read, just not for the purpose everyone assumed. A populated field proves somebody filled it in. It proves nothing about what consumes it. ─────────────────────────────────────────────────

What we built

A small script that flips a post from held to published when its date arrives. Dry-run by default, with a date override so it can be tested without waiting a week.

One design decision in it is worth explaining, because getting it wrong would have been worse than the original gap.

The obvious rule is: any draft whose date has passed should be published. We nearly shipped that.

Two posts on our estate were drafts that had been held back deliberately — one of them dated three weeks ago. Under the obvious rule, the first run would have published somebody’s withheld work.

So the script only touches posts carrying an explicit marker set by the writing process. An ordinary draft stays a draft forever, no matter how old. The rule is not “old enough to publish” but “scheduled by us, and now due” — and those are different populations that a date test cannot tell apart.

The audit worth running on your own operation

The useful generalisation is not about publishing. It is: which capabilities does your business believe it has, and which have actually been exercised?

Three questions that surface these quickly.

1. What would happen if the person who usually does this were away for a fortnight?

Most assumed capabilities are actually a person. The system does not schedule; somebody remembers. That works until it does not, and it fails silently because nobody is watching for the thing that did not happen.

2. When did we last use this on purpose?

Not “is it configured”. When was it last exercised and what was the result. Applies to a scheduled report, a failover, an approval workflow, a mail rule, a backup.

3. Which fields do we fill in without knowing what reads them?

This one is surprisingly productive. Go through a form your team completes regularly — a job record, a CRM field, a project tag — and ask what consumes each value. There is usually at least one that nothing reads, and occasionally one where the assumed consumer is not the actual one.

What it cost, and what it would have cost

Finding it cost an afternoon: the thirty posts were unpublished, marked as scheduled, and a release script was written.

Finding it in three months would have cost more than the time. We would have been running a publishing calendar that everybody believed was working, with posts appearing on the wrong days, and the discrepancy attributed to whoever pushed last rather than to a missing feature — because the natural explanation for a post appearing early is that someone published it early.

A missing capability is usually diagnosed as a person’s mistake before it is diagnosed as a missing capability. That is what makes them durable.

Two other assumptions the same week surfaced

Once we started looking, the publishing gap was not alone.

Nothing reconciled what had been produced against what was recorded. Three finished files sat on disk for nineteen days while the tracking record said they had never been made. Two separate processes wrote to two separate places and nothing compared them.

Several commercial pages had no links pointing at them. Not few — none. The pages existed, were correct, and were reachable only from a menu, because nothing in any article had ever referred to them.

Neither had a symptom. Both were found by counting rather than by noticing, which is the common thread with the publishing gap too: these are absences, and an absence produces no signal. You cannot notice something not happening; you can only go and check whether it happened.

That suggests an annual habit rather than a monitoring one. Once a year, take the things your business believes are automatic and confirm one of them by hand.

The narrower lesson

If your business has recently changed how it works — batching something that used to be continuous, planning further ahead, or moving work between people — then the assumptions that were safe under the old pattern are the ones to check.

Ours held for years because we published one post at a time. The moment we wrote a week ahead, a field that had always been decoration needed to be a function, and nothing anywhere said it was not.

---

Ganda Tech Services runs web, cloud, mobile and content operations for a group of Australian brands. Websites and publishing workflows are built through Cosmos Web Tech.