Rebrand cost depends on whether difference stayed inside the system

What it is

A rebrand’s bill rarely tracks how loud the new mark is. It tracks where the old difference lives. If unlike was written into semantic aliases and a few expression components, the rebrand is reassignment. If it leaked into hard-coded colors on pages, private SVGs, components forked from the library and never merged back, the rebrand is archaeology. Rebrand leakage cost writes the construction volume as “how much unlike lived outside the system”. Louder new brand plus more leakage makes the bill less controllable — loudness is not the driver; leakage is.

Why it happens

A reassignment rebrand scales with the count of semantic aliases plus expression components, not with page count. An archaeology rebrand scales with hard-coded occurrences times the labor to find and replace them, linear in pages and repos, and the ones you miss resurface after launch as old color and old mark. Leakage does not hurt on ordinary days: baking a hex on this page is faster than filing a token. Those local optima become full-corpus search debt on rebrand day. Difference inside the system is a rebrand feature: change the values, change the look. Difference outside is rebrand drag: each site must be found, negotiated, folded into the new system or deleted. The cost function follows leak area, not how radical the new look is.

Where it stops holding

A product from before the system existed has leakage as historical given; that rebrand will include archaeology. The claim applies to new leakage after the system claims to have taken over. Print, packaging, and physical space are not in interface tokens; they need their own bill of materials, and interface reassignment will not cover them. User-generated content, third-party embeds, and cached system screenshots will still show the old look after tokens move; they need an expiry policy. In a multi-brand setup, restyling one brand must not rewrite another’s assignments; aliases that should not have been shared are a layering bug that turns one rebrand into collateral damage. Motion and illustration stored as bitmaps rather than recolorable vectors are unreachable from the token layer and must be handled as assets, not as aliases.

Applying it

• Audit leakage before the rebrand: search the corpus for hard-coded color, type sizes that skip semantic aliases, private icons, forked components. List by file, and estimate the split between “assignment will cover” and “hands must edit”.
• Ban new hard-coding on product main paths in ordinary times: an undeclared color or size in a pull request is new leakage, rerouted to an alias on the spot.
• Forked components get a return-by date; overdue forks are deleted or force-assigned at rebrand time, not left as “later”.
• Check: on staging, replace only semantic aliases and expression components; touch no product pages. Every remaining old color, old mark, or old radius on a main path is a leak. Use that count as the real input to the rebrand budget. If main paths already wear the new look after alias replacement, with only campaign art and bitmap illustration left, difference was contained. If product pages barely move, the bill will grow with page count, not alias count — leakage is pricing the job, not the brand proposal.

Related

• Same group: R1.07.1 Systems chase reuse; brands chase difference · R1.07.2 Confine difference to a few expression layers · R1.07.3 Customizing everything forfeits the system's return · R1.07.4 Brand recognition is cheaper on a few high-frequency touchpoints · R1.07.5 Marketing pages and product UI can run different constraint intensities
• Adjacent: R1.01 Design tokens · R1.15 Multi-brand and multi-theme
• Search terms: rebrand leakage cost · semantic alias · hard-coded color