---
name: supporting-imagery
description: >-
  Create on-brand AssemblyAI supporting imagery — visuals for decks, web
  sections, social, and ads — in one of seven defined styles (UI & Code, Demos,
  Maps, Pure Abstract, Literal × Abstract, Graphs, Diagrams). Use whenever the
  user wants to design, generate, mock up, or spec a marketing visual, hero
  image, section graphic, chart, diagram, or background for AssemblyAI. Routes
  the request to the right style, applies the design system, and produces the
  asset to that style's spec.
---

# Supporting Imagery

This skill produces **on-brand AssemblyAI supporting imagery** — the visuals that sit alongside copy in decks, web sections, social posts, and ads. It is built on the AssemblyAI Brand Design System v1.1 and a library of **seven style modules**. Your job: **pick the right style for the request, then build the asset to that style's spec.**

## How to use this skill

1. **Read the request and the data/content to be shown.** What is the visual *for* — proving a number, showing the product, setting mood, explaining a system, showing reach?
2. **Select a style** using the decision guide below. If a request could fit more than one style, **infer the best fit, state which style you chose and a one-line rationale, and proceed** (the user can redirect). Don't stall on ambiguity.
3. **Find that style's section** below and follow it exactly — each section is the source of truth for its color, type, composition, level of detail, do/don'ts, export specs, and how it composes on a slide/section.
4. **Apply the shared rules** (below) that hold across every style.
5. **Produce the asset** to spec, and note the style + key choices so the result is reviewable.

## Reference: the design system

The brand source of truth is `public/brand-design-system/assemblyai-brand-design-system.md` (Brand Design System v1.1) in the `assemblyai-website` repo — tokens, palette, type scale, primitives, components, and brand rules. Every style section is built on it. When a detail isn't in a style section, defer to the design system; if it's in neither, ask.

**For deck slides**, also follow `../assemblyai-slides-guidelines.md` (sibling of this folder) for slide brand rules — layouts, typography, color, chrome, and dos/don'ts. When a style section says "on a deck slide…", apply it together with those guidelines: this skill governs the *supporting visual*, the slides guidelines govern the *slide it sits on*.

---

## Style selection guide

Match the **job of the visual** to a style.

| If the visual needs to… | Use |
|--------------------------|-----|
| **Show the product working** — a transcript, code, terminal, API call, chat | **UI & Code** |
| **Demonstrate a capability/output** — a clean, idealized product mock-up (transcript, editor, captions, entity highlights, a simple API flow) rebuilt from tokens | **Demos** |
| **Show global reach / a connected network** of places or entities | **Maps** |
| **Set mood / brand atmosphere** with texture and geometry, no literal subject | **Pure Abstract** |
| **Pair a real artifact with brand atmosphere** — a clean UI/chart card on a grainy abstract ground | **Literal × Abstract** |
| **Prove a claim with real numbers** — benchmarks, comparisons, price-performance | **Graphs** |
| **Explain how a system works** — input → engine → outputs flow, architecture | **Diagrams** *(draft, single-reference)* |

### Quick disambiguation

- **Real numbers to compare?** → **Graphs**. (Don't fake data with Pure Abstract's "data-like" texture.)
- **Real product UI/code/transcript?** → **UI & Code** (literal/raw) or **Demos** (idealized, token-rebuilt). Demos is the cleaner, brand-controlled version.
- **A flow/relationship between parts, no quantities?** → **Diagrams**.
- **A network of peers across geography?** → **Maps**. (A directional input→output flow is **Diagrams**, not Maps.)
- **Just a background / mood, nothing literal?** → **Pure Abstract**.
- **One asset that's both a real thing *and* a brand ground?** → **Literal × Abstract** (only when both layers earn their place).

When two genuinely fit, prefer the **more literal / more informative** style if the request is making a claim or showing something concrete, and the **more atmospheric** style if it's setting tone. State your pick and move on.

---

## Shared rules (all styles)

These hold across every style section; the per-style sections add to and specialize them.

**Color & tokens**
- **Cobolt `#3923c7` is the brand's only core accent.** Most styles lead with it. Grounds are the warm neutral scale: page `#fdfcf8`, tint `#f5f3eb`, card `#ffffff`, dark anchor `#1d1b16`.
- **Two styles carry a sanctioned, style-scoped green** (`#01762f` text/icons, `#cce4d5` fills, `#99c8ac` highlights): **UI & Code** and **Demos**. It is *not* a core token — use it only where those sections say to.  (Also the success check tint reused in **Diagrams**.)
- **Graphs** add a style-scoped multi-series chart palette (Cobolt scale + warm neutrals + Blush, grouped-charts only). **Pure Abstract** adds a sanctioned emerald-green and a rare Blush/warm thematic spot.
- These green/Blush extensions diverge from the design system's "Cobolt-only, Blush-for-errors" rule and are **flagged in their sections** for promotion to official tokens. Don't introduce any *other* off-system hue.

**Typography**
- Three faces, per the design system: **Oceanic Text** (serif headings), **UN 11ST** (body/UI/labels), **Modern Gothic Mono** (eyebrows, CTAs, code, and in-artifact technical content for UI & Code / Demos).
- **Most imagery carries little or no baked-in type** — headlines, eyebrows, and body copy are layered by the slide/web template, not the asset. Exceptions: **Graphs** (a full type-rich section) and the short labels inside Demos / UI & Code / Maps / Diagrams. Pure Abstract carries **no** type.

**Composition & export**
- Build on the design-system grid, spacing scale, and `Pill`/icon primitives (Material Symbols). Restrained motion/flat rendering — no 3D or drop shadows unless a section says otherwise.
- Default export: **PNG, sRGB, filled background** (warm or dark), authored large and exported @2x for crisp text/grain. Use **transparent** only when a section allows it and the asset drops onto a matching ground. Each section gives the proven aspect ratios.
- **One supporting visual per slide/section**, and don't stack two imagery styles in one frame (the one intentional fusion is **Literal × Abstract**).

**Accuracy & honesty**
- Any real content must be correct: **Graphs** require real, sourced data and an honest encoding (zero baselines, real axes — see its §6 checklist); **Demos / UI & Code** require valid AssemblyAI SDK code and plausible content. Never fabricate data or APIs.

---

---

# Style: UI & Code

> Derived from seven approved on-brand examples in the "Website refresh" Figma file (nodes `3039-12082`, `3039-12083`, `3041-27241`, `3041-27277`, `3041-27410`, `3041-27466`, `3041-27477`).

## 1. Intent

**UI & Code is the "show the product working" style.** It renders the thing AssemblyAI actually produces — a transcript, a chat between an agent and a caller, a code snippet that calls the API, a terminal printout, a captioned player, a request/response flow — as a clean, monospaced, windowed artifact. It is literal, technical, and legible. The viewer should be able to *read* it and understand exactly what the product does.

**Use UI & Code when the point is mechanism or proof:**
- Demonstrating an API call, SDK usage, or config (`aai.TranscriptionConfig(...)`).
- Showing a real conversation: voice-agent turns, interruptions, redaction, compliance prompts.
- Visualizing what a feature outputs: word-level timestamps, entity/PII highlighting, captions, translation.
- Diagramming a pipeline or architecture at a conceptual level (Audio in → Voice Agent API → Audio out).

**Reach for a different style when the goal is not mechanism:**
- Pure emotional/brand tone, lifestyle, or human context → photographic/editorial style.
- Decorative section dividers, gradient hero fields, abstract texture → Pure Abstract.
- A single headline stat or quote with no UI → a typographic/stat style.
- A literal org/data flowchart with many nodes and routing → Diagrams; UI & Code diagrams stay deliberately sparse (2–4 nodes).

If the artifact would contain readable interface text, code, or a transcript, it is UI & Code. If it would not, it is probably another style.

## 2. What makes it on-brand

### 2.1 Color and tokens

This style is built on a **style-scoped green accent** layered on the warm neutral base from the design system. The green is specific to UI & Code supporting imagery; it does **not** replace Cobolt as the site/CTA accent elsewhere.

> **Note for design system maintainers:** these greens are not yet tokenized in `assemblyai-brand-design-system.md`. They are codified here as a style-scoped palette and should be promoted to official `--color-ui-green-*` tokens.

**Style-scoped green palette:**

| Role | Hex | Usage |
| ---- | --- | ----- |
| Green text / icon | `#01762f` | "Agent" labels, checkmarks, diagram heading text, code keywords/functions, the active caption item. |
| Green highlight | `#99c8ac` | Solid block highlight behind a key token, entity, or PII span. |
| Green fill | `#cce4d5` | Pale fill for the emphasized element: the primary node in a flow, the Agent chat bubble, a callout/compliance banner. |

**Warm base — straight from the design system:**

| Role | Token / hex | Usage |
| ---- | ----------- | ----- |
| Page / canvas bg | `--color-white-200` `#fdfcf8` | Default background behind the artifact. |
| Subtle section tint | `--color-white-300` `#f5f3eb` | Footer strips, secondary panels, the "matte" area behind a window. |
| Card / window surface | `--color-white-100` `#ffffff` | The window, editor, terminal, or chat panel itself. |
| Dark anchor | `--color-black-500` `#1d1b16` | The full-bleed dark variant. |
| Border | `--color-neutral-300` `#c7c3b2` | 1px window borders, bubble outlines, tab dividers, the dotted grid. |
| Heading/code base text | `--color-black-500` `#1d1b16` | Default monospace text and active code lines. |
| Body / secondary text | `--color-black-400` `#4a4945` | Non-emphasized speaker, comments, supporting code. |
| Muted text | `--color-black-300` `#777673` | Inactive caption text, dimmed context lines. |

**Secondary accents — use only as shown, never decoratively:**

| Role | Token / hex | Usage |
| ---- | ----------- | ----- |
| Cobolt | `--color-cobolt-500` `#3923c7` | Syntax: string literals in code. Also second speaker-role label outline when a green role is already in play. |
| Orange | `#e67f36` | Syntax: numeric literals only. |

> **Color discipline:** green is the *single* emphasis accent. Cobolt and orange appear **only** inside realistic code syntax highlighting. Never add a fourth accent hue, and never use the warm Blush scale here.

### 2.2 Typography

- **Everything readable in the artifact is monospace: `Modern Gothic Mono` (fallback `"JetBrains Mono", monospace`).** Chat text, code, terminal output, diagram node labels, and captions are all mono.
- **Labels and annotations** (e.g. `CALLER INTERRUPTS`) follow the design-system eyebrow treatment: Modern Gothic Mono, **uppercase, positive tracking** (`.e1` 12px/1.2px or `.e2` 14px/1.4px).
- **Code follows real syntax conventions:** comments and base code in `#1d1b16`/`#4a4945`, keywords & function calls `#01762f`, strings `#3923c7` (Cobolt), numbers `#e67f36`.
- **Never** set Oceanic Text (serif) or UN 11ST inside the artifact.

### 2.3 Composition, structure, and chrome

- **One artifact per image, centered, with generous breathing room.** A single window/card sits in the frame with comfortable margin to all edges.
- **Window chrome is minimal and consistent:** a rounded-rectangle surface (`--radius-xl` 16px to `--radius-xxl` 24px), a 1px `#c7c3b2` border, a soft low shadow, and `#ffffff`/`#fdfcf8` fill. Editors/browsers get a tab with a filename and a close `×`; terminals get a `>_` tab marker. No traffic-light dots or fake toolbars.
- **Chat transcripts:** speaker bubbles with a leading Material Symbol + role label. Agent: pale green fill `#cce4d5` with `#01762f` label; Caller: white bubble with `#c7c3b2` border and muted text. Bubbles align opposite sides.
- **Highlighting:** drop a solid `#99c8ac`/`#cce4d5` block highlight behind just the relevant characters. Use surgically — a few spans per artifact.
- **Diagrams stay sparse:** 2–4 nodes connected by thin `#c7c3b2` lines, the key node filled green, optionally on a faint dotted grid. A bottom strip of green-checkmark feature labels is an approved supporting element.
- **Level of detail:** realistic but trimmed. Real API names, plausible values, a real conversation — cut anything that doesn't serve the point.
- **Optional focus devices:** a magnifier/loupe overlay; a popover menu; a redaction bar (solid green block for hidden PII). Use at most one per artifact.

### 2.4 Background treatment

- Default: warm `#fdfcf8` canvas (or a `#f5f3eb` matte panel behind the window).
- Dark variant: full-bleed `#1d1b16` background; on dark, code/text base flips to `#f5f3eb`/`#fdfcf8` and muted context to `#777673`; green and Cobolt stay as-is.
- The dotted-grid field is reserved for diagram artifacts, not chat or code.

### 2.5 Export specs

| Spec | Value |
|------|-------|
| **Format** | PNG. |
| **Background** | Transparent when compositing onto a slide/section that supplies its own background; filled (`#fdfcf8`, `#f5f3eb`, or `#1d1b16`) when self-contained. |
| **Resolution** | Export at 2×–4× placed size. Target long edge ≥2560 px for full-bleed, ≥1400 px for inline. |
| **Aspect ratio** | Flexible to content. Diagrams/players ~4:3; code/terminal ~4:3 to ~16:10; chat transcripts tall/portrait. |
| **Color profile** | sRGB. |

## 3. Do / Don't

**Do**
- Set all in-artifact text in Modern Gothic Mono.
- Use green as the single emphasis accent: `#01762f` text/icons, `#cce4d5` fills, `#99c8ac` highlights.
- Keep code/syntax colors realistic: green keywords, Cobolt strings, orange numbers.
- Highlight surgically — a few entity/PII spans, not whole blocks.
- Give the artifact one job and lots of margin; keep window chrome to a filename tab + close, or a `>_` marker.
- Use uppercase mono annotations (`CALLER INTERRUPTS`) for process/timeline labels.

**Don't**
- Don't swap green for Cobolt as the emphasis fill (or vice versa).
- Don't introduce a fourth accent hue or use the Blush error scale decoratively.
- Don't set artifact text in Oceanic Text or UN 11ST.
- Don't add fake browser traffic-lights, dense toolbars, or skeuomorphic chrome.
- Don't highlight entire paragraphs or blanket the artifact in green fill.
- Don't use placeholder/lorem text or syntactically broken code.
- Don't crowd two unrelated UIs into one image.
- Don't put a dotted grid behind chat or code — it's a diagram-only texture.

## 4. Composing inside a slide or web section

UI & Code is the **supporting visual**, not the headline. It pairs with the design system's text styles rather than competing with them.

- **Slide / section anatomy:** Oceanic Text headline and UN 11ST supporting copy carry the message; the UI & Code artifact sits beside or below as the proof.
- **Placement:** works in the media slot of card and river components, and in two-column hero layouts.
- **Background handoff:** match the artifact's field to the section. On `#fdfcf8`, export with transparent or matching background. On dark anchor, use the dark variant.
- **One accent system per section:** if CTAs and eyebrows are Cobolt, the artifact's green reads as a distinct "product output" signal — don't add a third accent.
- **One artifact per section.** If you need to show two things (e.g. code + output), prefer a single artifact that contains both.

---

---

# Style: Demos

> Derived from 7 approved reference frames in the Figma "Website refresh" library (file `o1ezHRtSGFYiOocz4bhg4R`): nodes `3039-12082`, `3039-12083`, `3041-27241`, `3041-27277`, `3041-27410`, `3041-27466`, `3041-27477`.

## 1. Intent

**Demos is the "show what the product does" style: clean, idealized mock-ups of real product interactions, built entirely from brand tokens.** Transcript conversations, code editors, terminals, live-caption players, entity highlights, and simple API-flow diagrams — rendered as legible, on-brand artifacts rather than captured from a live screen. Each frame is theme-named to a capability and carries **real, technically-credible content**: actual AssemblyAI SDK code, plausible agent dialogue, real config keys.

The defining trait: a Demo is a **purpose-built, simplified representation** of the product, not a literal screenshot. It strips the chrome, noise, and inconsistency of a real screen capture and re-renders the interaction in the brand's own type, color, and spacing.

### When to reach for it

- Feature and product sections that need to *show the thing working* — a transcript, a code snippet, an agent turn, a caption stream.
- Developer-facing surfaces where real SDK code earns trust.
- "Here's the output" / "here's the integration" moments: translation, entity detection, timestamps, compliance redaction, medical transcription.
- Launch and use-case content tied to a specific capability.

### When *not* to use it

- **Mood, texture, or ambient brand ground** → Pure Abstract.
- **Explaining architecture or a multi-stage system** → Diagrams (a simple IN → API → OUT flow is fine in Demos; full pipelines belong in Diagrams).
- **A raw, literal screen capture** → use a real-screenshot style.
- **People, customers, or real-world scenes** → photography / illustration.

## 2. Brand patterns and constraints

### 2.1 Color and tokens

Demos run on **two co-equal accent families**, split by surface type:

- **Green — conversational / UI surfaces.** Agent bubbles, entity and PII highlights, success checkmarks, the compliance shield/banner, status labels.
- **Cobolt (+ orange) — code / technical surfaces.** Syntax highlighting inside code editors and terminals.

| Role | Token / value | Notes |
|------|---------------|-------|
| **Green — deep (text/labels/keywords)** | approx. `#14783c` → `#006428` | Agent label, dark body on green fills, code keywords, checkmark/shield glyphs. **Imagery-only.** |
| **Green — mid (highlights)** | approx. `#8cc8a0` / `#99c8ac` | Inline highlight behind entities, PII, medical terms, active config line. |
| **Green — light (fills)** | approx. `#cce4d5` | Agent bubble fill, feature boxes, compliance banner fill. |
| **Cobolt (code syntax)** | Cobolt scale `#3923c7` / `#503cc8` | Functions, strings, and keywords inside code/terminal windows. |
| **Orange (code numerals)** | approx. `#dc7828` | Numeric literals in code syntax only. **Imagery-only.** |
| **Body / UI text** | Black 500 `#1d1b16`, Black 400 `#4a4945` | Caller dialogue, code default text, captions. |
| **Muted / labels** | Black 300 `#777673`, Black 200 `#a5a4a2` | Person/role labels, comments, secondary UI. |
| **Grounds** | White 200 `#fdfcf8`, White 300 `#f5f3eb`, White 100 `#ffffff` | Slide/section ground, card and window fills. |
| **Card borders** | Neutral 300 `#c7c3b2`, Neutral 100/200 | Window chrome, caller bubbles, dividers. |
| **Dark-mode ground** | Black 500 `#1d1b16` | Dark transcript variant (medical frame). |

**Color rules**
- **Match the accent to the surface:** green for conversational/UI demos, Cobolt+orange for code/terminal demos.
- **Highlights are green**, always — entities, PII, medical terms, and the one "look here" config line use the mid-green highlight, never Blush or Cobolt.
- **Code syntax highlighting** is the *only* place orange appears.

### 2.2 Typography

| Element | Font | Notes |
|---------|------|-------|
| Code, terminal output, transcript dialogue | **Modern Gothic Mono** | The demo's primary content. |
| Role / speaker labels | Modern Gothic Mono | With a small leading Material Symbol. |
| Status / event labels | Modern Gothic Mono, **uppercase**, tracked | The standard `.e1`/`.e2` eyebrow treatment. |
| Code-window filename / tab | Modern Gothic Mono | Sits in the window's top chrome bar with a `×` glyph. |

**No Oceanic Text and no UN 11ST inside a Demo asset** — the artifact is mono. Display and body type live in the surrounding template.

### 2.3 Composition

1. **Window / card frame** — rounded container (`--radius-lg`/`--radius-xl`), White 100 fill, thin Neutral border, inset with generous padding.
   - **Code/terminal window:** top bar with filename or `>_` prompt and `×` close glyph.
   - **Plain card:** no top bar; content sits directly inside.
2. **Chat / transcript bubbles** — Agent: light-green fill, green role label with leading glyph. Caller: white or neutral fill with thin border, muted label.
3. **Entity highlights** — mid-green highlight blocks behind specific words.
4. **Feature / status strip** — a row of green checkmarks + uppercase mono labels, or a full-width green footer banner with shield glyph.
5. **Simple flow diagram** — labeled boxes joined by thin connector lines on a faint dotted-grid ground; the active/product box uses green fill.
6. **Optional abstract ground** — a Demo UI can be composited over a Pure Abstract texture, but the UI artifact stays focal.

**Layout tendencies:** one artifact per frame, centered or left-weighted. Content is **cropped/clipped at the frame edge** to imply continuation. Rounded corners, generous internal padding (~24–32px).

### 2.4 Level of detail

**Medium-high, but ruthlessly clean.** Enough real content to be credible; strips everything a real screenshot would carry that doesn't serve the point. One capability per frame.

### 2.5 Content accuracy (non-negotiable)

- **Code must be valid and current** AssemblyAI SDK usage. Don't invent API surface.
- **Dialogue and outputs** should be plausible and on-brand — realistic agent turns, believable entities, no placeholder lorem.
- **Highlights must mark the right thing** — the PII, entity, or config line the demo is about.

### 2.6 Export specs

| Spec | Value |
|------|-------|
| **Format** | PNG. |
| **Background** | **Always filled** — warm off-white or dark Black 500. **Never transparent.** |
| **Aspect ratio** | **4:3** across all seven reference frames. |
| **Resolution** | Author large (long edge ~1550–5100px); export @2x. |
| **Color profile** | sRGB. |
| **Bleed / crop** | Ground bleeds to edge; artifact sits inset; content may clip at frame edge. |

## 3. Do / Don't

**Do**
- Match accent to surface: green for conversational/UI demos, Cobolt+orange for code/terminal syntax.
- Set the content in Modern Gothic Mono.
- Frame the artifact in a rounded window/card with optional filename/`>_` + `×` chrome.
- Use real, accurate AssemblyAI SDK code and plausible dialogue.
- Highlight meaningful words in green.
- Annotate events in uppercase tracked mono.
- Keep one capability per frame; let content clip at the edge.
- Use the dark Black 500 ground when the demo benefits from a terminal/dark-UI read.

**Don't**
- Don't paste a real screenshot.
- Don't set demo content in Oceanic Text or UN 11ST.
- Don't cross the accent wires — no Cobolt agent bubbles, no green-fill code keywords, no orange outside a code window.
- Don't use Blush or any off-system hue.
- Don't ship inaccurate or placeholder content.
- Don't overload the frame with multiple capabilities or decorative elements.
- Don't export transparent or borderless-to-edge.
- Don't build a full architecture diagram here.

## 4. Composing with other styles and with type

### On a web section

- Place the Demo in the media slot of a card, river-flow, or split section; put the headline (Oceanic Text), copy (UN 11ST), eyebrow (Modern Gothic Mono), and CTA in the adjacent copy column.
- Don't overlay readable marketing copy on top of the Demo.
- One Demo per view. Pair it with a clear claim; let the artifact be the evidence.

### On a deck slide

- **Best fit: Layout 8** (full-bleed screenshot / artifact) — centered, no slide title needed. Also works in the right panel of Layout 5/7.
- Don't put a Demo behind text or use it as wallpaper — that's the abstract style's job.

### Pairing with the other styles

Demos are the **proof / "show me" layer**; abstract styles are the **mood layer** and diagram styles are the **explain layer**. A strong rhythm: an abstract opener sets tone, a diagram explains the system, and a Demo proves it works.

---

---

# Style: Maps

> Derived from 5 approved reference frames in the Figma "Website refresh" library (file `o1ezHRtSGFYiOocz4bhg4R`): nodes `3038-19609`, `3048-1866`, `3041-31092`, `3041-31149`, `3041-31206`.

## 1. Intent

**Maps is the "global reach / network" style: a stylized wireframe globe drawn from thin great-circle arcs, dotted with labeled location pills connected by Cobolt routing lines.** It expresses *spread across the world* and *many points on one network* — geographic coverage, multi-region availability, worldwide language support, low-latency edge presence, or a constellation of named entities sitting on a single connected fabric.

The defining trait: a **graticule** (latitude/longitude arcs forming a partial globe) overlaid with **pill-shaped markers**, each a ring-and-dot locator glyph plus a short label, with a few **Cobolt great-circle arcs** weaving through the neutral graticule. It is semi-abstract: the globe is suggested, never a literal rendered earth with coastlines.

### When to reach for it

- Global availability, multi-region deployment, worldwide infrastructure, edge presence, data residency.
- Language and locale coverage ("transcription in N countries / languages").
- A network or ecosystem of named entities placed as nodes.
- Hero washes, banners, and section grounds for enterprise/scale/global narratives.

### When *not* to use it

- **Mood, texture, or ambient brand ground with no labels** → Pure Abstract.
- **Showing the product working** → Demos.
- **Explaining a system, pipeline, or architecture** → Diagrams. Maps suggests a *network of places*, not a process flow.
- **Encoding real data for comparison** → Graphs.

## 2. Brand patterns and constraints

### 2.1 Color and tokens

Maps is **Cobolt-led**, fully inside the design-system palette — no off-system hues.

| Role | Token / value | Notes |
|------|---------------|-------|
| **Connection arcs (accent)** | Cobolt 500 `#3923c7`, with 400/300 `#614fd2`/`#887bdd` | The few "lit" great-circle routes. Cobolt is the only accent. |
| **Graticule — light ground** | Neutral 200/300 `#dad7cb`/`#c7c3b2` | Thin, quiet lat/lon arcs. |
| **Graticule — dark ground** | White 300 `#f5f3eb` at low opacity | Thin light arcs on the dark field. |
| **Ground — light** | White 200 `#fdfcf8`, White 300 `#f5f3eb`, Neutral 100 `#ecebe5` | Warm off-white field. |
| **Ground — dark** | Black 500 `#1d1b16` | The dark globe variant. |
| **Marker label text** | White 100 `#ffffff` on Cobolt fills · Black 500 `#1d1b16` on light fills | Always max contrast. |

**Marker (pill) fill — three sanctioned variants:**

| Pill variant | Fill | Text | Seen in |
|--------------|------|------|---------|
| **Cobolt solid** | Cobolt 500 `#3923c7` | White | `3048-1866` |
| **Cobolt light** | Cobolt 200 `#b0a7e9` | Black 500 | `3038-19609` |
| **Cream / warm white** | White 100/300 with 1px Neutral 300 border | Black 500 | `3041-31092`, `3041-31149/206` |

**Color rules**
- **Cobolt is the only accent.** Do not introduce green, Blush, orange, or any other hue.
- **One pill variant per image.** Don't mix marker styles.
- **Keep the graticule quiet** so Cobolt routes and markers read as the focal layer.

### 2.2 Typography

- **Marker labels are set in UN 11ST** (~14px, line-height 1.3) per the `Pill` primitive. Sentence/proper case.
- **No headlines, eyebrows, or running copy** baked into the asset.

### 2.3 Composition

1. **Graticule globe** — thin great-circle arcs. In **banner** crops, show the top dome arcing across the upper frame. In **full-frame** crops, fill the frame with a denser field.
2. **Connection arcs** — a handful of Cobolt great-circle routes. Few, not many.
3. **Location markers (pills)** — fully rounded pills (`--radius-full`), each with a leading ring-and-dot locator glyph + short label.
4. **Negative space** — generous; markers spread asymmetrically.

**Layout tendencies:** 6–13 markers per frame, distributed to feel scattered-but-balanced. Markers sit *on* the graticule; arcs pass *behind* the pills. Asymmetric, with open field on one side.

### 2.4 Level of detail

**Medium-low.** Thin line work, a quiet graticule, a few Cobolt routes, and a handful of labeled pills. Never a literal earth with continents, terrain, or country borders.

### 2.5 Export specs

| Spec | Value |
|------|-------|
| **Format** | PNG. |
| **Background** | **Always filled** — warm light or dark `#1d1b16`. **Never transparent** unless compositing onto a matching solid section ground. |
| **Aspect ratios** | **Wide banner ≈ 3.1:1** for top-dome crop; **≈ 4:3** for full-frame. |
| **Resolution** | Author large (long edge ~3300–6600px); export @2x. |
| **Color profile** | sRGB. |
| **Bleed** | Globe and graticule bleed to the frame edge. No internal border or padding. |

## 3. Do / Don't

**Do**
- Lead with Cobolt for the connection arcs; keep the whole image inside the design-system palette.
- Draw a thin great-circle graticule and let a few Cobolt routes weave through it.
- Use the `Pill` primitive for markers — fully rounded, UN 11ST label, a leading ring-and-dot locator glyph.
- Pick one pill variant per image and apply it to every marker.
- Match the banner crop to a top-dome globe and the square-ish crop to a fuller field.
- Spread markers asymmetrically with generous negative space.
- Bleed arcs to the edge and export filled PNG.

**Don't**
- Don't render a literal earth — no coastlines, continents, country outlines, or terrain.
- Don't introduce off-palette color.
- Don't mix marker variants in one frame.
- Don't set labels in Oceanic Text or Modern Gothic Mono.
- Don't bake headlines or body copy into the asset.
- Don't overcrowd with dozens of markers or a dense web of arcs.
- Don't add film grain or heavy texture — that's Pure Abstract's signature.
- Don't export transparent or with internal padding.

## 4. Composing with other styles and with type

### On a web section

- **As a section/hero background:** place the globe full-bleed and layer headline, copy, eyebrow, and CTAs over it. **Guarantee contrast** — anchor text over the calmer negative-space region, or behind a solid/scrim panel.
- **As a banner:** the 3:1 top-dome crop fits full-width hero and section banners.
- **One Maps image per view.**

### On a deck slide

- **Best fit:** section dividers, cover/section-title moments, and "global scale" stat slides.
- Don't put Maps behind dense content slides (bullets, tables, code, charts) — those want a flat warm or Cobolt ground.

### Pairing with the other styles

Maps is a **scene-setting / "global context" layer**. A healthy rhythm: a Maps opener establishes worldwide scale, then literal styles do the explaining. Never overlay a literal style (screenshot, chart) on top of the globe in one frame.

---

---

# Style: Pure Abstract

> Derived from 7 approved reference frames in the Figma "Website refresh" library (file `o1ezHRtSGFYiOocz4bhg4R`): `Security_03` and six siblings (nodes `3041-30193`, `3038-19293`, `3038-18319`, `3038-18205`, `3038-18131`, `3038-17646`, `3038-17352`).

## 1. Intent

**Pure Abstract is the texture-and-geometry style: grainy, gradient-filled geometric compositions with no literal subject.** It carries mood and brand presence through abstracted form alone: stepped gradient columns, smooth-gradient ovals and pills, isometric cubes, perspective grids, concentric ripples, and vertical gradient bands. A theme can be *hinted* with a single minimal motif (e.g. an abstracted padlock for security) but the image is never a depiction of a product, a person, a screen, or a scene.

### When to reach for it

- Section backgrounds, hero washes, and full-bleed banners on the web.
- Deck section dividers, cover wallpaper, and "breather" slides between content.
- Card / tile art and social-post backgrounds where a screenshot or diagram would be too literal or too busy.
- Any moment that is **evocative rather than explanatory** — a launch teaser, a topic opener, an ambient texture behind a headline.

### When *not* to use it

- **Showing the product** → UI & Code or Demos.
- **Explaining a system or flow** → Diagrams.
- **Depicting people, customers, or real-world context** → photography / illustration.
- **Presenting data** → Graphs. The dithered columns in Pure Abstract *evoke* data; they never *encode* it.

Rule of thumb: **if the viewer needs to read, compare, or follow anything in the image, this is the wrong style.** Pure Abstract is for feeling, not information.

## 2. Brand patterns and constraints

### 2.1 Color and tokens

| Role | Token / value | Notes |
|------|---------------|-------|
| **Primary** | Cobolt scale — `#3923c7` (500), `#614fd2` (400), `#887bdd` (300), `#b0a7e9` (200), `#d7d3f4` (100) | Dominant hue in every frame. Gradients ramp *within* this scale. |
| **Secondary (imagery only)** | Deep emerald green, approx. `#1f6b3f` mid, ramping to `#003018` deep | **Not a core design-system token.** Sanctioned *only* for Pure Abstract imagery. |
| **Dark field** | Black 500 `#1d1b16` → near-black | Dark base for high-contrast frames. |
| **Light field** | White 200 `#fdfcf8`, White 100 `#ffffff`, White 300 `#f5f3eb` | Warm off-white grounds. |
| **Neutral** | Neutral 100–300 `#ecebe5`–`#c7c3b2` | Grayscale gradient grounds. |
| **Rare thematic accents** | Blush family `#e39389` / `#ec9d92`; one warm spot | Single small element only. Never a large fill; never more than one such accent per image. |

**Color rules**
- **Cobolt must read as the dominant or co-dominant hue** in every Pure Abstract image. Green is a partner, never the lead.
- **Two-hue maximum for the structure** (Cobolt + green, or Cobolt + neutral). Pink/yellow appear only as a single small thematic spot.
- Gradients ramp **within one hue family** per shape. Do not blend Cobolt directly into green across a single shape.

### 2.2 Typography

**None.** Pure Abstract images carry **no text** — no headlines, labels, eyebrows, watermarks, or captions baked into the asset. Type is layered *over* the image by the slide or web template.

### 2.3 Composition

Built from a consistent grammar (confirmed in the Figma layer tree of `Security_03`):

1. **Base** — a full-frame gradient fill: either a dark field or a warm/neutral field.
2. **Form blocks** — one to four named geometric primitives:
   - **Stepped / dithered gradient columns** — stacked rectangles whose fill steps in discrete bands. The signature motif.
   - **Smooth-gradient ovals & pills** — soft vertical or radial gradients inside rounded forms.
   - **Isometric cubes** — 2.5D blocks in Cobolt and black on a gray gradient.
   - **Perspective grid** — a receding floor plane, mostly dark, with a few lit tiles.
   - **Concentric ripples** — radial rings, Cobolt, centered.
   - **Vertical gradient bands** — full-bleed stripes of Cobolt gradient.
3. **Optional thematic motif** — one minimal abstracted icon-shape (e.g. `Lock`) and/or a thin connector `Line`. Single, small, off to one side.
4. **Grain overlay** — a layered texture stack applied last, over everything.

**Layout tendencies:** asymmetric and left-weighted; dense form-blocks cluster to one side, negative space opens to the other. Generous negative space.

### 2.4 Level of detail

Medium-low. **A few bold forms, not many small ones.** Detail lives in the *gradient banding and grain*, not in shape count. Never busy, never illustrative, never figurative beyond a single hinted motif.

### 2.5 Texture / grain (signature, non-negotiable)

Every Pure Abstract image carries a **layered film-grain overlay**. The `Security_03` frame builds it from a stacked `Texture` group:

- `Paper_Aged` — warm paper base
- `Paper_Highlights` — subtle lightness variation
- `Halftone_Texture` — fine dot structure
- `Noise_Texture` — film noise
- `Speck_Texture` — sparse specks

Apply grain as the topmost layer, at a strength that is clearly visible but never muddy.

### 2.6 Export specs

| Spec | Value |
|------|-------|
| **Format** | Raster **PNG** (grain + gradients demand it). |
| **Background** | **Always filled** — dark or warm/neutral. **Never transparent.** |
| **Aspect ratios** | Wide banner ≈ **4.45:1** and ≈ **3:1**; standard block **4:3**. |
| **Resolution** | Author large (long edge ~2400–8100px); export @2x. |
| **Color profile** | sRGB. |
| **Bleed** | Design to bleed — forms and grain run to the frame edge. No internal border or padding. |

## 3. Do / Don't

**Do**
- Lead with Cobolt and keep the whole image inside the sanctioned palette.
- Apply the layered grain overlay on top of everything.
- Build from the established form vocabulary: stepped gradient columns, gradient ovals/pills, isometric cubes, perspective grid, concentric ripples, vertical bands.
- Keep it to one or two bold gestures with generous negative space and asymmetric, left-weighted balance.
- Hint a theme with at most one minimal abstracted motif placed small and to the side.
- Ramp gradients within a single hue family per shape.
- Bleed forms and grain to the edge and export filled PNG.

**Don't**
- Don't bake in text of any kind.
- Don't let green outweigh Cobolt, and don't blend Cobolt directly into green inside one shape.
- Don't introduce off-palette hues. Green and the Blush-range pink are the only sanctioned exceptions.
- Don't render literal content — no real UI, screenshots, charts that encode data, people, or logos-as-subject.
- Don't ship it flat / grain-free.
- Don't crowd the frame with many small forms or kill the negative space.
- Don't export with a transparent background.

## 4. Composing with other styles and with type

### On a web section

- **As a section/hero background:** place full-bleed; layer headline, copy, eyebrow, and CTAs over it using standard tokens. **Guarantee contrast** — avoid readable body copy directly on busy gradient areas.
- **As card or tile art:** crop a region into the card's media slot; keep the card's own copy in a separate solid area.
- **One abstract per view.** Don't stack multiple Pure Abstract images in adjacent sections.

### On a deck slide

- **Best fit:** Layout 1 (Cover), Layout 2 (Section divider), and Layout 3 (Section title).
- Don't put it behind dense content slides (Layouts 4–8) where it would fight bullets, tables, charts, or screenshots.
- Honor the one-accent rule: if the abstract is already carrying green, don't also introduce other accent colors in the slide's type or shapes.

### Pairing with the other styles

Pure Abstract is the **mood/transition layer**; literal styles are the **explain layer**. A healthy rhythm alternates them: an abstract opener or divider, then literal content surfaces. Never overlay one literal style on top of a Pure Abstract ground in the same frame.

---

---

# Style: Literal × Abstract

> Derived from 4 approved reference frames in the Figma "Website refresh" library (file `o1ezHRtSGFYiOocz4bhg4R`): nodes `3038-19198` (usage chart card on Cobolt ground), `3041-27122` (same card on green ground), `3038-19238` (isometric data-layer planes + lock on Cobolt ground), `3038-70159` (permissions UI matrix on dark ground).

## 1. Intent

**Literal × Abstract is the "product moment on a brand ground" style: a clean, literal artifact — a Demos/UI card, chart, data-layer diagram, or UI panel — composited on top of a Pure Abstract textured ground.** The abstract layer supplies mood, depth, and brand color; the literal layer supplies a concrete, readable thing. The tension between **grainy, gradient abstraction** and **crisp, on-token UI** is the whole point.

The defining trait: **two stacked layers in one frame.** A Pure Abstract field fills the background; a single literal artifact floats above it. Neither layer alone is this style — it is specifically the *overlay*.

### When to reach for it

- Hero and feature visuals that need to *show something real* while carrying brand atmosphere.
- Pricing/usage, scale, security, and capability moments where a lone Demos card would feel flat and a lone abstract would say nothing concrete.
- Launch and campaign imagery that wants both "here's the thing" and "here's the vibe" in a single asset.

### When *not* to use it

- **Mood / atmosphere with no concrete artifact** → Pure Abstract alone.
- **A clean product artifact that should read as honest UI/output** → Demos or UI & Code alone.
- **Global reach / networked points** → Maps.
- **A literal architecture/flow explanation** → Diagrams.

Rule of thumb: **use it only when both layers earn their place** — a real artifact worth showing *and* a reason for the brand ground beneath it.

## 2. Brand patterns and constraints

### 2.1 The two layers

| Layer | Source style | Role |
|-------|--------------|------|
| **Ground (back)** | Pure Abstract | Full-bleed grainy, gradient/banded field. Carries brand color and mood. **Always textured — grain is non-negotiable.** |
| **Artifact (front)** | Demos / UI & Code | One clean, flat, on-token literal element. **No grain on the artifact.** |

The single most important rule: **grain lives on the ground, never on the artifact.** The literal layer stays crisp and flat so it reads as "real UI" against the textured field.

### 2.2 Color and tokens

- **Ground** is Cobolt-led per Pure Abstract: a Cobolt-scale field, the sanctioned **emerald-green** variant, or a **dark** Black 500 field. One ground hue family per image.
- **Artifact** uses the literal modules' palette: White 100 card surfaces, Neutral 300 borders, warm cream chart/area fills, Black 500 text, and **Cobolt** for accents.
- **Keep the ground hue and the artifact accent in the same family.** Cobolt ground → Cobolt artifact accents. The green-ground variant keeps the *same* literal card — only the ground hue changes; the artifact does **not** get recolored green.

### 2.3 Typography

- **The ground carries no type** (Pure Abstract rule). All text lives in the artifact.
- **No headline/eyebrow baked into the asset.** Template type goes on top.

### 2.4 Composition

1. **Ground fills the frame**, bleeding to all edges, with the grain overlay on top.
2. **One artifact, centered or near-centered**, floating above the ground with clear margin so the textured field shows around it on all sides.
3. **Separation between layers** comes from contrast (crisp vs. grainy, opaque card vs. textured field) and, where shown, a subtle outer rounded frame/1px border on the whole composite.
4. **One literal artifact per frame.** Don't scatter multiple cards across the ground.

### 2.5 Level of detail

**Medium.** The ground stays low-detail (one or two bold gestures + grain); the artifact stays clean and purposeful. The combined image reads in one glance as "a real thing on a brand field."

### 2.6 Export specs

| Spec | Value |
|------|-------|
| **Format** | **PNG** — required: the ground's grain + gradients cannot survive SVG. |
| **Background** | **Always filled** (the abstract ground *is* the background). **Never transparent.** |
| **Aspect ratio** | **~4:3** across all four reference frames. |
| **Resolution** | Author large (long edge ~3800–5100px); export @2x. |
| **Color profile** | sRGB. |
| **Bleed / frame** | Ground bleeds to the edge. A subtle rounded outer frame/border may sit just inside the edge. |

## 3. Do / Don't

**Do**
- Stack exactly two layers: a Pure Abstract ground + one literal artifact.
- Keep grain on the ground and the artifact perfectly clean/flat.
- Match the artifact's Cobolt accents to a Cobolt ground; keep the same artifact when only the ground hue changes.
- Center one focal artifact with ground showing around it.
- Use the dark-ground variant when the artifact reads better on dark.
- Let each layer follow its own style's rules, and only manage the seam here.
- Export filled PNG at ~4:3 with the ground bleeding to the edge.

**Don't**
- Don't apply grain/texture to the artifact — the literal layer is always crisp.
- Don't ship a single layer and call it this style.
- Don't recolor the artifact to match a green/dark ground.
- Don't introduce off-system hues at the seam.
- Don't crowd the frame with multiple cards/artifacts or extra decorative elements.
- Don't bake headline/eyebrow/body copy into the asset.
- Don't run readable marketing copy across the grainy ground.
- Don't export transparent.

## 4. Composing with other styles and with type

### On a web section

- **As feature/hero media:** drop the composite into the media slot; put the headline, copy, eyebrow, and CTA in the adjacent copy column.
- **If overlaying type on the asset**, anchor it over the artifact's calm surface or a quiet region of the ground, with guaranteed contrast.
- **One composite per view.** Because it already carries texture, don't place it next to a Pure Abstract ground — alternate with the warm off-white base.

### On a deck slide

- **Best fit:** feature/proof slides and section openers — the composite sits as full-bleed or panel art.
- Don't also lay it behind dense content (bullets, tables, code) — its artifact + grain will fight the content.

### Pairing with the other styles

Think of the style map as: **Pure Abstract = mood only; Demos / UI & Code = literal only; Literal × Abstract = the deliberate fusion of the two.** Don't place it adjacent to its own parent styles in the same view. Never stack a second literal artifact or a Maps globe on top of the composite — two layers is the ceiling.

---

---

# Style: Graphs

> Derived from 4 approved reference frames in the Figma "Website refresh" library (file `o1ezHRtSGFYiOocz4bhg4R`): nodes `3041-27488` (WER vertical bar chart), `3041-27575` (Missed-entity grouped multi-series bars), `3041-27727` (price-performance scatter), `3041-27811` (WER bars + dataset filter).

## 1. Intent

**Graphs is the data-visualization style: real charts that encode real numbers — bar charts, grouped multi-series bars, and scatter plots — built to compare AssemblyAI against competitors and to make benchmark claims credibly.** Unlike every other supporting-imagery style, a Graph *means something quantitatively*: the bar heights, point positions, and axis values are accurate data, and AssemblyAI is always the highlighted, winning series.

The defining trait: an **honest, on-token chart** in a benchmark layout — a serif heading, a short methodology note, a "*LOWER IS BETTER*" / metric caption, and the plot itself, with **AssemblyAI rendered in Cobolt and all competitors in muted warm neutrals**.

### When to reach for it

- Benchmark and accuracy claims (WER, missed-entity rate, diarization, multilingual, code-switching).
- Price-performance / value positioning (cost vs. quality scatter).
- Any "we measured it and here's proof" moment.

### When *not* to use it

- **Evoking "data/signal" as mood** → Pure Abstract. Its dithered columns *suggest* a chart; Graphs *is* one.
- **A single headline number with no comparison** → a stat treatment, not a full chart.
- **Showing the product working** → Demos / UI & Code.

Rule of thumb: **if the viewer is meant to read, compare, or trust specific values, this is the only correct style.** Accuracy is the whole job — never fake the data.

## 2. Brand patterns and constraints

### 2.1 Color and tokens

| Role | Token / value | Notes |
|------|---------------|-------|
| **AssemblyAI series / winning value** | Cobolt 500 `#3923c7` | The highlighted bar, the ringed scatter marker. Always Cobolt. |
| **Competitor series / bars** | Neutral 200 `#dad7cb` fill | Quiet gray-tan bars/dots so AssemblyAI stands out. |
| **Bar "track" / remainder** | Neutral 100 `#ecebe5` / White 300 | Unfilled portion of a bar; AssemblyAI's track carries a thin Cobolt outline. |
| **Plot ground** | White 300 `#f5f3eb` / White 200 `#fdfcf8` | Warm off-white section ground. |
| **Gridlines / axes / dividers** | Neutral 300 `#c7c3b2` | Thin axis lines, scatter grid, tab underlines. |
| **Heading / value text** | Black 500 `#1d1b16` | Chart heading, data labels. |
| **Body / axis-tick text** | Black 400 `#4a4945`, Black 300 `#777673` | Methodology copy, axis ticks, category labels. |
| **AssemblyAI category label** | Cobolt 500 `#3923c7` | The x-axis label under the AssemblyAI bar/point is Cobolt. |
| **Metric caption / "*LOWER IS BETTER*"** | Cobolt 500, Modern Gothic Mono, uppercase | The mono Cobolt note beside the methodology copy. |

**Multi-series categorical palette (style-scoped — for grouped charts only):**

| Series | Color | Token |
|--------|-------|-------|
| 1 | `#3923c7` | Cobolt 500 |
| 2 | `#614fd2` / `#887bdd` | Cobolt 400 / 300 |
| 3 | `#b0a7e9` / `#d7d3f4` | Cobolt 200 / 100 |
| 4 | olive/dark warm neutral | Neutral (dark) |
| 5 | tan | Neutral 200 |
| 6 | light tan | Neutral 100 |
| 7 | `#e39389` | Blush 500 |
| 8 | `#eebeb8` / `#f4d4d0` | Blush 200/300 |

> **Flag for design system maintainers:** this categorical palette uses the **Blush** scale as ordinary data-series colors. The design system reserves Blush for **error/correction states only**. It is codified here as a **style-scoped, grouped-chart-only** extension and should be promoted to an official chart palette. **Do not** use Blush as a data color outside multi-series charts.

**Color rules**
- **AssemblyAI is always Cobolt 500 and always the most prominent series; competitors are always muted Neutral.**
- **Single-series charts** use only Cobolt (AAI) + Neutral (others). The categorical palette applies *only* when a chart genuinely has multiple data categories.

### 2.2 Typography

| Element | Font | Notes |
|---------|------|-------|
| Chart heading | **Oceanic Text** (serif), weight 400 | `.h3`/`.h4` scale, sentence case. |
| Methodology / supporting copy | **UN 11ST** (body) | `.p3`/`.p4`, left-aligned, Black 400. |
| Metric caption + `*LOWER IS BETTER*` | **Modern Gothic Mono**, uppercase, tracked | `.e2`; caption is Black 400, the note is Cobolt. |
| Metric-tab nav labels | UN 11ST | Active = Cobolt with Cobolt underline; inactive = Black 300. |
| Data labels, axis ticks, legend | UN 11ST, small (`.p5` 14px) | Value labels may be rotated vertical. AAI category label in Cobolt. |
| Filter dropdown | UN 11ST | Standard select: White fill, Neutral 300 border. |

This is the one style that **deliberately uses all three brand faces** (serif heading + sans body/data + mono caption).

### 2.3 Composition and spacing

Laid out on the section grid (1440px canvas, `148px`/`120px` padding):

1. **Optional left metric-tab nav** — a vertical list of metric names; the active item is Cobolt with a Cobolt underline.
2. **Header block** — serif heading, then a two-column row: methodology copy on the left and caption + mono Cobolt note on the right, separated by a thin vertical Neutral divider.
3. **Plot area** — the chart, generous width, on the warm ground:
   - **Vertical bars:** full-height tracks with a value fill; AAI bar Cobolt with Cobolt-outlined track; rotated value labels; category labels below.
   - **Grouped bars:** clustered series per provider with a top legend.
   - **Scatter:** gridded plot; competitor points as small Neutral dots, AAI points as Cobolt ring markers with Cobolt labels and an optional "Best value" note.
4. **Optional filter** — a dropdown below the chart to switch the dataset/view.

### 2.4 Level of detail

**High — but only meaningful detail.** Real values, real axis scales, real provider names, accurate proportions. Strip chart junk: no 3D, no drop shadows, no heavy gridlines. Every mark encodes data.

### 2.5 Data accuracy (non-negotiable)

> Before building, run the **chart-type decision guide (§5)** to pick the right encoding, then validate against the **accuracy checklist (§6)**. Both are mandatory.

- Use actual benchmark numbers and real provider/model names.
- AssemblyAI must legitimately be the highlighted/leading series for the metric shown.
- State the metric direction (`*LOWER IS BETTER*`) and the basis.
- Verify figures against current benchmarks/`/compare` data before publishing.

### 2.6 Export specs

| Spec | Value |
|------|-------|
| **Format** | **PNG** for raster export; or build natively in-page/in-deck as vector. |
| **Background** | **Filled** warm off-white. Transparent acceptable **only** when dropping onto a matching warm section ground. |
| **Aspect ratio** | **Wide section** ≈ 1440×~800–980. Author full-width; can also be cropped to plot for inline/card use. |
| **Resolution** | Author at 1440-canvas scale; export @2x. |
| **Color profile** | sRGB. |

## 3. Do / Don't

**Do**
- Make AssemblyAI Cobolt 500 and the clear hero series; mute every competitor to Neutral.
- Encode real, accurate data with honest axes and a stated metric direction.
- Use all three brand faces in their roles: Oceanic Text heading, UN 11ST body/data, Modern Gothic Mono Cobolt caption.
- Label directly and keep chart junk out — rotated value labels, thin Neutral gridlines, no shadows/3D.
- Add the left metric-tab nav and/or a dataset filter when the chart is one of several views.
- Reserve the multi-series palette for genuinely categorical grouped charts, in order.
- Color the AssemblyAI x-axis label Cobolt.

**Don't**
- Don't fake or distort data — no invented numbers, truncated axes, or highlighting a metric AssemblyAI doesn't win.
- Don't let a competitor carry the Cobolt/hero color.
- Don't use Blush as a data color outside multi-series grouped charts.
- Don't add 3D, shadows, gradients, or heavy gridlines.
- Don't set chart text in the wrong face.
- Don't confuse this with Pure Abstract — if the bars don't encode real values, you're in the wrong style.

## 4. Composing with other styles and with type

Graphs are **self-contained, type-rich section layouts** — they usually *are* the section rather than sitting behind one.

### On a web section

- **As the section itself:** drop the chart layout into a full-width section. The built-in serif heading + methodology copy carry the message.
- **As inline/card media:** crop to the plot and place it in a card or split section.
- **Pair with a metric-tab nav** to let one section cycle through several benchmark views.

### On a deck slide

- **Best fit:** data/proof slides. Put the chart in the content area with a serif slide title.
- Don't lay a Graph over a textured/abstract ground — data needs the calm warm field for legibility.

### Pairing with the other styles

Graphs are the **proof-by-numbers layer**. Never substitute Pure Abstract's evocative "data" texture for a real Graph when a claim is being made. Never overlay a Graph on another style's imagery in one frame.

## 5. Chart-type selection guide

**Pick the encoding from the shape of the data, not from preference.**

| Your data | Use | Why | Example |
|-----------|-----|-----|---------|
| **One value per item**, comparing items on a single metric | **Single-series bar chart** | One bar per item, sorted best→worst. AssemblyAI Cobolt, others Neutral. | `3041-27488` / `3041-27811` |
| **Several sub-values per item**, comparing breakdown across items | **Grouped bar chart** | Clustered bars per item + legend; use the multi-series palette in order. | `3041-27575` |
| **Two continuous variables in tension** (e.g. price vs. accuracy) | **Scatter plot** | Point per item on X/Y grid; AAI as Cobolt ring markers, competitors as Neutral dots. | `3041-27727` |

**Decision shortcuts**
- Ranking items on one number → **single-series bar**, sorted, not a scatter.
- Comparing multi-part composition across items → **grouped bar**.
- "Better on two axes at once" / cost-quality tradeoff → **scatter**.
- More than ~3–4 categories per group → consider small multiples or metric-tab nav.

**Beyond the three:** create a new chart type only when the data demands it, and all three defaults genuinely fail. Build it fully on-brand and note what you did.

## 6. Accuracy checklist (verify before publishing)

Every Graph must pass all of these. Treat any failure as a blocker.

**Data integrity**
- [ ] Every value is real, sourced, and current.
- [ ] Provider/model names and versions are correct and current.
- [ ] AssemblyAI legitimately leads the metric shown.
- [ ] The comparison is apples-to-apples. State the basis.

**Encoding integrity**
- [ ] **Bar charts start at a zero baseline.**
- [ ] Bar lengths / point positions are exactly proportional to the values.
- [ ] Axis scales are linear and consistent; if log scale is used, label it.
- [ ] Grouped charts keep identical category order, color mapping, and scale across every group.
- [ ] Scatter axes have real units, tick labels, and an honest origin.

**Labeling integrity**
- [ ] Metric direction is stated (`*LOWER IS BETTER*` / higher-is-better).
- [ ] Units are shown (%, $, ms, hrs).
- [ ] Every series is identified.
- [ ] The AssemblyAI series is visually dominant (Cobolt) and its label is Cobolt.
- [ ] A source/as-of note is available where the claim warrants it.

**Style integrity**
- [ ] Single-series = Cobolt (AAI) + Neutral (others) only; multi-series uses §2.1 palette in order.
- [ ] Flat, thin, honest — no 3D, shadows, gradients, or heavy gridlines.
- [ ] Heading is Oceanic Text, data/labels UN 11ST, metric note Modern Gothic Mono Cobolt.

---

---

# Style: Diagrams

> **v0.1 (draft)** · Derived from a **single** approved reference frame in the Figma "Website refresh" library (file `o1ezHRtSGFYiOocz4bhg4R`, node `3041-30915`): a horizontal input → engine → outputs flow.
>
> ⚠️ **Single-reference caveat.** This section is defined from one example and describes the pattern that frame establishes. Treat specifics (exact spacing, the checkmark tint, connector routing) as **provisional**; confirm with design before extending the style to layouts the single example doesn't show (vertical flows, branching trees, loops, swimlanes). Don't over-generalize from one frame.

## 1. Intent

**Diagrams is the "explain the system" style: a flow that shows how inputs move through AssemblyAI to become outcomes.** The reference frame reads left → right as three zones — **Input** (any voice/audio), **Engine** (the AssemblyAI Speech API), **Outputs** (a grid of things you can build) — joined by thin connector lines on a dark gridded ground. It is conceptual and architectural: it names the parts of a system and the direction of flow, without encoding quantities (that's **Graphs**) or rendering real UI (that's **Demos**).

### When to reach for it

- Product/architecture overviews: audio in → Speech API → results.
- "One API, many outcomes" stories — a single engine fanning out to many use-cases or capabilities.
- Pipeline and integration explanations where the *relationship and direction* between parts is the point.

### When *not* to use it

- **Encoding real numbers / benchmarks** → Graphs.
- **Showing the product working** → Demos / UI & Code.
- **Geographic reach / a network of places** → Maps.
- **Pure mood / texture with no labeled parts** → Pure Abstract.

## 2. Brand patterns and constraints

### 2.1 The three-zone flow (from the reference)

| Zone | What it is | Built from |
|------|-----------|------------|
| **Input (left)** | A Cobolt grainy waveform/banded block titled `Voice + Audio` with a muted sub-label. | A small Pure Abstract texture block (Cobolt + grain) acting as a labeled node. |
| **Engine (center)** | A circular ring node holding the **AssemblyAI logo mark**, with a chip below labeled `⊛ Speech API`. | A ring/circle node + a Pill-style chip with a leading brand glyph. |
| **Outputs (right)** | A grid of outcome chips, each a leading check icon + short label. | The **`Pill` primitive** on dark, with **green check** glyphs as the success signal. |

Flow direction is **left → right**, Input → Engine → Outputs.

### 2.2 Color and tokens

| Role | Token / value | Notes |
|------|---------------|-------|
| **Ground** | Black 500 `#1d1b16` | Dark field with a **faint Neutral grid** at low opacity. |
| **Connectors** | Neutral 300 `#c7c3b2` at low opacity | Thin lines linking zones. |
| **Input accent** | Cobolt scale `#3923c7`/`#614fd2`/`#887bdd` | The waveform/banded texture. |
| **Engine accent** | Cobolt | The logo mark / ring node. |
| **Output success icon** | Green `#01762f` check (per Demos) | The "outcome achieved" signal on each output chip. |
| **Chip fill / border** | Dark fill + 1px Neutral 300 border | Output pills and the Speech-API chip (dark variant). |
| **Text** | White 200 `#fdfcf8` titles, Black 200 `#a5a4a2` muted sub-labels | High-contrast labels on dark; muted secondary lines. |

**Color rules**
- **Cobolt leads** (input texture + engine); **green is confined to the output check icons**; everything else is neutral chrome on a dark ground.
- Keep connectors and the grid quiet so the three zones read as the content.

### 2.3 Typography

- **Node titles and chip labels: UN 11ST (body face)** — short, sentence/spec case, matching the `Pill` primitive. Muted sub-labels in Black 200.
- **No serif headline or running copy** baked into the asset. Template type goes on top.

### 2.4 Composition and spacing

- **Horizontal, left → right, three zones**, with the engine centered as the hub.
- **Thin connector lines** route between zones (quiet, low-contrast). Lines pass behind chips; nodes sit on top.
- **Outputs arranged in a tidy grid** of equal chips with consistent gaps.
- **Generous negative space** and a faint background grid for alignment.
- Keep it to a **readable number of nodes** — one input, one engine, one tidy output grid.

### 2.5 Level of detail

**Medium-low.** A few labeled nodes, one hub, a grid of outcome chips, thin connectors. The image reads in one glance as "audio in → AssemblyAI → outcomes." Never a dense technical schematic.

### 2.6 Export specs

| Spec | Value |
|------|-------|
| **Format** | **PNG** (the input block carries grain + gradient; needs raster). |
| **Background** | **Filled dark** (`#1d1b16`). Not shown on light — confirm first. |
| **Aspect ratio** | **Wide banner ≈ 3.25:1** (1440×444). Author wide; this is a horizontal flow. |
| **Resolution** | Author at ≥1440 wide; export @2x. |
| **Color profile** | sRGB. |
| **Bleed** | Ground fills the frame; nodes inset with margin; the grid may bleed to the edge. |

## 3. Do / Don't

**Do**
- Lay out a left → right, three-zone flow (Input → Engine → Outputs) with the AssemblyAI engine as the hub.
- Reuse the proven pieces: a Pure Abstract Cobolt+grain block for the input, the logo in a ring node for the engine, Pill-primitive chips with green check icons for the outputs.
- Keep connectors thin and quiet on a dark gridded ground.
- Confine green to the output check icons and keep Cobolt on the input/engine.
- Label nodes in UN 11ST, short and plain, with muted Black 200 sub-labels.
- Hold to a readable node count — one input, one engine, one tidy output grid.

**Don't**
- Don't encode quantities — no bar heights, axes, or values (that's Graphs).
- Don't render real UI/code/transcripts inside the nodes (that's Demos / UI & Code).
- Don't sprawl into many stages, crossing connectors, or a dense schematic.
- Don't introduce new accent hues — Cobolt (input/engine) + green (output checks) + neutral chrome only.
- Don't set diagram labels in serif or mono without reason.
- Don't bake a headline/eyebrow into the asset.
- Don't invent unshown layouts (vertical flow, branching trees, loops, swimlanes, light ground) and present them as canonical — confirm with design first.

## 4. Composing with other styles and with type

Diagrams are the **"explain layer"** — they map the system so other styles can prove and decorate it.

### On a web section

- **As feature/overview media:** place the flow full-width or in the media slot; put the headline, copy, eyebrow, and CTA in the adjacent copy. The diagram explains; the copy frames.
- **If overlaying type**, anchor it over the calm dark area, not across the input texture or chip grid.
- **One diagram per view.**

### On a deck slide

- **Best fit:** an architecture/"how it works" slide — the flow sits as the centerpiece on the dark ground with a serif slide title above.
- Don't lay dense content over it; connectors and chips need their space.

### Pairing with the other styles

In a deck or page, Diagrams **explain**, Graphs **prove with numbers**, Demos / UI & Code **show the product**, Maps shows **reach**, and Pure Abstract / Literal × Abstract carry **mood**. A natural sequence: a Diagram lays out the input → engine → outputs system, then a Demos frame shows one output for real and a Graph proves it's measurably better.