A neutral default ships garbage

Average content quality: 37/100

That line was not in a report. It sat in the visible body of a page that was ready to publish, printed for any reader to see. The page was one of 122 pool-city hub pages waiting in the queue on one of my sites. Their median was about 25 visible words. Their bodies also linked out with an unfilled placeholder where a real path should have been.

I found them during a readiness check. I was about to switch a harm gate from report mode to enforce mode, so I replayed the real gate, without writing anything, over sets of pages I already knew were bad. The verdict I wrote down was blunt. On its own, the gate does not make content safe, and it misses thin, empty, and placeholder pages.

That mattered because the daily publisher runs this gate on every run. Whatever it passed was what went live.

The quality scorer adds up parts, and a page at or above 40 may publish (60 for the more sensitive pages). I worked out what a page with no body at all would get. SEO metadata could add up to 15. Field coverage could add up to 15. Freshness and the navigation signal had nothing to measure, so each fell back to a neutral default of 5 to 10. The total landed between 40 and 45. An empty page cleared the bar.

The other safety net had the same hole from a different side. The harm gate skips empty bodies on purpose, because an empty body produces an all-zero fingerprint, and that is not a duplicate signal. So an empty page passed both checks. Neither one had been built to notice it.

A neutral default sounds harmless. In a sum with a pass line, it is a vote to pass. When freshness had nothing to say, I let it say about average, and about average added up to ship it.

The rule now is short. If a page has zero visible words, fewer than 20, a leaked debug line, or a visible unfilled placeholder, the scorer returns a total of 0 and a list of the substance problems it found. Real bodies score exactly as they did before.

When the gate blocks, its message names the reason and quotes the offending text, so the 37/100 line now shows up in the refusal itself. A blocked run reports something like this:

Substance gate blocked 122 page(s) (debug_text=122, thin_body=63); e.g. [id] /restaurants/tulsa-ok/ - debug_text: '...Average content quality: 37/100'

The debug line had its own source. The function that builds hub bodies printed an internal metric straight into the page. I removed that line, and with it a per-child database loop that existed only to feed it.

Then I measured the new rule against every draft, ready, and published page before trusting it, with no writes and no model calls. The question was narrow: which pages passed the old gate and fail the new one? The answer was 608. When I looked at them by hand, all 608 were hub pages. No page outside the hubs tripped the leak detector, and no page anywhere had a fully empty body. Only 63 of them fell under the 20-word floor, all from that first set of 122. The problem lived in the hub template, and it did not reach the rest of the site.

The measurement also caught my own false positives before they shipped. Three published blog posts with unbalanced code fences, and one package page carrying a pasted BSD licence with {organization} in it, matched as placeholders. Those are real pages. So indented lines and lines that look like format strings now count as code, and the new tests include a list of those real shapes that must pass.

There are 33 new tests. The detail that told me the most was in four older test files. They had to be rewritten, because their fixtures used bodies of two or three words. Thin bodies had been normal enough that my own tests were built on them. I also broke the rule on purpose three ways. Disabling the early return failed 7 tests. Breaking the debug pattern failed 5. Raising the word floor to 200 failed 3, including the one that checks a short but real page still passes.