You inherit 400 streams under four naming conventions, with abbreviations nobody can expand — what do you standardise, and what do you leave alone?

## Two problems wearing one name "Our naming is a mess" is almost always two separate complaints, and they have different fixes and different prices. - **The grammar is inconsistent** — four conventions, different segment orders, different separators. This is fixable by decision. Write one grammar, publish it, and apply it to everything created from today. - **The vocabulary is dead** — a leading segment is a three-letter abbreviation whose meaning left with the team that coined it. No grammar fixes this, because the name is already well-formed. What is missing is the expansion, and publishing it costs nothing and changes no stream. A leader who conflates the two proposes a rename programme when half the value was available for the price of a published table. ## Apply forward, rename by danger 1. **Publish the grammar once**: segment order most-general to most-specific, the separator the platform accepts, a conforming example, and an explicit list of what must not appear in a name. 2. **Publish a closed vocabulary for the domain segment**, with every abbreviation's expansion, held with the estate's own inventory rather than on a page owned by one team. 3. **Apply it to new streams**, and accept that the estate will be mixed for years. 4. **Rename only where the name is dangerous**, which is a short list, not a sweep. 5. **Record which prefixes are legacy**, so the four conventions are a documented fact rather than a discovery someone makes during an incident. The dangerous names are worth naming explicitly, because everything else is taste: - a **wrong or missing environment segment**, since grants and automated sweeps are written against that prefix and the failure is real traffic treated as disposable; - a name that **sits under another domain's prefix**, and is therefore already inside that domain's grant — an access problem, not an aesthetic one; - a name that **collides with a prefix the platform reserves** for its own internal streams. Everything else stays, because a rename is priced as a migration per stream: grants, quotas, retention settings, mirroring rules, dashboards, alert conditions, cost attribution and runbooks all name the old string, and none of them moves by itself. Four hundred of those is a programme with no outcome a user can see. ## What the standard should forbid Each segment is a promise to keep something true for the life of the stream, so the standard earns as much from its exclusions as from its inclusions: - **the owning team's name** — organisations reorganise faster than domains are redrawn, and the owner belongs in the stream's owner record where changing it is an edit; - **the producing service** — services are split, rewritten and retired while the stream survives them; - **the payload's encoding** — governed elsewhere, on its own schedule; - **a date, a ticket identifier or a project codename** — meaningful for a quarter, misleading for a decade. ## The price of a mixed estate | What you avoid by not renaming | What you pay instead | |---|---| | 400 migrations, each with its own inventory of bindings | every prefix-scoped grant, quota and dashboard query enumerates several patterns | | Coordinating with every owning team at once | a new engineer cannot infer a name and must look one up | | A year of programme with nothing user-visible | automation that keys on the convention carries special cases indefinitely | | Risk of breaking working streams for tidiness | cost attribution by prefix stays approximate | State that table out loud when you propose the policy. The failure mode of "apply forward" is not the decision — it is pretending the decision is free, so nobody ever funds the residue and the special cases are still there in five years. ## The endurance test The standard is being written for an organisation that will outlive its current teams, so test every proposed segment against three futures: a reorganisation that renames every team; a second region or a second cluster; and a second platform, whose accepted character set may be narrower than today's. A segment that survives all three is worth encoding. A segment that fails one of them is a migration you have scheduled without knowing it. The last piece is expectations. Consistency across a legacy estate is not achieved, it is approached, and the measure of success is not that every name conforms but that every name is either conforming or documented as legacy — and that nothing dangerous is left in either set.