Versions and projects
What applied stays as it was.
Brand guidelines change over the years, but a reprint from 2022 should look like 2022. That is why every published version in nexbrand is frozen and carries the date it applies from, and a project stays on the version it was made with.
First a draft, then a version
Nothing in a published version can be changed. If you want to change something, you create a new version, and it starts as a draft.
- New version
You give it a name, such as “2027” or “Relaunch”, and choose what it starts with: an existing version or nothing. A client can have up to 30 drafts at a time.
- Edit draft
In the editor you change colours, fonts, logos, sizes, rules, examples and the dark mode. The checks run on the right, and if you try to close the tab with unsaved changes, you are asked.
- Publish
With “Publish now” the draft gets its name and the day it applies from. From then on it is a version and never changes again. If you record an old identity afterwards, use the date it applied from back then.
Pavo saysA date in the future works too. Then the new version applies in the app, in the code and through the API only from that day, and until then the old one stays current.
The time line
At the top of every client page all versions stand side by side, with their colours as a strip and the day they apply from. The one that applies is marked “current”, a coming one “upcoming”, drafts are dashed.
- As of: A date shows the version that applied on that day. If there was none yet, nexbrand tells you when the first one applies from.
- 3 years ago: one click, as soon as versions are that old.
- Origin: Every draft says where it comes from: by hand, collected, over MCP or chosen by the client.
Comparing two versions
The tab History lists every version with its origin, date, who published it and the note. Below it you pick two, from and to, and see what changed: every colour, font, logo, size, rule, example and the dark mode, field by field.
Colours come with their distance ΔE by CIEDE2000, so you see at a glance whether a red was only sharpened or has become another red. At the end the comparison shows which hints of the checks are new and which were fixed.
On a draft, “Compare” leads straight to the history, to compare it with the current version. Over MCP the tool compare_versions returns the same difference.
Projects with their own colours
A website, an autumn flyer, a trade fair stand: a project belongs to the client, builds on one of its versions and may have parts of its own.
A new project takes over everything at first. In the project's draft you then decide per part what applies:
| Setting | Meaning |
|---|---|
| as the client | The part comes unchanged from the client. It is changed there. |
| as the client, plus its own | The client's part plus the project's own. The same name replaces; rules are only added. |
| its own | Only in the project. The client's part plays no role. |
This works for colours, fonts, logos, sizes, rules, examples and the dark mode. Each colour of the project says whether it is inherited, replaced in the project or project only. In the draft, inheriting works live; publishing freezes it, and the project gets versions of its own with a time line of its own.
Moving a project, on purpose
When the client publishes a new version, nothing changes in the project. It only shows a hint that a newer one exists, and that inherited parts look as in the older version until somebody moves the project.
“Move to 2026” first shows what would change. Then you pick “Leave on 2022” or “Draft on 2026”: that creates a new draft of the project, which you check and publish like any other.
Pavo saysThat way a reprint looks as it did then, and no website gets a different blue overnight just because the agency sharpened something at the client.