Firefly Brand Guardrails

Firefly Brand Guardrails

The compliance layer for production generative pipelines. Base Firefly is commercially-safe at the model level — IP-safe training data, output filtering for harmful content. But "commercially safe" is not the same as "on brand." Brand guardrails are the customer-specific layer that sits between Firefly and the customer's published assets.

This skill encodes the pattern that converts a generative pipeline from "marketing previews the output" to "every shipped asset has a documented approval lineage that survives legal audit."

When to Use This Skill

Use this skill when:

• The customer is in a regulated industry (financial services, pharma, automotive, public sector, healthcare)
• Marketing legal will need to approve assets before they ship
• The brand has explicit do/don't rules (no competitor products visible, no specific colors, no minors, no specific weather/locations)
• The user mentions "brand safety", "review queue", "approval workflow", "compliance hold", "legal sign-off"
• Output will be published externally (ad campaigns, social, broadcast) — never just "internal preview"
• The customer has had a brand-incident in the past and wants belt-and-suspenders

Do NOT use this skill when:

• The output is for internal ideation or storyboards only — base Firefly is fine
• The customer has no brand-review process and explicitly does not want one — don't impose process they won't follow

The Four-Layer Guardrail Stack

Brand guardrails are not a single feature. They are four layers, each filtering at a different stage:

Layer 1: Model-level lock-in        (custom models, deny base model entirely)
            ↓
Layer 2: Prompt-side filtering      (deny-list, prompt rewriting, banned terms)
            ↓
Layer 3: Output-side filtering      (visual classifiers, content tags, moderation API)
            ↓
Layer 4: Human review queue         (sampling for spot-check, blocking for high-risk)

A regulated-industry pipeline runs all four. A brand-sensitive but not regulated pipeline often runs 1, 2, and 4, skipping 3 for cost reasons.

Step 1 — Layer 1: Model-Level Lock-In

The strongest guardrail is restricting which model can run at all. For brand-critical workflows, the pipeline does not call the base Firefly model — it only calls custom models trained on approved brand assets.

Implementation sketch:

const ALLOWED_MODELS = new Set([
  'brand-light-icon-style-v3',
  'brand-dark-icon-style-v3',
  'brand-product-subject-v2',
]);

function validateGenerationRequest(req) {
  if (req.intent === 'published' && !ALLOWED_MODELS.has(req.customModelId)) {
    throw new GuardrailViolation(
      `Published generations must use an approved custom model. Got: ${req.customModelId ?? 'none'}`
    );
  }
  if (req.intent === 'published') {
    req.headers['x-model-version'] = 'image3_custom'; // required for custom models
  }
}

See firefly-custom-models for the full custom-model lifecycle.

Step 2 — Layer 2: Prompt-Side Filtering

Two patterns: deny-list and rewriting.

Deny-list

A list of banned terms (competitor names, prohibited categories, brand-conflict phrases). Pipeline rejects prompts containing any term on the list.

Match deny-list terms case-insensitively, with simple stem rules. Aggressive regex matches over-filter — be specific. Maintain the list in version control, not in code, so legal can update without a deploy.

Prompt rewriting

For terms that should be substituted rather than rejected, run a rewriting pass:

Rewriting is a Lambda that runs before the Firefly call. Keep it deterministic — same input always produces the same output. Log both the original and rewritten prompt for audit.

Step 3 — Layer 3: Output-Side Filtering

Firefly's built-in content filtering blocks the obvious (CSAM, gore, explicit content). Brand filtering is the layer on top.

Three options, in order of cost:

Tag-only pattern

For every generated asset, attach metadata at persistence time:

{
  "modelId": "brand-light-icon-style-v3",
  "promptHash": "sha256:...",
  "outputDimensions": "1920x1080",
  "generatedAt": "2026-05-19T14:21:08Z",
  "complianceTags": {
    "containsPerson": null,
    "containsCompetitorBranding": null,
    "containsRegulatedSubject": null
  },
  "humanReview": "pending"
}

complianceTags starts as null. A reviewer (or classifier) fills them in. The pipeline holds publication until they are non-null and pass policy.

Classifier pattern

For volume workloads, run a classifier between Firefly success and S3 persistence:

Firefly success → download output → classifier → tag results → persist + queue for review

Use a hosted classifier (AWS Rekognition, GCP Vision AI, Azure Computer Vision) for off-the-shelf coverage. Custom classifiers (trained on Sagemaker / Vertex AI / Azure ML) for brand-specific concepts (e.g., "is the brand logo present and correctly placed").

Step 4 — Layer 4: Human Review Queue

The terminal guardrail. Even with the previous three layers, some percentage of assets land in a review queue before they can ship.

Three review modes

A typical FDE engagement starts at 100%, tightens to sampling once the team trusts the pipeline (usually 4-8 weeks in), then drops to flagged-only after a quarter of clean operation.

Queue architecture

Pipeline output (status=succeeded, humanReview=pending)
       ↓
SNS topic: needs-review
       ↓
Review UI (custom-built or Workfront / Asana / Jira)
       ↓
Reviewer marks: approved | rejected | escalate
       ↓
       ├── approved  → S3 tag humanReview=approved; release for publication
       ├── rejected  → S3 tag humanReview=rejected; move to /rejected/ prefix; notify originator
       └── escalate  → second-level reviewer (legal / brand director); notification + SLA timer

Rejection-reason taxonomy

Reviewers should not free-text reject. Maintain a fixed taxonomy:

The taxonomy feeds back into the deny-list and the custom model retraining cycle. A workflow without this feedback loop will repeat the same rejections forever.

Step 5 — Wiring into the Batch Pipeline

In the firefly-batch-pipeline Step Functions state machine, the review gate is a state after persistence:

... → PersistAssets → TagForReview → WaitForHumanReview → PublishOrReject

WaitForHumanReview uses waitForTaskToken — the state pauses until the review UI calls SendTaskSuccess (or SendTaskFailure if rejected). Wait timeout = customer-agreed SLA + buffer. Past the timeout, escalate.

Validate

The guardrail stack is production-ready when:

1. The pipeline refuses to submit intent=published generations without an approved customModelId
2. The deny-list lives in version control and legal can update it without an engineering deploy
3. Every output asset carries complianceTags and humanReview metadata
4. A review queue exists with a documented reviewer SLA and an alarm if p95 wait time exceeds it
5. Rejection reasons follow a fixed taxonomy that feeds back into deny-lists and retraining
6. Audit trail per asset includes: prompt, model, seed, reviewer, decision, timestamp, reason code

Troubleshooting & Edge Cases

• Reviewers approve too quickly without looking: Audit shows >100 approvals/hour per reviewer. Cap throughput; require at least 30 seconds per asset; introduce calibration checks (planted rejections to verify reviewers are looking).
• High rejection rate (>20%): The pipeline is producing too much off-brand output. Trace back: is the custom model stale? Is the deny-list catching enough? Retrain or expand filtering.
• Legal flags a category mid-campaign: Add the category to the deny-list immediately; retroactively scan in-flight and queued jobs; pull published assets if needed.
• Reviewer disagrees with classifier: Track the disagreement rate. If the classifier is wrong >10% of the time, retrain. If the reviewer is inconsistent with peers, calibration session.
• Custom model output drifts after Adobe base update: The base model under the custom layer changed. Retrain (see firefly-custom-models §7).
• Customer wants to bypass review for "small" campaigns: Bypass is fine for internal-only intent. For any intent=published, no bypass — that is the whole point of the gate.
• Asset approved but later flagged externally (e.g., social media incident): Recall workflow pulls the asset, marks humanReview=recalled, alerts brand team, and logs the case for taxonomy expansion.

Chaining with Other Skills

• firefly-custom-models — Layer 1 lock-in depends on a healthy custom-model library
• firefly-batch-pipeline — Where the review gate plugs into the production state machine
• firefly-cost-optimization — Rejection rate is a primary cost-burn driver
• firefly-services-storage-refs — Where the compliance metadata gets attached
• firefly-services-troubleshoot — When 422s spike, the deny-list or model needs attention

References

• Firefly API — Commercially safe generative AI
• Firefly Custom Models Overview
• AWS Rekognition — Content moderation
• AWS Step Functions — Wait for Callback with Task Token