Sweep Terminology Drift Across Your Product

Workflow area: Content & UX Writing · Tier: Core · Hands-on time: ~30 minutes

Terminology drift is invisible from inside any single file. Each screen's copy looks fine locally; only the whole corpus reveals that "remove," "delete" and "discard" are being used interchangeably, that onboarding reads at grade 6 and settings at grade 14, and that the billing flow is somehow the only chirpy part of the product. Reading every string side by side used to be a week of content-designer time. A model can cluster the corpus in minutes — leaving you the part that actually needs a human: deciding which term wins.

When to use — and when not to

• Use it when multiple teams write stringsdrift is the default outcome of parallel feature teams; sweep quarterly or after every big release.
• Use it before building the pb-27 voice enginethe term base this sweep produces is the TERMINOLOGY block of that system prompt; adjudicate first, encode second.
• Use it before localizationevery synonym you ship multiplies into every target language; one sweep here saves N sweeps there.
• Skip it if you can't export stringsscreenshots of every screen work but cost more than they return for a small product; get the string file first.
• Skip the full sweep for a single known conflictif the fight is just "delete vs. remove," adjudicate it in a meeting and move on.

The recipe

1. 1.

   Export the corpus. Pull every user-facing string: localization files (JSON, XLIFF, strings), CMS exports, and Figma text layers for unshipped work. Include string IDs — findings without IDs can't be fixed. Dedupe, then note the count; a few thousand strings is normal and fine.

2. 2.

   Run the drift analysis. Paste the corpus (or attach the file) with this prompt:

   Copy

   Here is our product's full string corpus with IDs. Analyze it for
   terminology and tone drift. Do not rewrite anything yet.
   
   1. SYNONYM CLUSTERS: group different terms used for the same concept
      (e.g. remove/delete/discard, workspace/project/board). For each
      cluster list every variant with its string IDs and a count.
   2. TONE OUTLIERS: flag strings whose register clearly differs from
      the corpus norm (jokey, apologetic, formal) with IDs.
   3. READING-LEVEL SPIKES: flag strings well above the corpus's typical
      reading level, with IDs.
   4. CASING & PATTERN INCONSISTENCY: title case vs. sentence case,
      terminal periods on some tooltips but not others.
   
   Output as four tables. Report ONLY what is in the corpus — do not
   infer strings that are not present.
   
   [PASTE CORPUS OR ATTACH FILE]
   

   Good output looks like this:

   Copy

   SYNONYM CLUSTERS
   Concept: remove an item
     "Delete"  — 41 uses — IDs: btn.file.del, dlg.confirm.del, ...
     "Remove"  — 27 uses — IDs: btn.member.remove, ...
     "Discard" — 6 uses  — IDs: editor.discard, ...
   Concept: main container
     "Workspace" — 88 · "Project" — 31 · "Board" — 4
   

3. 3.

   Spot-audit before you trust it. Pick two clusters and check five listed IDs each against the real corpus. You are looking for the two classic failures: invented strings (an ID that doesn't exist) and false merges (a cluster mixing genuinely different concepts — "delete a file" and "delete an account" may deserve different words). If more than one in ten checks fails, tighten the prompt and re-run before adjudicating anything.

4. 4.

   Adjudicate — this part is yours. For each cluster, a human decides the winner and the rule. This is design judgment, not string counting: "remove" for reversible actions, "delete" for permanent ones is a distinction, not drift. Record each decision in a term base: term, definition, when to use, never-use list, decided-by and date. Where the split is contested, take it to the team; the sweep gives you counts and evidence, which is what ends the meeting.

5. 5.

   Generate the fix list and feed the system. Have the model turn the adjudicated term base plus the cluster tables into a change list — string ID, current text, corrected text — for review, then batch the updates into your localization files and Figma. Finally, paste the term base into your pb-27 voice-system prompt so new strings stop drifting the day the old ones are fixed.

Make it yours

• Google Sheets as the adjudication table: dump the cluster output into a sheet with columns for winner, rule, and status; content design adjudicates asynchronously and the sheet becomes the living term base your prompts and docs both cite.
• Writer for continuous enforcement: load the adjudicated term base into Writer's style-guide engine so violations get flagged as people type — the quarterly sweep then only catches what slipped past the live gate.
• Claude Project for the recurring sweep: keep the prompt, the term base and last quarter's cluster tables in one Project; each new sweep asks "what changed since last time?" and drift becomes a trend you track, not a surprise you rediscover.

Quality check

• Every finding carries string IDs that existyou spot-checked; a cluster you can't trace is a cluster you can't fix.
• False merges got splitintentional distinctions (delete vs. remove) were recognized as rules, not flattened into one winner by majority vote.
• A human made every adjudicationthe model counts usage; it must not pick winners. Frequency is evidence, not authority.
• The term base has rules, not just words"use X" without "when" reproduces drift with new vocabulary.
• The loop is closedthe term base landed in the voice-system prompt and (if you have one) the live linter; a sweep that only produces a document will need repeating forever.