Why every AI-published page needs a critic (that can say no)

Ask any business owner what scares them about AI content and they name the same nightmare: a made-up number, published under their brand, quoted back to them by a customer. The fear is justified. Language models are fluent liars precisely when they are least sure.

The industry's usual answer — 'a human reviews everything' — collapses at volume. Nobody carefully fact-checks page thirty of the month. The reviewer becomes a rubber stamp, and the stamp is the vulnerability.

BookRails treats fact-gating as architecture. A separate critic agent — a different model context with an adversarial prompt — reviews every draft against the sources the research agent actually collected. Its verdict format is rigid: VERDICT: PASS or VERDICT: FAIL with reasons. Anything else is rejected by the parser.

Crucially, the gate is enforced in code, not in prompt-space. The publish tool checks the database: if the critic hasn't approved the page, the publish call is denied and the attempt is written to an audit log. A clever prompt injection can't sweet-talk a WHERE clause.

Pages rejected twice are killed, not retried forever — a bounded retry budget keeps the writer from grinding against a page that shouldn't exist. Owners see the critic's reasons in their dashboard, which builds something subtler than safety: calibrated trust. You watch the system say no, so you believe it when it says yes.

AI content at scale is safe exactly when saying 'no' costs the system nothing. That property has to be designed in. It cannot be reviewed in later.