The Anti-Slop Doctrine We Adopted - and Wired Into Every Groundcrew Skill

“Don’t publish AI slop” sounds sensible, but it is not an operating standard. A standard has to tell a writer what must change, tell a reviewer what blocks publication, and leave evidence that a reader can inspect.

That is how we use the term anti-slop doctrine in the current TrustGrowth and Groundcrew workflow. We credit the framing to the WHY-NOT-SLOP doctrine in the newsjack.sh skill pack. The public WHY-NOT-SLOP doctrine describes the underlying stance; our job is to turn that stance into repeatable constraints.

Here, “slop” means output with one or more operational failures: unverifiable claims, statements detached from their sources, generic filler, invented certainty, or conclusions that cannot be traced to a rule or evidence item. This article explains the standard we apply now. It does not claim that the standard guarantees accuracy, rankings, traffic, or business outcomes.

The doctrine in one sentence

Our anti-slop doctrine treats an unverified, non-inspectable, or over-certain claim as a publishing risk, so the workflow must refuse it, constrain it, or push back before publication.

The important words are “publishing risk.” A rule does not need to prove that every permitted sentence is useful. It needs to identify specific failure modes and produce a clear operator response.

Five operating principles

First, claims need named evidence. “Data-backed” is too vague. A draft should identify the source type—such as a public proof page, repository file, or measured audit output—and keep the claim within what that source shows.

Second, current state beats speculative promise. We describe what a rule, page, or product surface does now. We avoid turning an intention, roadmap, or isolated observation into a future outcome claim.

Third, measured facts and editorial judgment stay separate. A crawl result or source field can be inspected. A judgment about usefulness or trust still requires interpretation. The distinction is explored in what you can quantify versus what still requires human judgment.

Fourth, refusal is better than fabricated certainty. When a requested claim lacks evidence, the workflow should stop instead of inventing a source, number, comparison, or confident conclusion.

Fifth, publicly inspectable rules beat hidden “trust us” standards. The public Groundcrew ethics document and doctrine file do not prove every output is correct. They do let a skeptical reader inspect stated constraints rather than relying on marketing language alone.

Doctrine-to-rule mapping

The doctrine becomes useful when each principle maps to an enforcement behavior. This compact table shows the five mappings we use as the current operating model.

Principle Public artifact Response Trigger Operator action Name the evidence Evidence schema (illustration) Hard refusal Factual claim has no identifiable source Add a source or remove the claim Use current-state framing WHY-NOT-SLOP (doctrine) Soft pushback Copy implies an unverified future result Rewrite in present tense and state the limit Separate fact from judgment Valid evidence example (illustration) Soft pushback Measurement and interpretation are blended Split the observed field from the conclusion Refuse fabricated certainty ETHICS (doctrine) Hard refusal Request asks for guarantees or unverifiable comparisons Decline or replace with supported wording Make rules inspectable TrustGrowth public proof (current public evidence) Hard refusal Required evidence is missing at the publish gate Attach and label inspectable evidence

The schema and example above are illustrations of evidence structure, not proof of a live run. The proof page is current public evidence, not evidence of a promised outcome. Those labels matter because the same URL can otherwise be made to carry more weight than it supports.

Hard refusals versus soft pushback

A hard refusal stops the workflow until a blocking problem is resolved. A soft pushback flags rigor or clarity that can be improved without pretending the issue is equivalent to a false claim.

In our current setup, a factual claim without a source is a hard refusal. So is an outcome guarantee, an unverifiable comparison, a request to expose private write surfaces, or an attempt to publish while required evidence or media is absent. The operator must remove the claim, provide an appropriate source, or satisfy the gate.

Soft pushback covers wording that is vague, repetitive, or insufficiently qualified. It also covers passages that blend measured evidence with interpretation or use a generic example where a public artifact would be clearer. The operator can continue editing, but the warning should result in a concrete revision.

This distinction prevents two opposite failures. Treating everything as a hard stop makes a review system noisy and easy to ignore. Treating everything as advice lets unsupported claims pass behind polished prose.

How the doctrine appears in TrustGrowth today

The public signals are deliberately modest. The TrustGrowth proof page exposes current public evidence that can be inspected. It should be read as a current snapshot with its own context, not as proof that a particular intervention caused a ranking or traffic result.

The same boundary appears in the explanation of Site Health Score checks before rankings enter the discussion. It separates checks the system can surface from outcomes the system cannot promise. Likewise, the E-E-A-T measurement article separates quantifiable signals from questions that still require human judgment.

These pages do not establish that every published item satisfies every doctrine rule. They show the current public pattern: expose what can be inspected, name limitations, and avoid converting a score or check into a guaranteed result.

What the doctrine does not solve

Public rules do not eliminate editorial mistakes. A source can be real but misread. A sentence can be technically qualified and still be unhelpful. A checklist can catch missing evidence without judging whether the overall argument deserves attention.

The doctrine also cannot automate every trust decision. E-E-A-T includes interpretation that is not reducible to a single objective field. Public proof can show current evidence without establishing causation. A repository rule can document intended behavior without proving flawless enforcement in every context.

The honest claim is narrower: these constraints make certain failure modes easier to detect and harder to wave through. They do not guarantee usefulness, accuracy, rankings, or commercial performance.

Apply an anti-slop doctrine to your workflow

Start by listing the claim types your team will not publish without named evidence. Keep the list concrete: unattributed statistics, anonymous benchmarks, guaranteed outcomes, invented comparisons, and claims about systems the writer cannot inspect.

Next, divide review responses into hard refusals and soft pushback. A missing source should block. A repetitive paragraph should be tightened. Write the required operator action beside each rule so reviewers do not merely label problems.

Then require source labels. “Analytics says” is weaker than naming the relevant system or public artifact. The goal is not to decorate copy with links; it is to keep each claim inside the boundary of its evidence.

Finally, make part of the system inspectable. Publish a checklist, doctrine file, example schema, or proof surface. Label doctrine as doctrine, examples as illustrations, and live evidence as current evidence. That vocabulary keeps readers from mistaking a design artifact for a measured result.

Publication checklist

• Credit WHY-NOT-SLOP to the newsjack.sh skill pack.
• Link at least one public Groundcrew repository artifact.
• Include and label current public evidence or measured-data media.
• Remove outcome guarantees and unsupported comparisons.
• Do not name competitors or expose private write surfaces.
• Use current-state wording and state important limitations.
• Mark each review response as a hard refusal or soft pushback.
• Check that every named artifact or article is a clickable live URL.

FAQ

What is an anti-slop doctrine?

It is an enforceable set of content constraints aimed at preventing unverifiable, generic, or overconfident output. It changes what gets blocked, revised, sourced, or disclosed.

How is it different from a style guide?

A style guide usually governs tone and presentation. An anti-slop doctrine adds evidence requirements, refusal conditions, limitation language, and operator actions.

Why publish the rules?

Public rules give readers an inspection surface. They do not prove perfect execution, but they make the stated standard testable rather than hidden.

What is the difference between hard refusal and soft pushback?

A hard refusal blocks progress until a factual or safety problem is fixed. Soft pushback asks for clearer, tighter, or better-qualified copy while preserving an explicit review signal.

Does the doctrine guarantee accurate or high-ranking content?

No. It reduces named risks such as unsupported claims and fabricated certainty. It does not guarantee accuracy, rankings, traffic, usefulness, or business outcomes.

Conclusion

The anti-slop doctrine is a current operating constraint, not a promise machine. Its practical test is straightforward: can a reader inspect the rule, can an operator name the evidence, and does the workflow stop when certainty exceeds support?

The public doctrine, ethics, schema, example, proof, and score explanations above show how we currently answer those questions. They also show the boundary: inspectable evidence can support careful current-state claims, but it cannot manufacture certainty.