# When a real launch looks like a template date

> A customer published six pages on one day in September and our ship detector credited none of them. The guard that threw them out existed for a good reason. Fixing it meant finding a signal that separates a real batch publish from a CMS date stamp, and refusing the cases it can't separate.

- Author: Kevin Kho
- Published: 2026-09-24
- Canonical: https://knitknot.ai/blog/when-a-real-launch-looks-like-a-template-date/
- Publisher: KnitKnot, the AI Competitive Positioning platform (https://knitknot.ai)

---

## Six pages, zero credit

On September 9, one of our customers published six new pages on its site. New pages on a customer's own site are what our playbooks ask for, and what our ship detector is built to notice. It noticed all six and discarded every one, so not one of that customer's playbooks was detected as done.

Max flagged it on September 18. The detector had thrown the pages away for a single reason: they shared a publish date.

## Why the detector exists

A playbook only gets measured once we know it shipped and which URL implements it. In practice customers publish the page and never come back to paste the link. The play sits in "proposed," and eventually our planner retires it as unactioned while the page it asked for is live and unmeasured. The same customer had done exactly that twice in August.

So we built a detector that works from the other end. It watches the small set of pages a customer has published recently and asks whether one of their own open playbooks asked for that page. When the match is confident, it records the ship exactly as if the customer had pasted the link.

The hard part is the word "recently." To know a page is new, we need two things. The page has to be new to our crawl, and it has to carry a publish date inside the window. The first half is not enough alone, because finding an old page late is not a publication.

## Why the date guard existed

The second half has a catch. The date a page reports is often not a publish date at all. Plenty of sites stamp every page with the date of the last deploy or template change. The customer's platform, product and solutions pages all read July 31, 2026. That date belongs to the site's template, not to the pages.

So we added a rule. If more than three owned pages share a publish date, that date is suspect. It was a sensible rule, and it caught real stamps. It also caught the thing the detector exists to catch. Customers rarely ship one page a week. They ship a content push, and a content push lands a batch of pages on one day. Counting pages that share a date can't tell those two situations apart.

## A signal the template can't fake

What separates them is the day we first saw each page. A template stamp has no reason to agree with our crawl. A real publish does, because the page appears shortly after the date it claims.

Across that customer's whole inventory the difference is stark. Twelve pages carry the September 9 date, and all twelve first appeared in our crawl within 14 days of it. The July 31 date sits on 15 pages, and only 2 of them are that close. Two older stamps, on 13 and 10 pages, have none.

We picked 14 days as the window because it is the widest one that still rejects the July 31 stamp. At 30 days, 14 of those 15 stamped pages would have passed and the guard would have stopped doing its job. Anywhere from 3 to 14 days gives the same verdict, so the choice isn't sitting on a knife edge.

## The case page-by-page checking missed

Checking pages one at a time turned out not to be enough. Another customer's documentation site re-stamps every page on each build. If we happen to crawl around the same time, some old pages agree with our first-seen date by coincidence. One bucket had 139 pages dated the same day, 44 of which corroborated. Among those 44 was the product's main page, which the detector was about to credit as a newly published article.

The fix was to judge the whole date bucket before believing it for any page in it. A real batch publish is almost entirely new pages, and a re-stamp is mostly old ones. The September 9 bucket corroborated 12 of 12. The docs re-stamp corroborated 44 of 139, about a third. We now require 80% of a suspect bucket to corroborate. A bucket in between, like a later one on that same docs site where 22 of 39 pages corroborated, is refused.

## What we still refuse

That refusal is deliberate. We will miss some real publishes. A new page whose date we can't parse or corroborate is discarded. When two playbooks fit a page about equally well, we don't pick one. That becomes a question for the customer. We cap automatic credits at five per workspace per sweep so that a bulk republish can't mark a backlog as done overnight. And a match needs a shared term that is rare in the customer's own content, because on a site where every page uses the same category vocabulary, general similarity proves nothing.

I think this is the right trade, though I'm not certain the thresholds will hold for every kind of site. The reason is what a ship sets in motion. Crediting a ship freezes the baseline run the play will be measured against and the set of prompts it's expected to affect. A wrong ship date anchors the comparison to the wrong point. The measurement then reports movement that belongs to something else, and nothing in the report would flag it.

The same caution runs through what happens after a ship. When fewer than five prompts sit on either side of a playbook's comparison, we leave its controlled deltas blank and say there aren't enough affected prompts to isolate the impact yet. A blank is less satisfying than a number. With a sample that small, the number would mostly be noise.

We would rather miss a ship than credit one that didn't happen. A missed ship costs the customer a pasted link. A false one costs them a measurement they have no reason to doubt.