We built a gate that refuses to publish our own pages

Run our content status command today and it reports:

prompts      0 / 4 publishable
competitors  0 / 11 publishable
tools        0 / 0

Fifteen records in the repository, none of which may become a URL. Nothing is broken. The templates work, the routes build, the tests pass. The records are not finished, and the build refuses to pretend otherwise.

Where the refusal lives

It would be natural to put this in the schema, as a required field. We deliberately did not, and the reason is the whole design.

The schema’s job is to accept work in progress. Someone researching a competitor should be able to commit a half-finished record, open a pull request, and have a colleague look at it. If the schema demanded every field, that work could not exist in the repository at all, and it would live in someone’s notes instead, which is where research goes to die.

So the schema is permissive and a separate function decides publication. It runs inside getStaticPaths, which means a record that does not pass simply has no route. Not a 404 page, not a noindex page. The URL does not exist.

What it checks

For a prompt page, the conditions are:

• A real narration excerpt from a real run, not a description of one
• At least two failure modes
• At least two variations
• A measured runtime
• A measured duration on every beat of the output plan
• At least two related prompts, so the page is not an orphan

Every one of those can only be written by someone who ran the thing. That is the selection criterion. Titles, summaries and descriptions can be assembled from what a vendor publishes about themselves. Narration transcripts and failure modes cannot.

The failure-modes field is the one doing the most work. “If the app gates on two-factor the agent stalls at step three” is not inferable, summarisable or synthesisable. It is only observable. A page without it has nothing on it that a competitor could not also write, and therefore no reason to be indexed.

The comparison pages have a stranger requirement

For a page comparing us to a competitor, one field is mandatory and it is this: a written statement, at least sixty characters, of something that competitor does better than us.

It is load-bearing three ways. It is the strongest structural signal that a comparison page is not a doorway, because doorway pages never contain one. It guarantees no two comparison pages read alike, because the honest advantage differs every time. And in our experience it is the part that actually persuades anyone, because a comparison that admits nothing is a comparison nobody believes.

A page that cannot name what a rival does better has not been researched. The gate treats that as a fact about the research rather than a stylistic preference.

Why a function and not a checklist

We had a checklist first. It was in a document. It was accurate and everybody agreed with it and it did not survive contact with a deadline.

The version that survives is the one where the build will not produce the page. There is no step where a person decides whether the standard applies today. If we want to publish something that does not meet the bar, we have to go and change the function, in a commit, with the reason visible in the diff.

That is a higher bar than intending to be careful, and it is the only version we have found that holds when we are busy.