Slopless

This dataset provides fingerprints of 'tortured phrases' and 'tortured abbreviations' specifically within the Humanities and Social Sciences (HSS) domains, such as education, psychology, and economics.

'Tortured phrases' are artifacts created by AI spinners (like QuillBot) that replace established scientific terms with nonsensical synonyms (e.g., 'bosom peril' instead of 'breast cancer'). This dataset extends existing STEM-focused databases to include HSS-specific examples like 'bound-together domain' instead of 'United Kingdom'.

The 'Tortured Phrases from the Humanities and Social Sciences' is a fingerprints dataset available via Zenodo. It is used for identifying academic 'slop' or non-standard phrasing in research papers.

Dataset Metadata:

• DOI: 10.5281/zenodo.14753785
• Resource Type: Dataset
• License: Creative Commons Attribution 4.0 International (CC BY 4.0)
• Publisher: Zenodo

https://doi.org/10.5281/zenodo.14753785

The Google style guide implementation is organized into three main directories:

• /Google: Contains the YAML-based rule implementations that define the style.
• /fixtures: Contains individual unit tests. Each directory is named after a specific rule from /Google and contains its own .vale.ini file to isolate that rule.
• /features: Contains Cucumber Step Definitions used for testing fixtures via the Aruba framework, which validates Vale's output against the fixture directories.

The llm-cliches dataset is a collection of commonly used clichés and phrases found in Large Language Model (LLM) outputs. It is organized into three text files categorized by part of speech, which can be used to identify or filter AI-generated 'slop' in text:

• adjectives.txt: Words that describe or modify nouns.
• nouns.txt: Words that identify people, places, things, or ideas.
• verbs.txt: Action words that describe what something or someone does.

In AI search, retrieval readiness is the ability of a page to survive the technical processes of chunking, embedding, passage selection, and answer compression.

To achieve retrieval readiness, content must move beyond broad relevance and focus on being a high-quality 'retrieval candidate'. This means:

• Avoiding Vague Content: Instead of phrases like "streamline your workflow," state exactly what the product does.
• Passage-Level Stability: Individual sections (passages) must be extractable, specific, and stable even when separated from the parent page.
• Evidence Density: Pages should contain concrete facts, definitions, criteria, examples, constraints, steps, tradeoffs, metrics, and named use cases rather than just category language and confident phrasing.

The solution-boring-frame rule identifies instances where a solution-like subject is described as 'boring'. The matcher looks for a specific syntactic structure:

1. A determiner: the, this, or that.
2. A solution qualifier followed by a solution noun (newly supported nouns include principle, recommendation, rule, and technique).
3. A scope phrase: one to six words beginning with a declared preposition or that.
4. A linking verb followed by the word boring.

Example structure: [the/this/that] [qualifier] [noun] [1-6 scope words] [linking verb] boring.

The Fresh Slop Corpus Expansion is organized into the following directories:

• texts/: Contains long, realistic prose samples representing various slop-heavy writing styles.
• edge-cases/hits/: Contains compact examples that are intended to be positive hits (slop) and should be reviewed for promotion to future fixture material.
• edge-cases/no-hits/: Contains compact adversarial controls (clean text) that should remain unflagged after review.
• analysis/: Contains first-pass notes regarding potential rule widenings and associated risks.

Low-Rigor Candidate Generators are external sources used to generate hypotheses for new slop detection rules. They should not be used for direct rule adoption. Instead, use them to identify candidate word families, sentence formulas, or tone patterns that can then be validated against more rigorous sources.

Recommended Slopless workflows:

• Derive density-gated tests: Use identified patterns to create rules that trigger based on the frequency of specific terms.
• Create no-hit fixtures: Use these patterns to build test cases that ensure the engine correctly identifies (or ignores) specific slop styles.
• Cross-check: Always validate terms found in these sources against rigorous datasets before promoting them to the core rule set.

The workflow recommends using a small, consistent set of document types, each supported by a lightweight template. Using specific types allows for better routing of reviews (e.g., a runbook goes to operational review, while a decision record goes to ownership review).

Recommended Document Types:

• Decision record: Explains the choice, context, options considered, and the reason for the selected path.
• Runbook: Explains how to identify a condition, steps to take, how to verify results, and when to escalate.
• Reference page: Defines stable information like names, fields, interfaces, owners, or constraints.
• Process guide: Explains recurring work in sequence.
• Project brief: Explains scope, goals, dependencies, and status.
• Review checklist: Defines the standard used during review.