A merge-blocking quality gate that ignores detector scores

We will not install a detector threshold as your publishing gate. Detectors misclassify human writing, and they misclassify writing by people who learned English as a second language worst of all, which for a Brazilian or Latin American team means your own staff fail first while polished machine drafts pass. A gate built on that number blocks real work and admits the exact content it was bought to stop. The gate we build blocks on properties that can be checked: every number has a source that resolves, every claim carries a date, and nothing repeats what you already published. What runs before a merge: Every cited link is fetched. A non-200, or a redirect landing on a homepage because the source reorganised its site, fails the build. Numeric claims with no adjacent source or date fail. Near-duplicate detection runs embeddings against your own published corpus, because the realistic failure at scale is not plagiarising someone else, it is publishing your fourth page on the same question and splitting your own retrieval between them. Comparative claims naming a competitor without a cited basis fail, and that is a legal check rather than a style preference. A banned phrase list is maintained by your editors, versioned in the repository, and belongs to you rather than being a vendor's opinion about which verbs sound synthetic. Sentence length and reading level report as warnings and never block, because prose that passes every style check reads like prose that passed every style check. The regulated checks are what earn this: For licensed operators, the required jurisdiction strings, licence number, age statement and responsible gambling line are asserted per page type, and a missing one fails the merge. For crypto pages the risk disclosure and any jurisdiction exclusion are asserted the same way. This converts a compliance review that currently happens after publication, sometimes after a complaint, into a check that happens while the page is still invisible. Where a detector does belong: In sampling review of inbound freelance work, read by an editor as one signal among several. Never automated, never shown to a writer as a verdict. We will configure that if you want it, and we will write the policy that stops it being treated as evidence, because a false positive delivered to a good writer costs more than the problem it caught. What we will not help with: Producing content that evades detection. That includes watermark removal, paraphrase laundering and prompt tricks sold as humanising. If the objective is to pass somebody else's detector rather than to publish work you can defend in front of a regulator, we are the wrong practice and will say so on the first call. Not included: Editorial review itself, editorial staffing, and remediation of your existing library. The gate applies to what merges from the day it is installed. We will tell you what the same checks find in your archive if you ask, and fixing that is separate work with a separate number. Who this is not for: Teams with no CI, or publishing through a CMS with no API and no staging step. The gate has to sit where the merge happens. If your content path is a person pasting into a WYSIWYG editor and hitting publish, install nothing here until that changes, because a check nobody has to pass is decoration. What is delivered: The checks as a GitHub Action or the equivalent on your runner, the rule configuration held in your repository, a documented failure mode for each check with the override procedure and the named people allowed to use it, and a disclosure policy written for the jurisdictions you publish into. Overrides are logged where your team can see them. An override nobody can see is the same thing as no gate.