What a brand holds
A brand in this module is not a folder of logos. It is nine sections in three groups, and the grouping tells you what each is for.
Brand identity — what the brand is
Section titled “Brand identity — what the brand is”Colors, Typography, Logos, Design Tokens, and Brand Guidelines.
These are the definitions other modules draw on. A change here changes what everything else produces, which is why this group is where controls and snapshots point.
The five are not equal in kind. Colours, type, and logos are the raw material. Tokens are those values given names code can use. Guidelines are the rules for combining them, which no amount of raw material can express.
Standalone — recorded, not used
Section titled “Standalone — recorded, not used”Custom Branding sits on its own, and the panel says why: these elements are for reference only and are not integrated with other platform modules.
It is separated so that nobody mistakes a signage specification for something the platform will apply. Recording the office sign spec next to the hex value it uses is useful; expecting a form to pick it up is not.
Governance and history — how the brand is kept
Section titled “Governance and history — how the brand is kept”Version History, Brand Controls, and the Activity Log.
None of these define the brand. They protect it: a restorable state, rules that prevent misuse, and a record of who changed what.
Why tokens are separate from colours
Section titled “Why tokens are separate from colours”A colour and a token look like the same thing stored twice, and they are not.
A colour is a value with a name people use — Navy, #0B1F33. A token is a value with a name code uses, and the two are named on different principles. People name colours for what they look like; code should name them for what they do, so --color-primary survives a rebrand that --color-navy does not.
Keeping them separate is what lets the brand change its navy to purple without every stylesheet lying.
Why guidelines are separate from controls
Section titled “Why guidelines are separate from controls”A guideline explains and a control enforces, and most rules need both.
A control that blocks a font without explaining which font to use instead produces a support request. A guideline that explains without enforcing produces a polite violation. The pairing is: write the reasoning in a guideline, then enforce the part that matters with a control.
Related
Section titled “Related”Governance goes deeper on controls and locks. Feature list lists everything each section holds.