How to version brand guidelines for AI workflows

TL;DR

Save a distinct brand version when guidance changes, and record the version used by each task. Preserve the task's guidance and files where you need a lasting history. Inspect proposed edits before applying them, and write a short note explaining the change. Keep temporary campaign instructions with the task. Reverse a mistake through a new recorded change.

Keep today’s guidance separate from yesterday’s work

When an old launch image uses a retired colour, you need to know what the agent received. It may have followed the guidance that was current at the time. It may have used an outdated copy. Or it may have ignored the right rule.

A file named latest-brand.pdf cannot distinguish those cases. Versioning becomes useful when three records can be connected:

The current brand can move forward while completed work keeps its original record. Changing the old record to match today's rules would hide how the work was made.

Save a coherent version of the brand

Keep the guidance, identity values and asset references together. A voice rule can name a product, a layout rule can refer to a colour, and logo guidance can point to a particular file. Recording only the voice document's version leaves the rest unexplained.

The useful principle to borrow from Semantic Versioning is immutability: changes to a released package get a new version. For brand work, use a distinct reference for each saved set of guidance and preserve its contents once work has used it.

You do not need to borrow software's major, minor and patch numbering. A sequence, date or immutable identifier can identify the version. Add a readable note explaining whether the change corrects an existing rule, adds something new or retires something earlier work used.

A version reference is also different from a download URL. A temporary link can expire while the version remains the same. Keep the identifier and preserve the files themselves when your archive needs to outlast the service or links supplying them.

Attach the version to the task when it runs

Rainbrand maintains brand guidance and assets that connected agents and products can use. Its Brand Skill is a complete, versioned snapshot of that context. A Brief selects guidance and files from the brand for a particular task.

You can see a saved task reference in our example for Eager, a juice brand. Claude used Rainbrand context to make packaging and launch material for a blackcurrant-flavour concept.

The saved Brief includes:

{
  "brief_id": "38483b58-5b8c-47cf-b582-cee4cabc240f",
  "status": "completed",
  "skill_id": "9e1d3f71-f0b5-5cd3-a8a1-f2e28ec02a0f"
}

Those are fields from the historical example. The page also preserves the guidance and selected files so a reader can compare what Claude received with the work it made. This connects the task to a saved brand version.

For a new integration, use the current Brief response. Its REST fields are data.id for the Brief and data.skillId for the brand version used. Store both with the final file, along with the task and relevant campaign instructions.

A practical record might contain:

Output file or content record:
Task:
Brand ID:
Brief ID:
Brand version used:
Campaign instructions supplied:
Guidance and selected files, or archive location:
Producing tool or model:
Review findings and revisions:

This is a suggested record for your workflow, not an API response schema.

Save the record as the work happens. Reconstructing it later from a brand name and a timestamp can leave you guessing which context reached the producing tool. Recording a version helps diagnose inputs; it does not promise an identical result if you rerun a generative model.

Prepare and inspect the next change

Once task records point to stable versions, a new edit can change future inputs without erasing the old ones.

Rainbrand's Brand Edit workflow prepares a proposal before changing active guidance. Inspect the proposed guidance, identity and asset changes, refine them if needed, then apply or discard the edit. An authorised agent or API client can carry out these steps.

The changed-file reference provides the base and proposed contents for inspection. Check those changes against the request. A proposal can be successfully prepared and still need adjustment.

Each edit is based on a particular version. If another edit changes the active brand first, applying the older proposal returns a conflict. Prepare a new edit from the current version. This prevents an older proposal from overwriting intervening changes.

The Brand Library, the collection of assets available for brand work, also has direct additions and removals outside this edit sequence. Record those asset decisions when they affect your history. Removing a Library file stops future Briefs and brand versions from selecting it while published Brand Skills keep working.

Explain what the new version changes

A version identifier tells your software that the inputs differ. A short change note tells colleagues what to do about it.

Keep a Changelog recommends dated, readable entries with the latest version first and related changes grouped. For a brand, include the reason and which work needs attention.

Fictional Acme makes design software for product designers. This illustrative change note records its rename from Atlas to Atlas Pro alongside a palette change:

Version 14 — 2 November 2026
Changed: Atlas is now Atlas Pro. Yellow changes from #FFD600 to #F2C94C.
Reason: revised product naming and launch identity.
Applies to: new launch material and current launch drafts.
Follow-up: refresh task context and check scheduled launch assets.
Previous version: 13

Replace the illustrative version numbers with your actual saved version references.

Keep current guidance readable on its own. An agent should receive the current product name and colour directly, rather than have to read the entire changelog to work out which rule wins.

After applying a Rainbrand edit, request a fresh Brief for affected tasks. A completed Brief stays tied to the version it used. The cross-tool update guide covers replacing exports, saved instructions and other copies.

Use the record to diagnose a wrong output

Compare the task's saved guidance with the output before deciding what to change.

If the task used an older version, decide whether that was intentional. A historical campaign may correctly use the brand from its release date; a new campaign usually needs current guidance. For stale work, retrieve current context and find the copy or reuse decision that supplied the old version.

If the task used the intended version but its rule was wrong, correct the brand. Use the version references to find other tasks that may have inherited the same problem.

If the rule was right, inspect how it reached the producing tool. The agent may have omitted a font, ignored a layout rule or passed an old logo. Correct the work or the handoff. Editing sound brand guidance to compensate would spread a workaround to future tasks.

Keep Review findings with the work where you use them. Review checks work against the brand and supplies findings; the tools creating the work make the corrections. A check performed after a brand change should also record which guidance it used, rather than silently replace the original task history.

Reverse a mistake without erasing its history

Restore the desired rule through a new change. Preserve the version that introduced the problem so work made from it remains explainable. Git's revert operation follows the same principle by recording a new commit that reverses earlier changes.

With Rainbrand, prepare a new edit describing what should be restored. Inspect and apply that proposal, then retrieve fresh context for affected tasks. This uses the normal edit workflow to restore the desired rules.

Record why the reversal was needed and which work needs revising. If you need an independent archive, export the Brand Skill and keep the downloaded files. Store task-specific guidance and selected assets too.

The Brief contract allows its version reference to become null if the saved version is deleted. A service reference alone is therefore insufficient for a permanent archive.

Keep temporary instructions with the work

A campaign headline, seasonal offer or proposed packaging colour can change while the underlying brand stays the same. Keep those instructions with the task unless you intend to make them available as lasting brand guidance.

For example, a fictional Acme summer campaign might use coral #FF6F61 on campaign material from 1 June to 31 August 2027. Record those dates and the usage restriction with the campaign. Include them when requesting the task's Brief, rather than making coral a permanent palette colour by accident.

The saved Eager Brief demonstrates this separation: it identifies the hypothetical flavour's packaging and copy directions as task-supplied concepts, distinct from source-backed brand guidance.

For ongoing work, the active brand reference tells an integration what is current; each task record tells it what was used. The runtime retrieval guide explains how to compare those versions before reuse.

Pick one recent output and check whether its task, version and supplied files can be found together. Fill that gap before adding a more elaborate numbering scheme.