Illustration and imagery

A tell is not a rendering flaw. It is the visible shape of a decision nobody made, which means every one of them has a fix that lives in the brief:

• Default lighting and lens. Skipped decision: where is the light coming from, and what is the camera. Fix: state it. "Single hard light from the upper left, long lens, no bloom, no lens flare." Boring, specific, unmistakably yours after four assets.
• Symmetrical hero composition. Skipped decision: what is the crop and where is the subject in frame. Fix: state a crop rule. "Subject in the left third, generous negative space on the right for copy." Now the asset has a job in a layout.
• Meaningless decoration. Skipped decision: what does this picture claim. Fix: forbid decoration outright. Every element in the frame must correspond to something real in the product.
• Unrelated palette. Skipped decision: is this asset in the product's colour world. Fix: name the palette as tokens, not vibes - the plum accent family and neutrals from b6, nothing else.
• Generic subjects. Skipped decision: who is this and what are they doing. Fix: write subject rules. For Cadence: real meeting artefacts, laptops with plausible interfaces, hands mid-note, nobody smiling at the camera.

The same move as everywhere else in this track: direction plus a stated standard. Direction gives the tool something the average of the internet does not have. The standard is what you review against, so "it feels off" becomes a specific line someone can fix.

Both of these produce a competent image. Only one produces an asset that belongs in Cadence.

The exclusion list is the half people leave out, and it is the half that removes the tells. Write it once for your product and reuse it in every image brief you send for the next year.

Someone will ask, usually a stakeholder holding a printed brand book. The documentation answers for you, and it is worth quoting rather than paraphrasing:

• --sref transfers style, not content. The docs are explicit that it "doesn't copy objects or people, just the overall style". So it can make an asset feel like your world. It cannot reproduce your mascot.
• You cannot create a style code from an uploaded image. Style codes come from Midjourney's own library. If your plan was "upload our brand assets and get a permanent brand code", that plan does not exist.
• References are inspiration. The documentation says references are used "as inspiration ... not to copy them exactly". Family resemblance across a set, yes. Pixel fidelity to an existing asset, no.
• Omni Reference is the strongest carry-over and the most expensive. One image, --ow 1-1000 with a recommendation to stay below 400, V7 and later only, and 2x GPU time. Budget for it deliberately rather than discovering it in your usage graph.
• Do not mix moodboards with style weights. A moodboard (--p mID) cannot be combined with --sv or --sw. If your prompt has both, something is being ignored.

None of this makes the tool less useful. It makes it a different tool than the one people imagine: a consistency engine for a set you are art-directing, not a brand-asset reproducer.

Product imagery is almost never one image. It is an empty state, an error state, an onboarding sequence, a marketing hero and three blog thumbnails, and they have to look related without looking repeated.

• Fix the style first, once. One --sref value and one --sw for the whole set. Write both into your standard. Changing either mid-set is why sets drift.
• Vary only the subject. Same lighting, same crop family, same palette, different object. Variation belongs in what the asset is about, not in how it is rendered.
• Use --stylize as a dial, not a rescue. Range 0-1000. Higher means more of the tool's aesthetic and less of your prompt, which is the opposite of what you want when direction is the point.
• Keep a record. Prompt, parameters, version, and the reference you used, stored with the asset. When someone asks for "one more like that" in four months, this file is the difference between five minutes and an afternoon.

1. "Commercially safe" is a design goal, and it is model-specific. The framing covers Adobe's own Firefly model. For the partner models hosted alongside it - and there are more than thirty - Adobe states it cannot verify commercial safety and directs you to the partner's terms. If your team uses the model picker casually, your asset library now has two legal regimes in it and no label distinguishing them.

2. Indemnification is something you buy, not something you get. It is a purchased entitlement, scoped to published lists of eligible features, surfaces and export events. Partner-model output is excluded, and so is anything labelled beta or trial. The practical question is never "are we indemnified" - it is "is this asset, made with that model, on that surface, inside the scope we bought". If you cannot answer that, you do not have coverage, you have a hope.

3. Provenance is a receipt, not a verdict. Content Credentials are applied automatically where 100% of the pixels are Firefly-generated, and on the Firefly web app and APIs; elsewhere they are opt-in, which means someone has to turn them on. C2PA's current spec version is 2.4, its Conformance Program launched mid-2025, and its Interim Trust List froze on 2026-01-01 - no new entries. What a credential proves is a signed history of how an asset was made and edited. What it does not prove: that an unsigned asset is fake, or that a signed asset is truthful. Both mistakes are common and both are expensive in a public argument.

One more, specific to Midjourney: commercial terms are the same across tiers, except that companies grossing over $1M USD per year must be on Pro or Mega. That is a procurement fact more than a design fact, and it is the kind of thing that surfaces the week before a campaign.

Deeper legal treatment - registrability of AI-assisted work, vendor indemnity scope, synthetic-content transparency duties, and where the primary sources were unreachable - lives in leader session a4. This session covers what you need to make an asset decision at your desk.

A three-line record next to every generated asset removes almost all of the risk that comes from not knowing:

• Tool, model and version. Not "Firefly" - which Firefly model, or which partner model. Not "Midjourney" - which version, since parameter behaviour and terms differ.
• Prompt and parameters, verbatim. Including reference URLs or codes, weights, and the version flag. This is also how you regenerate a match later.
• Rights status as a sentence you would say to counsel. "Adobe Firefly Image model, standard export surface, covered by our purchased entitlement" is a sentence. "Should be fine" is not.

Keep it with the asset, not in someone's notebook. The moment this matters is the moment the person who made it is on leave.