From Style Reference to Brand Kit: Governing --sref as an Approved Design System

The --sref flag was a breakthrough for visual consistency in Midjourney. Point it at a reference image and MJ produces outputs in that visual style—same colour palette, similar textures, coherent lighting. For the first time, teams could generate batches of images that genuinely looked like they belonged together.

But the flag solved one problem and created another. Teams quickly accumulated dozens or hundreds of style codes with no system for tracking which is which, who approved them, or which version of the brand they represent. The style reference has become the new “that folder of PSDs nobody can find.”

This guide walks through how to turn a scattered collection of --sref codes into a governed style reference library—with naming, versioning, approval workflows, and access control that actually scale.

What --sref Actually Does (And Doesn't Do)

The --sref flag accepts either a reference image URL or a previously saved style code. Midjourney extracts visual features from the reference—colour palette, texture, composition tendencies, lighting characteristics—and applies them to the new generation. The result is not a copy of the reference image, but a new image inflected by its visual DNA.

What --sref does not do:

• Guarantee pixel-level consistency — Two images with the same --sref will share an aesthetic, not identical rendering
• Maintain brand guidelines — A style code captures a visual mood, not a brand standards document with approved hex codes and typography rules
• Track usage — Midjourney does not record which team members use which styles, or when
• Version-control evolution — If you tweak a style reference, the old version is simply gone unless you saved it separately

Understanding these boundaries is essential. A style reference is a powerful creative tool, but it is not a brand management system. The governance layer has to come from you.

The Unmanaged Style Problem

Here is how it typically unfolds. A designer discovers a style reference that produces “our brand look.” They save the code, share it in Slack, and the team starts using it. Three months later, nobody remembers which of 47 saved codes is “the one.” The original designer has since created three variations. Two other team members have their own interpretations.

The consequences are predictable:

• Style drift — Different team members generate images with subtly different aesthetics, all claiming to use “the brand style”
• Client confusion — The client sees inconsistent outputs and asks “what happened to our look?”
• No audit trail — When someone asks which style was used for the Q3 campaign deck, nobody can answer with certainty
• Duplicated effort — Team members create new style references from scratch because they cannot find or trust existing ones
• Onboarding friction — New team members have no way to discover approved styles without asking around

This is not a Midjourney problem. It is an organisational problem that Midjourney's tooling does not solve. The platform gives you a saved styles list. It does not give you naming conventions, approval workflows, or versioning.

Building a Style Reference Library: Step by Step

The fix is not complicated, but it does require discipline. Here are the five steps to transform a scattered collection of style codes into something your team can actually rely on.

Step 1: Audit Your Existing Styles

Start by collecting every style code your team currently uses. Export from Midjourney's saved styles. Check Slack threads, Notion pages, and individual team members' accounts. The goal is a single list of every --sref code in active or recent use.

For each code, generate a test grid: run the same prompt with each --sref to produce four to six comparison outputs. A single output tells you nothing about a style's reliability. You need multiple samples to understand what it consistently produces versus what varies between runs.

Step 2: Catalogue with Structure

Create a structured catalogue entry for each style code. At minimum, each entry needs:

• Style code — The actual --sref value
• Preview grid — Four to six example outputs showing the range of what the style produces
• Descriptive name — Something human-readable like “Warm Editorial Photography” or “Flat 3D Product Renders”
• Intended use case — Editorial photography, social media graphics, product renders, watercolour illustration, etc.
• Approved date — When this style was reviewed and approved for use
• Owner — Who is responsible for maintaining and evolving this style

The format matters less than the consistency. A shared spreadsheet, a Notion database, or a DAM collection all work—as long as every style follows the same structure.

Step 3: Categorise by Approval Status

Not every style reference belongs in the same bucket. Group them into three tiers:

• Brand core — Always approved for any brand-related output. These are your primary visual identities, reviewed by creative leadership.
• Project-specific — Approved for a particular client, campaign, or project. Valid within scope, not for general use.
• Experimental — Interesting styles being explored, not approved for production deliverables. Useful for internal exploration and mood boards.

This three-tier system prevents the most common failure mode: a team member using an experimental style in client-facing work because they assumed it was approved.

Step 4: Version Your Styles

Styles evolve. A designer tweaks a reference image, adjusts the stylize weight, or blends two references to refine the aesthetic. When this happens, create a new version rather than overwriting the original.

A simple versioning scheme works:

• v1.0 — Initial approved style
• v1.1 — Minor refinement (adjusted parameters, same core aesthetic)
• v2.0 — Significant evolution (new reference image, different visual direction)

Each version entry should include a brief changelog: what changed, why, and who approved it. This sounds like overhead until you need to answer “why does this month's campaign look different from last month's?”

Step 5: Distribute and Make Discoverable

The best catalogue in the world is useless if nobody can find it. Make the approved style library accessible from where your team actually works:

• Shared Notion page with visual previews and quick-copy style codes
• CSV export for teams that prefer spreadsheets
• DAM collection with visual browse, tagging, and search for teams managing larger libraries
• Pinned Slack channel with the current approved styles list and update notifications

The point is that anyone on the team can find the right style without guessing, asking around, or creating their own version of something that already exists.

The Governance Layer

For solo designers or small teams, the five steps above may be sufficient. For agencies, brand teams, and studios managing multiple clients, you need a governance layer on top of the catalogue.

Approval Workflow

Define who decides which styles are approved for client work. This does not need to be complex—a single creative director reviewing and signing off on new styles before they enter the “brand core” or “project-specific” tiers is often enough. The key is that approval is explicit, not assumed.

Access Control

Can anyone on the team create new style references, or is that restricted to senior designers? There is no single right answer, but there should be a clear answer. Unrestricted creation leads to sprawl. Over-restriction stifles experimentation. A common middle ground: anyone can create experimental styles, but only designated team members can promote them to approved status.

Retirement and Archiving

When a style is no longer in active use, archive it—do not delete it. Previous deliverables may reference that style, and a client may ask for “more of what we did in Q2” six months later. Archived styles should be searchable but clearly marked as inactive, so nobody accidentally uses a retired aesthetic for new work.

Client Hand-Off

When a client asks “what style was used for my campaign?”—can you answer immediately? If your styles are governed, the answer is a thirty-second lookup. If they are not, it is a half-day archaeology project through Discord messages and Slack threads.

From Spreadsheet to System

A Notion page or CSV works well for teams managing ten or twenty styles. The visual previews are manually created, the versioning is handled by naming conventions, and distribution is a shared link. This is a perfectly reasonable starting point, and for many teams it is the right long-term solution.

The spreadsheet approach starts to break down around fifty styles, or when multiple clients are involved. Visual browse becomes cumbersome. Searching by aesthetic characteristics (rather than arbitrary names) becomes impossible. Version history gets lost in spreadsheet edits. And keeping previews up to date becomes a maintenance burden that nobody prioritises.

At that scale, a DAM system with visual browse, tagging, and search becomes a practical necessity—not because DAMs are inherently superior to spreadsheets, but because the specific operations you need (visual comparison, faceted search, access control, audit logging) are what DAMs are built for. Numonic is one option. There are others. The important thing is that the system supports visual discovery, not just text-based lookup.

The Style Reference Is Just the Beginning

Midjourney's --sref flag gave creative teams something genuinely new: reproducible aesthetics from a text-to-image tool. That is valuable. But a reproducible aesthetic is not a design system. The gap between “we have a style code” and “we have a governed visual identity” is where most teams lose consistency, waste time, and frustrate clients.

Filling that gap does not require expensive tooling or complex processes. It requires the same discipline that traditional design systems demand: naming things clearly, documenting decisions, versioning changes, and making approved assets discoverable. The tooling is secondary to the practice.

Start with the audit. Generate your test grids. Name your styles. Decide who approves them. The rest follows.