Blitz Brand Lab · Source of truth

One system, from token to page

The Brand Lab is the canonical reference of the BlitzAPI website. It renders the real tokens, assets, motion, sections and templates from the same source files as the site, so any page can be rebuilt the same way twice.

146 TOKENS57 ASSETS12 SIGNATURES29 SECTIONS12 TEMPLATES18 BLOCKS25 DIRECTORY PAGES
01Foundations

Tokens read from tokens.css: color, type, spacing, rhythm, grid, motion. Plus the UI primitives.

146 TOKENS · 3 BREAKPOINTS
02Assets

Atomic Data/B2B signs, one idea each, static by default, parameterized by props.

57 ASSETS · 27 ICON ROLES
03Motion

Live variants, brand signatures, automations and the MotionScene diagrams mounted in the heroes.

40 LIVE · 12 SIGNATURES · 6 RECIPES
04Sections

The production components, rendered live with the site’s own JSON, with their data contract.

29 SECTIONS · 6 GROUPS
05Templates

The composition contracts of every page type: data source, section order, checks, recipe.

10 LIVE · 2 DORMANT
06Content

The editorial and lesson blocks of the blog and Learn modules, and their reading layouts.

18 BLOCKS · 12 SHARED · 7 LESSON
07Code

How code appears on the site: panels, annotated payloads, tabs, and the API contract every snippet follows.

PANELS · SNIPPETS · CONTRACT
Read top to bottom

A page starts from the tokens, chooses assets, optionally turns on their motion, composes sections inside an authorized template, and fills it with data.

TOKEN → ASSET → MOTION → SECTION → TEMPLATE → CONTENT
01
How a page gets built

Five steps, the same every time

The lab exists for this: a product, use case or persona page is rebuilt from a template contract and a JSON file, not from a redesign.

10 LIVE TEMPLATES
  1. 01
    Pick the template

    Every page type is a contract: data source, section order, mandatory fields. Product, use case, team, hub, pricing, legal…

    Templates →
  2. 02
    Write the data

    One JSON per page in src/content or src/data/pages. Zero copy in a template: the H1, the FAQ and the endpoint live in the data.

    Templates · recipe →
  3. 03
    Let the sections render

    Each JSON kind maps to one production component. Missing fields trigger silent fallbacks, so the contract lists them.

    Sections →
  4. 04
    Add the proof

    An asset id in the JSON, a MotionScene spec for a framed hero, a signature for the conversion band. Never an image.

    Assets · Motion →
  5. 05
    Verify

    Build, run scripts/audit-sept.py dist (links, forbidden terms, SEO bounds, offer), then measure: rails, gutter, no overflow at 1440 / 991 / 767 / 375.

    Foundations · grid →
02
Canonical contract

The hierarchy does not bend

Six rules, all measured on the site before being written here. Every one of them was broken once, and the break was invisible in the source.

6 RULES
01Tokens set rhythm and color

No hard-coded width, color or duration in a component. tokens.css is the only scale.

02An asset carries one idea

Small, static first, parameterized. A metric only renders with a sourced value.

03Motion is opt-in

animated: true on the asset. The catalog picks the movement; nothing configures keyframes.

04Sections own their padding

A section carries its own padding-top. No compensation by adjacency, no rails redrawn locally.

05Templates are contracts

Order and required fields per section. Two pages of a directory read as one template.

06Content is data

Copy lives in JSON and MDX. Figures come from config/pricing.ts and the authorized KPIs.

03
Connected to the site

What each page reads

Nothing here is a copy. When a source changes, the corresponding lab page follows at the next build.

7 SOURCES
Lab pageSource files
Foundationssrc/styles/tokens.css (parsed at build), global.css, ui/*
Assetsvisual-assets/catalog.ts, icon-registry.ts, BlitzAsset.astro
Motioncatalog.ts (motion), brand-system/signature-catalog.ts, automation-recipes.json, motion/specs/**
Sectionscomponents/{product,usecase,persona,hub,sections}/*, content collections, data/pages/*
Templateslayout-system/page-templates.ts, mirror of src/pages/**
Contentcomponents/content/*, components/learn/blocks/*, layout-system/content-catalog.ts
Codehub/CodeTabs, learn/blocks/Payload, content/Endpoint, data/pages/developers.json
04
Writing rules

What every surface must respect

Checked by scripts/audit-sept.py on the built pages: forbidden terms, offer facts, SEO bounds. The lab follows the same rules.

7 RULES
  1. English (US) on every public surface, and in this lab.
  2. No em dash. A colon, a comma or a period does the job.
  3. Numbers in full: 15,000,000 results, never 15M. The unit is « result ».
  4. Only authorized KPIs: 1B+ records, 550M+ profiles, 65M+ companies, 100M+ job postings, 65M+ emails, 45M+ US phone numbers.
  5. Offer figures come from config/pricing.ts: 50 requests per second, Very high fair use, Core / Plus / Full.
  6. No accuracy percentage in the September build: quality is stated without a figure.
  7. Endpoints and field names are copied from docs.blitz-api.ai, never written « by convention ».