The Anti-AI Slop Humanizer Framework: Eliminating Clichés and Passing Information Gain Filters

A generic list catches generic slop. Your pipeline's model has its own tics. To find them, generate 50 drafts across varied topics with your production prompt, then count word frequencies and compare against a baseline corpus of human technical writing such as the Linux kernel mailing list archives or RFC text. Words with a frequency ratio above 5x are candidates. Review each manually; a technical term can score high simply because your topic uses it. In one audit, 'ensure' appeared 9x more often than in our human baseline, and 'comprehensive' 14x. Neither was on the public lists. Add them, re-run, and watch the next tic surface: suppressing one phrase often promotes its neighbor, a whack-a-mole effect that a quarterly list review handles better than a single large purge.

Replacement Rules That Preserve Meaning

Every banned token hides a missing fact, so the edit is a question: what would I have to know to say this precisely? 'Robust' asks what failure it survives; answer with the failure ('survived a 30-second network partition without dropping acknowledged writes'). 'Seamless' asks what the user did not have to do; answer with the removed step ('no restart, no config reload'). 'Crucial' asks what breaks otherwise; state the breakage. 'Landscape' and 'realm' almost always delete cleanly with no replacement, because they were decoration. Edge cases matter: quoted text, error strings and product names must be exempt, so the scanner should skip fenced code blocks and blockquotes. Finally, never fix banned words by asking the same model to 'make it less robotic'. It substitutes a fresh set of tics. Fix lexically with the scanner, then fix evidentially with real data.

The Mathematical Anatomy of Burstiness and Perplexity in Professional Prose

Perplexity measures how surprised a language model is by a text. Formally, for a token sequence w1..wN, perplexity is exp(-(1/N) * sum log P(wi | w<i)). Lower values mean the text is more predictable to the scoring model. Machine-generated text sits low because the generator picked high-probability tokens. Burstiness describes variance in that surprise, and, in the stylometric sense used here, variance in sentence length and syntactic structure. Human writers alternate: a four-word verdict, then a 31-word sentence carrying a subordinate clause and a number. Models flatten that variance toward a comfortable mid-length mean. Be careful with claims here. Public AI detectors built on these two signals have high false-positive rates, and OpenAI withdrew its own classifier in 2023 for low accuracy. Do not optimize to fool a detector. Treat the metrics as diagnostics of rhythm, because rhythm is what a reader feels. A practical target for technical prose: sentence-length standard deviation of 8 to 14 words, a minimum of 4 words, a maximum near 35, and no more than two consecutive sentences within 3 words of each other in length. Compute it in ten lines. Split on sentence boundaries, take word counts, report mean, population standard deviation and the longest run of near-equal lengths. For perplexity, GPT-2 small through the transformers library is adequate for relative comparison between drafts, though absolute numbers are model-specific. In SiteVerity audits, raw LLM drafts scored a mean GPT-2 perplexity near 21; edited drafts with injected data and varied structure scored near 38. The gap tracks reader preference more reliably than any single banned-word count.

python3 - <<'EOF'
import re, math, statistics, torch
from transformers import GPT2LMHeadModel, GPT2TokenizerFast
text = open('draft.txt').read()

# Burstiness
sents = [s for s in re.split(r'(?<=[.!?])\s+', text) if s.strip()]
L = [len(s.split()) for s in sents]
print('sd =', round(statistics.pstdev(L), 1), 'min/max =', min(L), max(L))

# Perplexity (GPT-2 small, first 1024 tokens)
tok = GPT2TokenizerFast.from_pretrained('gpt2')
m = GPT2LMHeadModel.from_pretrained('gpt2').eval()
enc = tok(text, return_tensors='pt', truncation=True, max_length=1024)
with torch.no_grad():
    loss = m(**enc, labels=enc['input_ids']).loss
print('perplexity =', round(math.exp(loss.item()), 1))
EOF

Computing Sentence-Length Variance and Run Detection

Standard deviation alone can hide a pathology: a text alternating strictly between 10 and 30 words has high variance and a robotic pulse. Add run detection. Walk the length array and flag any window of five or more sentences where the absolute difference between adjacent lengths stays under 4 words. Those windows are the monotone stretches readers skim. In practice, fix them by merging two short sentences with a semicolon or colon, or splitting one long sentence at its first conjunction and adding a blunt fragment. Keep technical meaning intact: never split a sentence in the middle of a command description. Another useful secondary metric is the ratio of sentences beginning with the same token. If more than 20 percent open with 'The' or 'This', rewrite openers to start with a noun phrase, a number, or a verb.

python3 - <<'EOF'
import re
L = [len(s.split()) for s in re.split(r'(?<=[.!?])\s+', open('draft.txt').read()) if s.strip()]
run = best = 1
for a, b in zip(L, L[1:]):
    run = run + 1 if abs(a - b) < 4 else 1
    best = max(best, run)
print('longest near-equal run:', best)
EOF

Why Detector Scores Are Diagnostics and Not Targets

Perplexity thresholds misfire on exactly the writing you want to publish. Dense technical prose full of rare identifiers (ngx_http_limit_req_module, PgBouncer, RFC 9110) scores high perplexity regardless of author, while a formulaic human press release scores low. Non-native English writers are flagged at higher rates by detectors, a documented bias in published evaluations. So use the numbers comparatively: same topic, same scorer, draft A versus draft B. If your edit pass raised perplexity and variance while also adding verifiable facts, the text improved. If it raised perplexity by inserting random rare words, it got worse and the Information Gain score will not move. Gate on the lexical scanner and on evidence checks, and log the burstiness numbers as trend data, not as pass/fail law.

The Human-in-the-Loop Verification Protocol: Injecting Real Production Data and Hard Failures

The strongest Information Gain signal an article can carry is a fact the model could not have invented. That requires a human to run something. The verification protocol assigns every major section one mandatory artifact: a terminal capture, a before/after measurement, a version-pinned config, or a failure postmortem. The writer, not the model, supplies it. The model's job is to wrap sentences around it. Start each article with a lab log, a plain text file listing what was actually executed: hardware (an 8 vCPU, 16 GB instance, for example), software versions (nginx 1.24.0, PostgreSQL 16.2, Python 3.12), commands, raw outputs and timestamps. Feed that log into the drafting prompt as ground truth and instruct the model to cite only from it. Every number in the final article must trace to a line in the log; the audit step greps for numerals in the draft and checks each against the log. Untraceable numbers are deleted, because a fabricated benchmark is worse than none and invites a correction that damages trust. Hard failures carry the most weight. Writing 'the first config returned HTTP 502 because the upstream keepalive count was 0' tells the reader you actually hit the wall. Include the error string verbatim, the wrong hypothesis you chased first, and the fix with its measured effect. This is the experiential layer that the E-E-A-T guidance in the Search Quality Rater Guidelines names as 'Experience'. Our companion tool at /tools/ai-prompt-humanizer includes a checklist field that blocks export until each section has a logged artifact attached.

python3 - <<'EOF'
import re
log = open('lab_log.txt').read()
draft = open('draft.txt').read()
nums = set(re.findall(r'\b\d[\d,]*\.?\d*\b', draft))
missing = sorted(n for n in nums if n not in log and len(n) > 1)
print('UNTRACED:', missing if missing else 'none')
EOF

Structuring the Lab Log So the Model Cannot Drift

A lab log works as a constraint only if it is specific and delimited. Use a fixed schema per entry: timestamp, host spec, command, raw output (truncated to the relevant lines), observation. Wrap the log in XML-style tags in the prompt so the model treats it as source material, and add an explicit rule: 'Any number, version or error string not present inside <lab_log> must not appear in the output.' Models still occasionally interpolate, so keep the traceability script above as the backstop. A frequent failure is rounding drift, where 412 ms in the log becomes 'about 400 ms' in prose. That is acceptable only if the writer approves it; set the script to flag any numeral absent from the log so rounding is a deliberate decision. Store logs alongside the article in version control. When a reader challenges a figure, you can reproduce it.

Capturing and Presenting Hard Failures

Failures are the highest-entropy content because no consensus source contains yours. Record the symptom exactly as it appeared, for example `nginx: [emerg] upstream timed out (110: Connection timed out) while reading response header from upstream`. Record the wrong turn: 'I raised proxy_read_timeout to 300s and the error persisted, which ruled out slow responses and pointed at connection reuse.' Record the fix and its effect with a before and after number. Present it in plain order: symptom, wrong hypothesis, evidence that killed it, root cause, fix, verification command. Keep the tone flat and factual. Do not dramatize. Edge case: if a failure involved client data or a security incident, anonymize hostnames and IPs, replacing them with RFC 5737 documentation ranges such as 192.0.2.0/24 so readers can still follow the logic.

The 3-Pass Prompt Engineering System for High-Entropy, Zero-Fluff Technical Writing

One prompt cannot produce publishable prose, because drafting, constraint enforcement and style editing pull the model in different directions. Split the work into three passes with separate system prompts and separate temperatures. Pass 1, Evidence Draft (temperature 0.4). Input: the lab log and an outline. The prompt demands that every claim be sourced from the log, that sections open with a result or a failure, and that no sentence exceed 35 words. Output is deliberately plain. The low temperature keeps the model from inventing detail. Pass 2, Constraint Scrub (temperature 0.2). Input: the pass-1 draft and the banned list. The model deletes banned tokens by restating claims with concrete nouns, removes conversational transitions, and cuts any sentence that carries no new fact. The scanner runs after this pass; a nonzero exit loops back to pass 2 with the hit list appended. Pass 3, Rhythm Edit (temperature 0.7). Input: the scrubbed draft and the measured burstiness report. The model receives targets (sd between 8 and 14, minimum sentence length 4, maximum 35) and the list of monotone runs flagged by the run detector. It rewrites only those spans. Restricting the edit to flagged spans prevents the higher temperature from reintroducing slop elsewhere. Finish with a human read-through for factual claims and voice. The template below is the pass-1 system prompt, and the full set of three is available in /tools/ai-prompt-humanizer.

SYSTEM:
You are a senior infrastructure engineer writing a technical guide.
SOURCE RULE: Use only facts, numbers, versions and error strings found
inside <lab_log>. If a needed fact is missing, write [NEED DATA] instead
of inventing it.
RHYTHM RULE: Vary sentence length between 4 and 35 words. Follow a long
sentence with a short one. Never write three consecutive sentences of
similar length.
STRUCTURE RULE: Open each section with a measured result, a command, or a
failure. Never open with a definition of the topic.
BAN RULE: Do not use conversational transitions (however, furthermore,
moreover, additionally), summary closers, rhetorical questions, or any word
in <banned_list>. Do not restate the section at its end.
EVIDENCE RULE: Every claim about performance must carry a number and the
hardware it was measured on.
OUTPUT: Plain prose, fenced code blocks for commands. No bullet lists of
three adjectives.

<banned_list>{{BANNED_TOKENS}}</banned_list>
<lab_log>{{LAB_LOG}}</lab_log>
<outline>{{OUTLINE}}</outline>

Temperature, Token Limits and Pass Isolation

Isolation matters more than prompt wording. If one conversation holds all three passes, the model carries pass-1 phrasing into pass 3 and the edit becomes cosmetic. Start a fresh context for each pass and pass only the previous output plus the new instructions. Set max_tokens to about 1.3x the expected output so a runaway generation cannot append a summary section. Low temperature in passes 1 and 2 reduces vocabulary variance, which is what you want when enforcing constraints; higher temperature in pass 3 is acceptable because the edit is scoped to flagged spans. Log token counts and cost per pass. In our runs, pass 1 consumed roughly 62 percent of tokens, pass 2 about 18 percent and pass 3 about 20 percent. If pass 2 exceeds 30 percent, your pass-1 prompt is leaking slop and needs tightening.

The Feedback Loop: Scanner Output Back into the Prompt

The scanner's file:line:column output is machine-readable, so feed it straight back. After pass 2, if the exit code is 1, append the hit list to the next request: 'Lines 14, 38 and 52 contain banned tokens; rewrite those sentences only.' Cap the loop at three iterations. If a hit survives three rounds, the sentence is structurally dependent on the token and needs manual rewriting; flag it for a human. This closed loop converges quickly: median iterations across 140 drafts was 1.4. Keep a changelog of which tokens recur after the first loop, since they reveal tics worth adding to the pass-1 ban rule and cutting at the source.

5 Testing Proofs: How Humanized Technical Articles Outrank Unedited AI Summaries

Claims about content quality need controlled tests. The five proofs below are ones you can reproduce on your own corpus. Keep the topic, URL structure, internal link count and publication date window matched between control and variant so that the edit is the only variable. Proof 1, lexical density. Run slop_audit.py on both versions. The unedited set averaged 11.8 hits per 1,000 words; the humanized set averaged 0.4. This is the cheapest proof and the one stakeholders understand immediately. Proof 2, burstiness delta. Sentence-length standard deviation rose from 5.1 to 11.6 words, and the longest near-equal run dropped from 9 sentences to 3. Proof 3, engagement. In Search Console and analytics, compare median engaged time and scroll depth. Humanized pages held readers 41 percent longer on a 22-page sample, consistent with readers finding concrete artifacts worth reading. Proof 4, ranking retention. Track position at day 14, 30 and 45. Fifteen of 22 humanized pages held top-5 at day 45 against 4 of 22 controls. Treat this as correlational: ranking has many inputs. Proof 5, citation capture. Query Perplexity and a Google AI Overview sample for the target questions and log which domains are cited. Pages carrying a concise answer box plus verifiable data were cited 3x more often than unedited twins. Report confidence honestly. With n=22 per arm, the ranking gap is directional, not definitive. Re-run quarterly and keep the raw numbers.

# Compare lexical density and burstiness for two content sets
for set in control humanized; do
  echo "== $set =="
  python3 slop_audit.py content/$set/*.md | grep -E '^\[(PASS|FAIL)\]' \
    | awk -F'|' '{print $1}' | sed 's/^/  /'
done

# Ranking retention via Search Console API export
python3 gsc_positions.py --urls urls.csv --days 14,30,45 --out positions.csv

Designing a Fair Control: Matching Pairs and Isolating the Edit

A fair comparison needs matched pairs. Pick topics with similar search volume and keyword difficulty, publish both versions on the same domain in the same week, and give them the same number of internal links from pages of similar authority. Do not publish the variant earlier or promote it harder. Hold the title and meta description pattern constant, since CTR differences will contaminate engagement data. Record which model, version and date produced each draft: model updates between runs change baseline slop levels and invalidate comparisons. Where you cannot match pairs, use a within-article design instead: rewrite half of an existing section set, leave the other half untouched, and compare section-level scroll depth through scroll-event tracking. That isolates the edit at the cost of a smaller, noisier signal.

Reading the Results Without Overclaiming

Four traps recur. First, survivorship: pages that were never indexed disappear from ranking data, so check index coverage before comparing positions. Second, seasonality: a 45-day window over a holiday period distorts click data; compare against a control published in the same window. Third, algorithm updates: if a core update lands mid-test, annotate the date and split the analysis before and after. Fourth, confounded effort: humanized articles usually also contain more real data, so you are measuring the whole editorial process, not word swaps. That is fine, and it is an honest finding. The banned-word scrub is hygiene; the data injection and rhythm work is where the gain comes from. Report both, and resist the claim that deleting 'delve' alone moves rankings.

Configuration	Banned Hits / 1k Words	Sentence-Length SD (words)	GPT-2 Perplexity (mean)	Top-5 Retention at Day 45
Raw single-prompt draft	11.8	5.1	21	4 of 22 pages
Raw draft + 'make it human' rewrite	7.3	5.9	24	6 of 22 pages
Pass 1 + Pass 2 (scrub only)	0.9	6.4	27	9 of 22 pages
Full 3-pass, no lab-log data	0.5	10.8	33	11 of 22 pages
Full 3-pass + injected lab data	0.4	11.6	38	15 of 22 pages

Frequently Asked Questions

How do you remove robotic clichés from AI text to pass Google Information Gain filters?

Run a regex scanner against a banned-token list and delete each hit by restating the claim with a concrete noun, never a synonym. Then inject facts the model cannot invent: measured benchmarks, version-pinned commands and verbatim error strings from your own lab log. Information Gain rewards new information relative to existing results, so evidence beats rephrasing.

What are the top words that give away AI-generated content?

The most frequent tells are delve, tapestry, realm, landscape, leverage, harness, robust, seamless, pivotal, crucial and holistic, plus connectives like furthermore, moreover and in conclusion. They stand out because their frequency in model output far exceeds their frequency in human technical writing. Find your own model's tics by comparing word-frequency ratios against a human baseline corpus.

What is burstiness in writing and why does it matter for SEO?

Burstiness is variance in sentence length and structure. Human prose alternates short and long sentences; LLM prose drifts toward a uniform mid-length mean. It matters indirectly: monotone rhythm lowers reader engagement and dwell time, which feed quality systems. Target a sentence-length standard deviation of 8 to 14 words, and treat it as a diagnostic rather than a ranking factor Google confirms.

Does Google penalize AI content or just low-quality generic content?

Google's published guidance states it targets content created primarily to manipulate rankings, regardless of whether a human or a model wrote it. AI-assisted content that shows real experience, original data and accuracy is not penalized for its origin. Scaled, generic, unverified output is what triggers the spam policies and the helpful-content demotions.

Building and Maintaining Your Own Banned List from Real Drafts