What 10 years at Clearscope taught me about AI slop

I spent the better part of a decade at Clearscope watching content teams make the same kinds of decisions over and over again. Should we publish this draft? Does it need another round of edits? Why did THIS page get the traffic and the one next to it die in obscurity?

Across thousands of editorial reviews, across hundreds of content teams, the pattern that emerged was almost embarrassingly simple. The pages that worked were the ones with specifics. Named places, named products, named people, specific numbers, real examples, firsthand details. The pages that died were the ones where you could swap out 'travel safety' for 'personal finance' or 'B2B SaaS' and the paragraph would still read like a paragraph.

That wasn't a Google ranking pattern. Or rather — it was, but indirectly. The deeper pattern was that specificity was the signal humans use to judge whether someone actually knows what they're talking about. Search engines were just measuring what humans were already measuring. Vague advice means you're summarizing; specific advice means you've lived it. Readers, raters, and ranking algorithms all converged on the same gut check.

When AI-generated content arrived, it arrived with a very particular failure mode: confident plausibility without specificity. The drafts read fine in isolation. They made sense paragraph-by-paragraph. They just didn't say anything that couldn't have appeared on a thousand other pages. The category we started calling 'AI slop' isn't really about AI — it's about the same vagueness pattern that human writers fall into when they're working too fast, writing about something they don't know, or pasting in summary language to hit a word count.

Which brings me to the design choice behind VeracityAPI.

Most AI-detection products were built around the question 'was this written by an AI?' That's an interesting question and there's a real market for it — academic-integrity workflows, editorial review, hiring. GPTZero, Originality.ai, and the others in that category serve that market well. But it's not the question that matters in autonomous workflows.

In an autonomous workflow, no human is reading the score. The agent generates a draft, scores it, and decides what to do next. 'This is 73% likely to be AI' is not actionable; the agent has to convert that probability into a decision. Every team building these workflows ends up writing their own thresholding code, picking arbitrary cutoffs, watching them drift when the underlying model recalibrates, and explaining to a stakeholder six months later why the gate has been quietly broken for a quarter.

The question that's actually useful in those workflows is the same question Clearscope's editorial customers were asking: should we ship this? And the most reliable predictor of whether something should ship is the specificity signal — the same one editors had been using by gut feel for decades.

So when we designed VeracityAPI, we deliberately weighted specificity_risk and provenance_weakness higher than synthetic_texture_risk. The product question isn't 'is this AI?' — it's 'is this generic enough that we shouldn't publish it, regardless of who wrote it?' A specific page written by a model is fine. A generic page written by a human is not fine. The signal we score is the one that actually matters for the decision.

There's a downstream effect of this design that I didn't fully anticipate. Teams using VeracityAPI to gate their content end up improving their generation prompts over time, because the evidence array tells them exactly what their generator is producing too much of. 'generic_phrasing,' 'specificity_gap,' 'paraphrase_summary' — these aren't accusations of AI-generation. They're a punch list of writing weaknesses. The same punch list that a good editor would give a writer at any other time in history.

I think that's the most useful framing for what we're building. VeracityAPI isn't an AI-detection product. It's an editor that scales — one that catches the specific weakness patterns that have always separated good content from forgettable content, but does it cheaply enough to run on every draft, before publish, at the boundary where the decision actually matters.

If your team is asking 'is this AI?' — there are good products for that. If your team is asking 'should we publish this?' — that's the question I spent ten years watching content teams struggle with, and that's the question VeracityAPI is built to answer.

Required caveat: VeracityAPI is a workflow-routing API, not forensic authorship proof. See /methodology for what we claim and don't claim.