De-AI-ification rules — docs.modulos.ai

Docs pages are drafted with Claude, and left unedited they read like it. This is the rulebook for keeping AI-writing tells out of everything a reader — human or agent — sees on docs.modulos.ai.

This is technical documentation, not prose. The target register is precise, neutral, and scannable — not "natural human voice." That cuts both ways:

• Structural uniformity is a documentation virtue, not a tell. Parallel bullet grammar, repeated page skeletons, tables, and saying "control" fifty times on a page about controls are all correct. Never add variation, personality, or rhythm for its own sake.
• The tells to remove are lexical (marketing vocabulary), rhetorical (templates, padding, filler), and typographic (em dashes) — never structural discipline.

Sources: the courses repo de-AI-ification rulebook, Wikipedia's "Signs of AI writing" (WikiProject AI Cleanup catalog), 2025–2026 reporting on AI writing tells, an audit of this repo (see Enforcement for the baseline), and a calibration audit against ten widely admired docs sites (Stripe, Twilio, Tailscale, Cloudflare, PostHog, FastAPI, React, MDN, Django, Rust Book; 2026-07) — the carve-outs in bans 1, 5, 9, and 16 and in Register C come from where those sites' good writing would otherwise be flagged.

---

The three registers

Register	Surfaces	Grammar
A — Page prose	body text of framework, platform, guide, and resource pages	WRITTEN. Complete sentences. Claims name their mechanism (article, requirement ID, control ID, UI location).
B — Machine-facing metadata	frontmatter description, faqs: answers (→ llms.txt, JSON-LD), AnnotatedScreenshot alt	WRITTEN, dense. Complete sentences that survive being quoted out of context by an agent. Facts and IDs, no benefit language.
C — Micro-copy	headings, sidebar labels, LinkCard titles/descriptions, ConceptSteps labels, captions, annotation titles, FrameworkCTA body, table cells	Clean noun phrases or one short claim. No terminal periods on headings/labels. No teasers.

Everything in Register B is consumed verbatim by LLMs and search engines: an agent will read the FAQ answer aloud to a compliance officer. It gets the strictest factual-density standard on the site.

---

The term-of-art exemption (read this first)

This site quotes regulations, standards, and official guidance. Quoted source text is never rewritten — not for em dashes, not for vocabulary, not for anything. Blockquoted article text, verbatim NIST subcategory statements, and official framework names stay character-for-character.

In our own prose, source vocabulary survives only when it names the source's concept:

• "the Article 15 accuracy, robustness and cybersecurity obligations" — keep.
• "trustworthy AI" as NIST's named set of characteristics — keep, attributed.
• "a robust logging pipeline", "a comprehensive governance platform" — our voice, banned. Say what it does instead.

The test: could you put a citation after the word? If yes, it is a term of art. If no, it is an adjective, and the blacklist applies.

---

Hard bans (all registers, our voice only)

1. Em dashes in prose. Replace with comma, colon, parentheses, or a period. Three sanctioned structural uses remain: the **term** — explanation / `ID` — explanation list-separator token, the Article 28 — Title locus grammar in headings, and en dashes for ranges (2023–2026, Articles 24–25). En dashes are for ranges only: a spaced en dash used as a clause break (lazy – the act of creating…) is the same tell in different clothing and equally banned. Frontmatter descriptions and FAQ answers are prose: no em dashes there.
2. Terminal periods on headings, sidebar labels, LinkCard titles, kicker-style labels.
3. Contrast templates: "It's not X, it's Y", "not just X, but Y", "no X, no Y, just Z". Real regulatory distinctions survive (provider vs deployer, org-side vs app-side, readiness vs fulfilment); the banned thing is the template as styling.
4. Rule-of-three triads where the count is not load-bearing. "28 requirements and 81 controls" lives — the count is the content.
5. Copula avoidance: "serves as", "stands as", "acts as", "represents a" → "is". "Offers/boasts/features" → "has". Carve-out: "represents" and "acts as" survive when identity would overclaim — a role, an analogy, or a proxy relation ("a QuerySet represents a collection" is correct because a QuerySet is lazy). The tell is decorating "is", not naming a real non-identity relation.
6. AI vocabulary blacklist (our voice; see exemption above): delve, robust, seamless, crucial, pivotal, vital, leverage (verb), harness, landscape (abstract), ecosystem (abstract), realm, tapestry, foster, cultivate, testament, underscore (verb), showcase, intricate, holistic, comprehensive, multifaceted, meticulous, vibrant, journey, embark, unlock, unleash, empower, elevate, supercharge, streamline, navigate the complexities, game-changer, transformative, revolutionary, cutting-edge, ever-evolving, fast-paced.
7. Significance padding: "plays a vital role", "marks a shift", "setting the stage for", "underscores the importance of", "reflects a broader trend".
8. Throat-clearing: "At its core", "Fundamentally", "It's important to note", "Simply put", "What this means is".
9. Signposting: "In this guide, we'll explore", "Let's dive into". A concrete scope statement ("This page covers X") is required, not banned; the ban is the vague preview that promises value without naming the deliverable. In guide/ tutorial pages, "we'll/let's" wayfinding is acceptable when the next sentence cashes it out as a literal action.
10. Benefit boilerplate: "helps ensure", "enables organizations to", "allows teams to", "supports better outcomes". Name the mechanism: the requirement ID, the control, the UI action, the article. "ORF-425 requires a maintained model inventory" beats "the platform helps ensure visibility".
11. Fake universality: "Whether you're a CISO, a developer, or a compliance officer…". The by-role guide pages exist precisely so each page can address one actual reader.
12. Moralizing or horizon-scanning wrap-ups: "Ultimately, AI governance is a journey", "As the regulatory landscape continues to evolve…". Pages end on the mechanism, the next step, or the CardGroup/FrameworkCTA — never on a sermon or a weather forecast. No "Conclusion" or "Key takeaways" sections.
13. Vague attribution: "experts recommend", "organizations increasingly", "industry best practice suggests". Name the source: the article, the guidance paragraph, the NIST section, the Modulos control. If there is no source, it is our claim — state it plainly and own it.
14. Stat and severity drama: staggering, massive, sweeping, game-changing. Fine amounts and deadlines carry their own weight: "up to €35 million or 7% of worldwide annual turnover" needs no adjective.
15. Hedging stacks: "may potentially", "can often". One hedge maximum, and only where the legal uncertainty is real (then say why it is uncertain).
16. Present-participle trailing claims: "…, ensuring compliance", "…, enabling traceability". The banned tail claims a vague benefit; a concrete causal consequence (", resulting in one fewer round-trip") may stay when it states a mechanism. If the claim matters, give it its own sentence with a subject.
17. Over-neat transitions: "This is where Modulos comes in", "That's why governance matters". State the mapping directly: "In Modulos this is ORF-432."
18. Elegant variation: never rotate synonyms around a precise term. A control is a "control" every time — never "measure", "safeguard", "mechanism" in rotation. Same for model, requirement, review, evidence, framework. Regulatory terms are load-bearing; a synonym changes the meaning.
19. Knowledge-cutoff hedges: "as of this writing", "at the time of publication". The git history dates every page. State the fact with its own date instead ("applies from 2 August 2026").
20. Mechanical bold in prose — bolding every occurrence of a key term. Bold marks structure (lead-ins, the operative phrase in a dense paragraph), used once.

Register B — metadata rules

• Descriptions are agent-useful (what + when), per LLMS_TXT_MAINTENANCE.md — and they are also prose: no em dashes, no blacklist vocabulary, no benefit boilerplate.
• FAQ answers must survive verbatim extraction: complete sentences, IDs and article numbers spelled out, no pronouns whose antecedent lives outside the answer.
• Never let a description promise more than the page delivers ("comprehensive guide to…"). Agents route users on these strings; an oversold description is a broken link in prose form.

Register C — micro-copy rules

• Headings say what the section contains. Sentence case, no terminal punctuation, no movie-poster teasers ("The Hidden Cost of Shadow AI"), no generic templates ("X: Why It Matters"). Question headings are allowed when the question is the reader's own at that point and is answered immediately below — FAQ sections, troubleshooting anchors ("Seeing a 403?"), reader self-selection ("Not a developer?"). Teaser and rhetorical questions stay banned.
• LinkCard descriptions: one clean claim about the destination, not an invitation ("Learn how…" is banned in card and link descriptions; an inline cross-reference sentence in body prose ("Learn how to export evidence.") is ordinary usage and fine. "Execute, review, and export controls" is the card form).
• Captions and annotation text: state what is shown and what the reader does with it. No benefit language inside <AnnotatedScreenshot> annotations.
• FrameworkCTA body: one pitch sentence, concrete, zero blacklist words. This is the highest-risk surface on the site for marketing slop; hold the line here hardest.

Keep list (house style, not tells)

• Structural uniformity. Parallel bullet grammar, repeated page skeletons, identical section orders across sibling pages, tables for enumerable facts. This is technical documentation; predictability is a feature.
• The **term** — explanation list separator in requirement/control breakdowns (and its `ID` — explanation variant). This is the sanctioned em-dash use: a design token, machine-distinguishable, never valid mid-sentence.
• The Article 28 — Title heading grammar: locus, em dash, subject. Same token logic.
• Modulos ID grammar: ORF-425, MRF-397 references, MCF-639 control lists. Precision is the product.
• Verbatim regulatory quotes in blockquotes, however "AI-flavored" the source language is. The law says "sound, comprehensive and well-documented"; we quote it.
• Terminology discipline: "reviews" (not "review records"), "remediation loops" (not "remediation workflows"). Repetition of the precise term is correct.
• Load-bearing counts: 28 requirements / 81 controls, the four NIST functions, the five risk-rating dimensions. The count must be used, not decorative.
• Concrete anchors: article numbers, OJ dates, fine amounts, control IDs, UI paths (Project → Controls).
• En dashes for ranges, sentence-case headings, ::: tip/warning/info containers (sparingly, never as a CTA).

Enforcement

• New copy: these rules bind at authoring time. Referenced from CLAUDE.md.
• Existing copy: reduced gradually through targeted edits. When a PR touches a page, sweep that page against this rulebook in the same PR (run node scripts/slop-check.mjs <page>.md before and after). The sweep unit is the whole page, not the touched paragraph — a partial sweep leaves a page stylistically split. No dedicated big-bang cleanup branch; the baseline shrinks page by page.
• Mechanical checks: npm run slop:check (scripts/slop-check.mjs) counts em dashes in prose (blockquotes, headings, and separator tokens exempt), blacklist vocabulary outside blockquotes, heading periods, copula avoidance, trailing participials, contrast templates, and benefit boilerplate. Informational, not a CI gate. Blacklist hits require a term-of-art judgment before fixing.
• Baseline at adoption (2026-07-15, 175 pages): 2,428 prose em dashes, 43 blacklist hits (mostly term-of-art candidates), 18 copula-avoidance hits, 13 heading periods, 2 trailing participials, 2 contrast templates, 0 benefit boilerplate.
• Editorial checks (reading pass, not grep): teaser headings, fake universality, moralizing endings, elegant variation, oversold descriptions.