Canonical naming works when design and code share one asset identity and every old name has an explicit migration or retirement disposition.
Separate identity from presentation
Name an icon for the concept it communicates, not the screen where someone first drew it or the pixel dimensions of one export. Store size, weight, direction, state, and theme as structured variants when they actually change the asset. This keeps a search icon recognizable across components while preventing unrelated glyphs from inheriting the same ambiguous filename.
Begin with an inventory of design names, repository names, component imports, and rendered meanings. Mark exact matches, aliases, collisions, missing variants, and assets whose semantics are unclear. Singapore's government design-system account describes the cost of design and code speaking through manual interpretation; a shared map gives both sides an inspectable contract instead.
Preserve aliases during migration
A rename should not silently break product code. Record the old identifier, canonical replacement, affected imports, owner, and removal condition. Generate aliases for a bounded transition when the runtime permits it, then make deprecated use visible in checks. Two old names may map to one canonical asset only when the buyer confirms that their meanings are truly interchangeable.
Keep manually modified or locally owned assets in an exception register. State whether each exception should be normalized, retained with a documented reason, replaced, or retired. This is also where licensing and attribution constraints belong. The manifest should never imply that placing a file in a shared repository grants permission to redistribute or alter it.
Review the map with actual component states
Names alone cannot prove that the right asset appears in the right context. Render the mapped icons in representative components and states, then ask the design owner to approve the baseline. Storybook's visual-testing documentation distinguishes rendered-pixel comparisons from markup snapshots, which matters when a filename change leaves markup valid but changes what a user sees.
Reality Contact, LLC prepares the canonical map and migration slice for Asset Release Path. The buyer makes semantic, brand, accessibility, and license decisions. The map records approved current use and known exceptions; it does not establish intellectual-property ownership or guarantee that every unreviewed product surface uses the intended icon.
Where the service stops
Reality Contact, LLC installs an asset-delivery workflow but does not create a visual identity, determine intellectual-property ownership, expand licenses, certify accessibility, approve visual changes, or guarantee identical rendering in future tools and browsers. The buyer identifies the authoritative design state and licensed source, approves canonical names and supported variants, reviews visual baselines, resolves ambiguous assets, and makes the installed path the required route for future approved assets. This implementation service does not replace the buyer's design, accessibility, intellectual-property, licensing, security, or release review; the public form must not receive private or licensed materials. Passing generation and visual checks apply only to the named asset family, versions, fixtures, and environment, and the buyer approves every canonical name and visual baseline.
Sources: Singapore Government Design System account of design-to-code alignment; Storybook documentation for rendered visual comparisons.