Ownership and Change
Every taxonomy changes. Who owns it, how each change goes on the record (a version, a date, a mapping), and how to run a change as a period: before, cutover, overlap and close.
On this page
Next year’s review. You pull the channel report for July and set it beside the July before. Example numbers, in sessions:
| Medium | Last July | This July |
|---|---|---|
social | 4,000 | 1,600 |
paid_social | 2,800 |
Organic social is down 60%. And a channel nobody remembers launching brought in 2,800 sessions from nowhere.
What happened? Make your guess before you read on.
Chapter 9 ended on a question. Now the rules live in the tool. Who changes them?
It’s easy to believe nobody needs to. The rules are written, the team is trained, the tool offers only approved values. The taxonomy runs itself.
But the rules have to change: a new question, a new channel, a new region. And a change nobody owns still happens. Whoever needs it makes it, on the day they need it, and tells whoever is nearby. Every link after it can be perfect, and the history still breaks:
- A relabel reads as a collapse.
- Last year stops comparing with this year.
- Where one list serves several clients with no boundaries, one client’s value ends up on another’s link.
The history broke, and nobody made a mistake
On July 1, your team started tagging paid posts paid_social instead of social. It was the right call: paid_social is the medium for paid social. Every link from that day on followed the new rule.
Nobody wrote the change down.
So last July’s social held paid posts and organic ones together, and this July the paid posts have a row of their own. Here’s the same report twice, as it stands and with one changelog entry beside it:
Example numbers
No record
| Medium | Last July | This July |
|---|---|---|
social | 4,000 | 1,600 |
paid_social | 2,800 |
Organic social down 60%, and a new channel from nowhere.
One changelog entry
| Medium | Last July | This July |
|---|---|---|
Flagged: social | 4,000 | 1,600 |
Flagged: paid_social | 2,800 | |
| Both | 4,000 | 4,400 |
Break on July 1: paid posts moved from social to paid_social. Only the sum compares.
Work it both ways.
Without the record, social fell from 4,000 to 1,600. That’s 2,400 sessions gone, 60% of the channel.
With it, last July’s 4,000 held both kinds of post, so it compares only with both of this July’s rows. 1,600 plus 2,800 is 4,400. Against 4,000, that’s 400 more: up 10%.
Down 60% or up 10%, from one set of sessions.
Couldn’t you split last July’s social into paid and organic, and compare like with like? No. It’s Chapter 1’s mailchimp row again: a value that held two meanings can’t be remapped, because no correction is right for both. So the report marks the break and compares the sum.
Nobody typed a wrong value. The change was right, and every link after it followed the rule. The history broke anyway.
The only difference between the two reports is the record.
The hardest part of governance isn’t the rules. It’s getting a VP to care about naming conventions. We’ve been in that meeting. What works is showing them the two versions of the same report. The pitch built around a pair like it, and what to measure afterwards, is in the Executive Summary.
No owner, no taxonomy
Why does a taxonomy have to change at all? Because of where it came from. Chapter 1 drew its dimensions from the reports you need, and those reports grow. The board asks a new question. Marketing opens a new channel. The company starts selling somewhere new. A frozen taxonomy stops answering, and an unowned one changes anyway, in whoever’s hands.
So yours will change. What you decide is whether each change lands on the record.
With the rules inside the tool (Chapter 9), every change to them is an act in one place: adding a value, retiring one, changing a pattern. One person makes each one, the taxonomy owner.
No owner, no taxonomy.
Without one, the July relabel is how every change happens: a sensible edit, made by whoever needed it, written down nowhere, and found a year later as a collapse that never happened.
The owner has three jobs:
- Approve new values. Dana’s rule in Chapter 3 was “ask me first.” Here it’s a role, with a name on it: someone wants
tiktokas a source, and the owner adds it to the list, with its meaning, or says no. - Run the audit. Chapter 8’s audit, made someone’s job instead of something someone remembers.
- Keep the record.
Write every change down
The record is a changelog: one entry per change, and each entry a new version of the rules. An entry has four parts:
- what changed
- the date it takes effect
- the mapping from old to new
- who made it
Your July change fits in one entry:
| Part | July’s entry |
|---|---|
| What changed | paid posts take paid_social, not social |
| Takes effect | July 1 |
| Mapping | social before July 1 held paid and organic posts: no remap, only the sum compares |
| Made by | the owner |
A year later, that entry is the difference between the two reports above.
Versioning is what the entries add up to: anyone can read a recorded click by the rules in force when its link was made. A click doesn’t carry its version. For a click from before a change, its date tells you: a social click from last July was made when social meant every social post. After the change the date can’t, because long-lived links keep sending the old values. The shape tells you instead, as Stride’s change below shows, where old names and new ones differ in their segment count.
Map the old to the new
The changelog’s working half is the mapping table: each old value or pattern, what it becomes, and whether old data can be remapped. Old data gets one of four readings, two for a value that changed and two for a field that’s new:
| Old data | Reads as | When |
|---|---|---|
| A changed value | the new value (a remap) | it meant one thing |
| A changed value | a marked break | it held two meanings |
| A new field | a value derived by lookup | it follows from something recorded |
| A new field | unknown | nothing recorded implies it |
Last July’s social is the second row. Stride’s change below is the third: a region that follows from where Stride sold.
The fourth row takes discipline.
Unknown is an answer. A guess written into the table looks like data, and every report built on it inherits the guess.
This is how a taxonomy compounds into an asset. Three years of paid_social compare with each other only if every change across them is on the record. Leave one unrecorded and the comparison stops at the day it happened.
A council decides, one owner holds the pen
The owner can be one person, or a council of the teams that use the taxonomy:
| One owner | A council | |
|---|---|---|
| Gives | one voice, fast decisions | every team’s say |
| Costs | the other teams’ say | slower decisions |
The two don’t conflict. A council decides; one owner still makes each change and keeps the record.
A council with nobody holding the pen is the July relabel with more meetings.
Below the owner sit the people who define each campaign and the people who build its links. In one stage they’re the same people; where several teams share a campaign, Chapter 9’s two-stage workflow makes them separate teams. What belongs here is what a change asks of each role:
| Role | Does | A change asks of them |
|---|---|---|
| Owner | changes the rules, keeps the record | the entry, mapping and date |
| Defining team | defines each campaign | the new pattern, from its start date |
| Link builders, in-house or agency | build links from it | the news, when the form changes |
| Report readers | read the reports | the news, before comparing |
Contractors and agencies sit in the third row. They get the defined campaign value, ready to use, not a naming guide to interpret.
Change it once, or once per copy
When several teams, brands or clients share a taxonomy, the list itself is a choice. Each team can see its part of one master list through a workspace (Chapter 9’s term: one team’s view of the list), or keep a copy of its own:
| One master list | A copy per team | |
|---|---|---|
| Each team sees | its part, in a workspace | a whole list of its own |
| One change | made once | made once per copy |
| Buys | one set of rules, one record | each team its own rules |
Run one change through each. Add a value to the master list and it’s one edit, one date and one changelog entry, and every workspace that should offer it does. With four copies it’s four edits, four dates and four entries, kept by whoever keeps each copy.
Nothing makes them match.
One copy gets the change a week late; another spells it its own way.
A workspace narrows the master list, never widens it: a team can see fewer values than the master holds, never one the master doesn’t.
Copies have a real case: each team or client gets rules of its own. If your teams’ rules differ, that’s what the price per change buys.
Chapter 8’s Marcus typed his values by hand, outside the rules. At an agency with twelve clients on one list, a slip that broke no rule went unnoticed for six weeks.
Leo picked from the menu he was given. One shared list without boundaries put the mistake on it.
A change is a period, not a switch
A changelog entry has one date. The change it records doesn’t end there. Links already in the wild keep sending the old values for as long as they stay in use: a printed QR code, a saved email template, a link in a bio. Old and new formats run side by side until the longest-lived link stops.
So a change is a period, and it runs in four phases: before, cutover, overlap and close.
Stride’s own change shows all four. Jump ahead some months, past the board meeting in Chapter 11. Stride starts selling in Europe, and the trigger Dana wrote down in Chapter 4 fires: the campaign pattern gains a region. Dana owns the change, and it becomes version 2 of Stride’s Tracking Constitution.
Before
The job: get everything that reads the values ready before anything new ships.
- a change request, tied to the report that needs it
- an inventory: the links in the wild, and every system that reads the values
- the people to tell: the builder’s record of who made which link names everyone making links
- the mapping table
- a cutover date, for campaigns launching from then
- the readers taught both formats, first
Dana’s request is Chapter 4’s question, sales by region. Her inventory comes out as two lists:
- where the values are written: the newsletter templates, the Meta campaign names (the join key, so they change with the pattern), and the QR code printed for the Fleet Feet NYC display
- what reads them: GA4 and the hyphen split her reports use (Chapter 4), the CRM’s hidden fields, the spend join
Her mapping table gives every three-segment name region us, by lookup, because before the cutover Stride sold only in the US. The cutover is set for campaigns launching from 2025_09.
Then, before the builder offers a single new name, her parser learns both formats. It tells them apart by segment count: three segments are the old pattern, four the new. No four-segment name ever meets a parser that expects three.
Cutover
The job: make the new format the only one on offer, and say so.
- the tool offers only the new pattern
- the changelog entry
- the news, in order: link makers, then report readers, then agencies
From 2025_09 the builder assembles every new campaign from four menus, in one pattern, [region]-. The fall sale launches under it twice, as europe- and us-fall_sale-runners-2025_09. Campaigns already running finish as they are, under the values they launched with.
The changelog gets its entry: version 2, for campaigns launching from 2025_09, three-segment names read as region us, made by Dana. Then the news goes out, link makers first, because they meet the new values first, and then whoever reads the reports, because four-segment names are about to appear beside three-segment ones.
Overlap
The job: read both formats as one, and watch the old one fade.
- one combined view, or a marked break: never the two silently mixed
- the audit watches the old format’s share of new clicks fall
- each long-lived link replaced or remapped, once
Stride’s reports get one combined view, with the region column filled by parsing for new names and by lookup for old ones:
| Campaign | Region |
|---|---|
spring_sale-runners-2025_03 | us, by lookup |
us-fall_sale-runners-2025_09 | us, parsed |
europe- | europe, parsed |
Dana’s audit watches the share of new clicks still arriving in the old format. It falls as the running campaigns end, down to one tail: the QR code at Fleet Feet NYC. Scanned through stride.co/nyc25, it still sends spring_sale-runners-2025_03, long after its six-week sale.
A long-lived link gets one decision, made once:
- Replace it. Reprinting the code costs a reprint. Pointing the short URL at a new value costs something less visible: one campaign’s clicks would arrive as two strings, and a report groups by the exact string.
- Remap it. Leave the code alone and read its clicks through the mapping table. Its name is three segments, so its region comes out
us, by lookup, like every old name’s. (Remapping a link means exactly this: reading what it sends through the mapping table, whichever row applies.)
Dana keeps the remap.
Close
The job: end the period on purpose, by a rule set before it began.
- a close criterion, set up front
- the old format retired from new links, and kept for history
- the mapping table, kept for good
Dana set hers before the cutover: the change is over when every old-format click comes from a known, remapped link. Once the audit shows only the Fleet Feet NYC code in the old format, it is. The three-segment pattern is retired from new links and kept for reading the history. The mapping table stays for good, because the code still needs it, and so does every report that reaches back before 2025_09. The formats still coexist while the code is in use; closing means every old-format click is known and read through the table.
The change is over. The table never is.
How much of this a change needs depends on how many teams and systems it touches, not on headcount. Dana’s fits on a page: one team switching, a few systems to teach. Where teams work in two stages, it shrinks, because only the team that defines campaigns switches patterns, and every channel team receives values already in the new shape. A one-page copy of the four phases, with where links hide and templates for the entry and the table, is in the Cheat Sheet. When the values being changed were never governed at all, When You Inherit a Mess puts the catalog and the map before these phases.
Your situation
Four things set the size of your version:
- How many teams, agencies or clients share the taxonomy. One team: one owner may be enough, and a change’s size depends on the systems it touches. Several: owner or council, master list or copies, and every change has more people to tell.
- How many systems read the values. Each one is a line in the inventory, and a reader to teach both formats before the cutover.
- How long your links live. Print, QR codes, saved email templates and bios set the length of the overlap. If every link ends with its campaign, the overlap ends with the last running one.
- How often your questions change. Rarely, and a change is an occasion you plan once. Often, and the changelog is routine, and every choice that makes a change smaller matters more.
What changes
| Decision | Before | After |
|---|---|---|
| Once the rules exist | done, runs itself | expect change; name one owner |
| Changing a value | the day someone needs it | on the record: version, date, mapping, owner |
| Switching formats | a date, then move on | four phases, until the longest-lived link stops |
| A drop year over year | read as a drop | check the changelog for a break first |
| Many teams or clients | a copy each | master list, or copies changed one by one |
Where the rule lives
A change to the rules has the same two homes as the rules themselves:
Beside the path
Announced in a meeting or a doc, the change is something everyone has to remember, and the old value stays one keystroke away.
Inside the path
Made in the tool, the new pattern is the only one offered from the cutover, and the changelog sits where the rules live.
Check yourself
From October, campaign names gain a goal segment. What does the mapping table say for a campaign launched in June?
Show answerHide answer
If the goal follows from something recorded, such as a campaign that only ever sought sign-ups, the table derives it by lookup. Otherwise it says unknown, never a guess. The table says which, so a report can show both.
Months after a cutover, a trickle of new clicks still arrives in the old format, all from a printed catalogue's QR codes. Is the overlap over?
Show answerHide answer
Close on the criterion you set up front, not on a date. Once every old-format click comes from a known long-lived link that’s been remapped or replaced, retire the old format from new links, keep reading the tail through the mapping table, and keep the table for good.
An agency keeps one copy of its taxonomy per client, twelve copies, and adds a region segment to its campaign pattern. What does the change cost, and what would a master list with workspaces change?
Show answerHide answer
Twelve edits, twelve dates, twelve chances to drift, and twelve changelogs. With one master list the change is made once, on the record, and each workspace narrows it. Copies buy each client its own rules, which is their case.
In one line
A taxonomy will change. It keeps its history when one owner makes each change on the record (a version, a date, a mapping) and runs it as a period: before, cutover, overlap, close.
Before the next chapter
Write down who approves a new value today, and where your last change to the rules is recorded. If the answer is nobody or nowhere, that's your first change.