Automating image and video production multiplies output — and multiplies the ways brand rules break. This guide shows how marketing and brand teams keep every variant on brand with typed template variables, reusable font uploads and version-pinned templates in JsonCut.
Why brand consistency breaks first in automation
Brand consistency in automated production is not a design problem — it is an interface problem. Publish one approved layout as a version-pinned template, expose only typed variables for the values that legitimately change, upload fonts and assets as reusable media, and reject invalid input before anything renders. Do that, and a thousand variants stay on brand by construction.
When teams move from designing each image or video by hand to rendering them from data, the first casualty is usually the brand. A campaign variant ships with the wrong accent color. A bulk job picks up a fallback font. Someone "fixes" a layout locally, and suddenly two regions render different logos. None of this happens because people are careless; it happens because every additional hand-off between design, data and automation is another chance to drift.
The fix is not more review meetings. It is shrinking the surface that automation is allowed to touch. JsonCut's template model is built around that idea: a project becomes a template when it publishes typed variables, and variables are the only controlled replacement points a render request can address.
One approved source instead of many files
Brand governance starts with deciding who owns what. In JsonCut, that split is explicit:
| Responsibility | Owner | Where it lives |
|---|---|---|
| Layout, typography, logo placement, motion | Designer | The editable project in Studio |
| Which values may change per variant | Designer, as a contract | Published typed variables |
| The actual values per render | Marketing, data or an agent | Render requests and CSV/JSON rows |
| Output settings (format, quality) | Automation builder | Per render or batch |
Publishing a project as a template captures a specific project version. A later edit in Studio does not silently mutate the already published version, so the layout your automation renders tonight is the same approved layout it rendered last week. When the brand does change, you publish a new version on purpose — and production requests keep discovering the inputs for the exact version they were validated against.
That version pin is what makes "approved" mean something. Without it, every template is a moving target; with it, design review is a one-time event per version, not a per-render gamble.
Locked by default: variables define what may change
The core rule is simple: everything not exposed as a variable stays exactly as designed. Variables identify controlled replacement points in the visual source — nothing else in the file is addressable by a render request. The supported public variable types are deliberately small:
| Variable type | Typical brand use |
|---|---|
string | Headlines, product names, localised copy |
number (with optional min, max, step, unit) | Prices, discounts, font sizes within approved ranges |
boolean | Toggling badges, legal lines or seasonal elements |
color | Accent and background tokens from the brand palette |
image, video, audio | Product shots, footage and voiceover per variant |
sanitized html | Rich, pre-cleaned text blocks |
| Bounded flat string array | Short lists such as feature bullets (max 100 items, 1000 characters each) |
Deliberately excluded: arbitrary objects, enums and nested arrays. That constraint is a governance feature. If a value cannot be expressed as a typed, bounded input, it does not belong in an automated brand pipeline — it belongs back in the approved design.
A brand-flavoured input contract might look like this:
{
"variables": [
{ "id": "headline", "label": "Headline", "type": "string", "default": "Now available in Berlin" },
{ "id": "accent", "label": "Accent", "type": "color", "default": "#ff9418ff" },
{ "id": "product", "label": "Product image", "type": "image", "default": "jsoncut-media://media_default" },
{ "id": "showBadge", "label": "Show badge", "type": "boolean", "default": true }
]
}
Two details matter for brand teams. First, defaults: every variable can carry one, so an unattended job that supplies no value still renders the approved baseline. Second, numeric constraints: a number variable can declare finite min, max, a positive step and a unit, so "font size" can never silently become 4 or 400.
Brand tokens bind to real properties
Declared variables only matter if they bind to the design, and bindings are typed too. data-jc-bind-text accepts string or number, data-jc-bind-visible accepts a boolean, media bindings accept matching media types, and data-jc-bind-props maps a supported property to a compatible number, color or boolean variable.
For brand work, the bindable property groups are the interesting part:
| Property group | Bindable properties | Brand relevance |
|---|---|---|
| Typography | Font size, color, background, line height, letter spacing | Type scale and text colors stay inside approved ranges |
| Geometry | x, y, width, height, rotation, opacity | Reposition without redesign |
| Border | Width, color, radius | Consistent framing across variants |
| Filters | Blur, brightness, saturation, hue | Controlled look adjustments, not per-variant surprises |
| Vectors | Stroke, stroke width | Line weights that match the system |
The practical pattern is to bind color tokens from the published palette and numeric tokens with tight min/max ranges — for example, a headingSize number variable constrained to the two sizes your type scale allows. Automation can still adapt content, but only inside the envelope the brand team defined.
Fonts and assets: upload once, reference everywhere
Off-brand fonts usually sneak in through asset handling. In JsonCut, fonts are first-class media: POST /api/v2/media accepts reusable images, video, audio and fonts, and returns a stable reference such as jsoncut-media://media_01J... that you persist in the project source. Upload the licensed brand typeface once, reference it everywhere, and render requests never carry font files at all.
Media retention encodes how durable an asset should be:
| Retention | Use |
|---|---|
temporary | One-shot inline work that may expire |
project | Durable media owned by one project |
template | Durable media a template requires |
persistent | Workspace media not yet attached to a project |
Two operational rules keep this safe. Preview URLs are short-lived and must not be stored in a template — only the jsoncut-media:// reference is durable. And deletion only succeeds for unused media: as long as a project or template still references an asset, the API keeps it resolvable for preview and rendering, so a cleanup script cannot quietly break the brand typeface behind a live template.
MCP agents get the same guarantee without touching storage credentials: they request one-use upload tickets instead.
Keeping a thousand variants on brand
Bulk rendering is where governance pays off. JSON and CSV batches are capped at 500 rows, every row is validated against the pinned template version before queueing, and invalid rows are reported with their index and a safe error — without preventing valid rows from rendering. Combined with an Idempotency-Key per render, retries re-deliver the same artifact instead of creating near-duplicate brand clutter.
| Drift risk | Governance control |
|---|---|
| Off-palette colors | color variables with approved defaults |
| Rogue font sizes | number constraints (min, max, step, unit) |
| Layout edits leaking into production | Version-pinned published templates |
| Ad-hoc asset uploads | Reusable media with explicit retention |
| Broken rows blocking or polluting output | Row validation before queueing |
| Retry duplicates | Idempotency keys on render creation |
The result is a checklist-sized review: approve the design, approve the variable contract, approve the media set — then let data flow. The examples gallery shows what repeatable, template-driven variants look like in practice.
FAQ
Do I need a dedicated "brand kit" feature to automate on brand?
No. The governance comes from the template contract itself: one approved layout, typed variables for what may change, and durable font and asset uploads behind stable references. Anything the contract does not expose cannot drift.
How do I stop automation from using off-brand colors?
Expose color as a color variable with the approved default, and never bind raw colors from untrusted data. Rows that fail validation against the pinned template version are rejected before rendering.
What happens when the brand guidelines change?
Update the project in Studio and publish a new template version. Existing production requests keep the version they were validated against, so you migrate deliberately instead of waking up to a silently different design.
Sources
https://jsoncut.com/docs/create/variables-and-templates/ (abgerufen 2026-10-14) https://jsoncut.com/docs/templates/ (abgerufen 2026-10-14) https://jsoncut.com/docs/media/ (abgerufen 2026-10-14) https://jsoncut.com/docs/ (abgerufen 2026-10-14)