Em-dashes are now the unmistakable AI watermark. We avoid them everywhere: marketing copy, product copy, docs, changelog, and every AI feature we build.

This card establishes the rule, audits existing copy, and bakes the constraint into every AI prompt and every copy lint check so it sticks.

The rule

Never use:

• Em-dash (the long one)
• En-dash where a hyphen will do
• Any long Unicode dash in general

Use instead, in order of preference:

• Comma for short asides
• Period for hard breaks
• Colon for explanations
• Parentheses for genuine asides
• Plain hyphen for compound words

Scope

1. Style guide page Add a short page in internal team docs covering the rule, examples, and the rationale (anti-AI-watermark, plainer voice).

2. Codebase audit Sweep src/, content/, public/, docs/ for em-dashes and en-dashes. Replace every instance with the right substitute.

3. Copy lint rule ESLint plugin or a tiny custom rule that flags em-dashes and en-dashes in:

   • JSX/TSX string literals
   • Markdown and MDX content
   • Server-action error messages
   • Email templates Fail the build on detection. Auto-fix offers replacement candidates.

4. AI prompt guardrails Every system prompt for every AI feature gets an explicit clause: "Never use em-dashes or en-dashes under any circumstance. Use commas, periods, colons, or parentheses instead." Applies to:

   • AI Suggest (post improvement)
   • AI changelog drafts
   • AI ticket sanitization
   • AI duplicate detection summaries
   • AI weekly digest
   • AI sentiment and theme summaries
   • AI moderation rationale
   • AI translation (target language permitting)

5. AI output post-processing Defense in depth: every AI response runs through a normaliser before reaching the UI. Replaces em-dashes with comma + space, replaces straggler en-dashes with a plain hyphen, and logs each occurrence so we can tune prompts upstream.

Out of scope

• Quoted user content. We never rewrite what a user typed: post bodies, comments, ticket text, profile bios. The rule applies to our copy and our AI output, not to their voice.
• Code blocks. Em-dashes inside code samples (rare but possible) are left alone.
• Translations into languages whose punctuation legitimately uses long dashes (Spanish or Russian dialogue dashes, for example). The translator card decides per-locale whether the rule applies.

Acceptance criteria

• Style guide page published in internal docs.
• Codebase has zero em-dashes or en-dashes outside user-generated tables and code blocks.
• CI build fails when an em-dash is added to copy.
• All AI prompts contain the no-dash clause.
• Output normaliser ships alongside the BYOK AI foundation card.
• Spot check: ten AI-generated outputs reviewed, zero em-dashes.

Why we care

Em-dashes are not bad punctuation, they are just the punctuation an LLM reaches for first. Removing them forces our voice to feel deliberate and human, signals that our copy was written or edited by a person, and stops every reader who has been online since 2024 from squinting at a sentence and thinking "this was generated."

Bonus: it pushes our writers to make sharper decisions. Every former em-dash becomes a real choice between a comma, a period, or a colon, and the writing gets cleaner as a result.