Core Design Principles

Every element reinforces the platform's role as the authoritative ledger for cultural property rights. These five rules are non-negotiable.

Brand & Logo

The MADE CX wordmark: solid "MADE" represents established culture, outlined "CX" in green represents exchange and future potential.

.logo-text {
    display: flex;
    align-items: baseline;
    font-family: var(--font-primary); /* Inter */
    font-size: 22px;
    font-weight: 900;
    letter-spacing: -0.01em;
}
.logo-made { color: var(--text); }
.logo-cx {
    color: transparent;
    -webkit-text-stroke: 2.5px var(--green);
    margin-left: 8px;
}

Iconography & Glyphs

All pictographic icons across MADE CX surfaces must be inline SVG. Emojis and Unicode-icon characters are not used anywhere on the platform — not in UI strings, not in toast messages, not in console output, not in placeholder labels.

Every visual icon on the platform is rendered as an inline <svg> element with stroke="currentColor" so it inherits its container's color. No icon fonts, no image sprites for UI icons, no Unicode pictographs.

Standard typographic characters are not pictographic icons and are encouraged where they improve readability:

Green (var(--green) / #00C805) is the platform's only accent color. It signals exchange, verification, and forward motion. To preserve its meaning, green is reserved for very small accents only — never as a fill, never as a state.

<!-- Standard checkmark icon -->
<svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2">
    <polyline points="20 6 9 17 4 12"/>
</svg>

<!-- Standard arrow icon -->
<svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2">
    <path d="M5 12h14M12 5l7 7-7 7"/>
</svg>

<!-- Sort chevron (replaces ↕) -->
<svg viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2">
    <path d="M7 10l5-5 5 5M7 14l5 5 5-5"/>
</svg>

Color System

Pure black and white with strategic green accent. Green is functional, never decorative. Red for negative/error states only.

Typography

Three font families with strict roles: Space Grotesk for display/headlines, Inter for body/UI, IBM Plex Mono for technical/labels.

Buttons

Buttons use var(--text) as background (black in light, white in dark). Green is ONLY for the arrow icon accent. All borders 2px. Font-weight 800.

Every button has five states. Default, hover, active, focus, disabled. Each state is structurally distinct so a user always knows what's possible. The animations are deliberate, not decorative — a button leaning forward on hover (4px arrow translate) signals "I'm ready"; the 1px inset on active signals "I received your input"; the focus ring signals "you're here, keyboard works." This is custodial UI: the system never leaves the user guessing what state they're in.

.btn {
  /* Base treatment */
  display: inline-flex;
  align-items: center;
  gap: 8px;
  padding: 12px 24px;
  font-family: var(--font-primary);
  font-size: 13px;
  font-weight: 800;
  letter-spacing: 0.1em;
  text-transform: uppercase;
  border: 2px solid var(--text);
  background: transparent;
  color: var(--text);
  cursor: pointer;
  /* Heritage Principle: every transition carries weight */
  transition: background 200ms cubic-bezier(.4,0,.2,1),
              color 200ms cubic-bezier(.4,0,.2,1),
              border-color 200ms cubic-bezier(.4,0,.2,1),
              transform 100ms ease-out;
}

.btn svg {
  width: 16px;
  height: 16px;
  color: var(--green);            /* arrow is the activation indicator */
  transition: transform 200ms cubic-bezier(.4,0,.2,1);
}

.btn-primary { background: var(--text); color: var(--bg); }

/* Hover — the button leans forward */
.btn:hover:not(:disabled) {
  background: var(--text);
  color: var(--bg);
}
.btn-primary:hover:not(:disabled) {
  background: transparent;
  color: var(--text);
}
.btn:hover:not(:disabled) svg { transform: translateX(4px); }

/* Focus — keyboard halo, no glow */
.btn:focus-visible {
  outline: 2px solid var(--text);
  outline-offset: 3px;
}

/* Active — tactile press */
.btn:active:not(:disabled) {
  transform: translateY(1px);
}
.btn:active:not(:disabled) svg { transform: translateX(2px); }

/* Disabled — unavailable, not absent */
.btn:disabled {
  opacity: 0.4;
  cursor: not-allowed;
}
.btn:disabled svg { color: var(--text-muted); }

This is a platform that handles cultural property. A click that says "Acquire License" might trigger a five-figure transaction and create a permanent on-chain record. The button needs to feel commensurate with that — confident, intentional, never accidental. The 200ms transition is slow enough that a user sees what's happening; the 4px arrow nudge is visible enough that the button reads as "ready"; the 1px press translate confirms receipt without bouncing or oversteering.

For LLMs and future devs reading this: when you build a new button variant, copy these timings exactly. The transition curve cubic-bezier(.4,0,.2,1) is Material's "standard easing" — it accelerates fast and decelerates gently, which reads as "decisive but not rushed." Do not substitute ease-in-out (too symmetrical, too "designed-feeling") or linear (mechanical). The 4px arrow translate is the canonical activation distance — not 8px (too theatrical), not 2px (too subtle to register).

Selection Groups

Radio-like option pickers where the user chooses exactly one value from 2–5 mutually exclusive options. Used for the Funding Speed picker on the Wallet, the Withdraw modal speed selector, and the Auto Top-Up “Max charges per billing period” control. The selected option uses inversion — never a green tint — per DS-canon.

• 2–5 options per group. More than 5 → use a dropdown.
• Always sharp corners (border-radius:0).
• Equal column widths via CSS Grid (grid-template-columns:repeat(N,1fr)).
• Single source of truth via aria-pressed on the active button.
• Never tint the active state green — that violates DS-canon.

Status Pills & Dots

Small accent components that communicate state without dominating the layout. This is where MADE-green legitimately appears: in 6–8px dots, in 12–16px icons inside pills, and in mono uppercase status text. These are the canonical “green as punctuation” surfaces.

A tiny circular badge for unread counts on header icons (messages, notifications). Green background, white number. Hidden when count is 0.

• Don't make pills larger than ~24px tall — they become buttons.
• Don't fill the pill background with green; the dot/icon does that job.
• Don't use red/amber pills for general status — reserve for warning/error.

Form Messages

Inline alert banners under (or alongside) a form field. Pattern: full-width box with a 4px left bar in the semantic color. Default state has a neutral left bar — never green by default. Success states are the exception where the bar is green, because the entire bar is communicating state.

• No green left bar by default. Reserve green for the explicit .success variant.
• Keep messages under 2 sentences. Long content belongs in a modal.
• One form message per field. Stacking multiple is a sign the form needs restructuring.
• For transient messages (saved confirmations, etc.), auto-dismiss after ~4 seconds.

Header Navigation

Two-tier sticky header used across every authenticated and public page. Tier 1 holds the logo, the primary tab cluster (MARKET / REGISTRY / LEDGER), and the tools cluster (search, sort, view, theme, live, volume). Tier 2 holds page-specific tools (filters, view-toggles, sort buttons) when a page needs them. Theme persists across navigation via shared localStorage.

The nav decomposes into four canonical regions: logo (flush-left), main-nav (primary tabs at margin-left: 24px), tools cluster (right side, margin-left: auto), and the optional Tier 2 page-tools strip (separated by a 1px hairline). Each element below is rendered live — what you see is the spec.

Right-aligned at margin-left: auto. Order matters — left-to-right reads as data → query → control → state. Each tool is rendered live below at production scale.

Optional second row when a page has its own filter / sort / view tools. Used by brand-dashboard (grid/list/map view-toggle), ledger (positions/orders/payment tabs), ip-asset-detail (tier-picker chrome). Separated from Tier 1 by a 1px (not 2px) border so it reads as continuous chrome, not a second nav.

The right cluster swaps between two states depending on session. Anonymous shows SIGN IN + SIGN UP; authenticated shows the user-menu (avatar + name + role). Toggle is driven by applyBuyerContextToHeader(ctx) after resolveBuyerContext() resolves the session. Sign-in URLs preserve ?return=<deep-link> so anon visitors who click an action land back on the same page after auth.

Theme state is stored under a shared key 'theme' in localStorage, not per-page. This is the contract that makes toggle persistence work across navigation — flipping to dark on Market keeps it dark on Registry, Ledger, Detail. Any new page must use the same key. A previous bug stored ledger's theme under 'made-theme'; that's deprecated and must not return.

To prevent a flash of light theme on dark-mode reload, an early synchronous script in <head> reads the persisted value and applies data-theme="dark" on <html> before the CSS renders. This script runs before <link rel="stylesheet"> resolves, so the first paint is already in the correct theme.

<script>
  // Apply persisted theme before CSS renders (prevents flash on reload).
  // Shared key 'theme' across all MADE CX pages so toggle persists on nav.
  (function () {
    try {
      var t = localStorage.getItem('theme') || 'light';
      if (t === 'dark') document.documentElement.setAttribute('data-theme', 'dark');
    } catch (e) { /* localStorage blocked — fall back to light */ }
  })();
</script>

function toggleTheme() {
  var html = document.documentElement;
  var current = html.getAttribute('data-theme');
  var next = current === 'dark' ? 'light' : 'dark';
  html.setAttribute('data-theme', next === 'dark' ? 'dark' : '');
  try { localStorage.setItem('theme', next); } catch {}
  applyThemeIcon();
}

Search reveals matches without redacting context. The canonical pattern is a dropdown panel positioned beneath the search input, populated as the user types. Selecting a result navigates to it. The main stage — the visible content the user was reading or browsing — stays unchanged the entire time. This is the opposite of "filter as you type", where keystrokes immediately collapse what the user was looking at into a narrower view.

Why dropdown over filter: filter-as-you-type breaks scanning and back-tracking. A user reading section 12 who searches for "valuation" loses 12 from view as the page collapses to a single result. The dropdown pattern preserves their position — they can scan suggestions, decide whether to navigate, or dismiss the dropdown and keep reading. This DS uses the dropdown pattern in its own header — try typing in the search field at the top right.

The search-preview-dropdown is the canonical search pattern across the platform. It applies anywhere a user might want to find something specific without losing their place:

• Registry asset search — type "Drake" → dropdown shows matching assets with thumbnails + creator names. Clicking navigates to detail page. The grid behind stays as it was.
• Ticker lookup — type "$ANG" → dropdown shows matching creators with ticker badges. Stage stays put.
• Ledger transaction history — type a registration ID → dropdown shows matching txns. The current ledger view doesn't collapse.
• Admin search — type a user email → dropdown shows matching profiles. Admin's current view stays visible.

The deprecated pattern (do NOT use): typing in a search field and having the underlying grid/list immediately collapse to only matching items. That is filter-as-you-type — appropriate for refining an active query view (e.g., a dedicated search results page where filtering IS the purpose), but never for the global header search where the user is mid-task on a different stage.

At ≤900px the nav-top padding shrinks to 10px 14px and flex-wrap: wrap lets the main-nav row drop below the logo when there's not enough horizontal room. Below 768px, the canonical pattern is to hide the inline desktop-controls + main-nav and surface a hamburger button that opens a left drawer (mirroring the .mobile-drawer from /culture-market-data.html).

The drawer is what the hamburger reveals. Below ~768px the inline tab cluster gives way to a hamburger button; tapping it slides in a left-anchored drawer that takes over navigation. The drawer follows the same philosophy as the desktop nav: structural borders, mono uppercase group labels, no decorative chrome — but trades inline horizontal compression for vertical scannability with collapsible accordion groups.

Why grouped accordion over flat list: a flat list of 17 nav links scrolls forever and gives no shape to the platform's information architecture. Grouping by category (DISCOVER / FOR CREATORS / FOR BRANDS / RESOURCES on the marketing site, FOUNDATION / COMPONENTS / TEMPLATES / CODE in the DS) lets a user jump directly to the right neighborhood, then expand only the group they need. Other groups stay collapsed so the drawer remains scannable at a glance.

The hamburger button is a state primitive, not a logo or accent. Three 2px horizontal lines, evenly spaced, in a 40×40 square with 2px var(--border). Hover bumps border to var(--text). No animation transformation into an X — the X is a separate icon inside the drawer header, not the hamburger morphing. Treat them as two distinct UI states (closed = hamburger visible, open = drawer with X visible) rather than a continuous icon transformation. This matches the structural-over-decorative principle: borders define state, not motion.

Image Standards

Professional photography with clear subjects. No text overlays. High contrast for white backgrounds.

Product Cards

Grid view cards with 4:3 image ratio. Category badge top-left, asset icon bottom-right. 2px border, hover to black.

List View & Financial Accordion

Table-style layout with expandable financial charts. Click chevron to reveal price history, projections, and stats.

Asset Detail Surfaces

Every cultural asset on the platform has two distinct detail surfaces — the Product Detail (public listing, exhibition tone) and the IP Asset Detail (trading view, market structure). They render the same underlying row from cultural_assets, but for fundamentally different audiences with fundamentally different intents — and behind different auth gates. Product Detail is public, viewable by anyone in non-auth mode (same posture as the Registry index). IP Asset Detail is verified-buyers-only, gated at page load. Same asset. Two lenses. Two flows. Two auth boundaries.

The architectural insight: the same asset can be both a venerated artifact and a tradable property without the platform having to pick one or the other. Product Detail honors the cultural dimension (heritage, ethical commitments, the act of supporting); IP Asset Detail honors the commercial dimension (tiers, market caps, options). A creator's lineage isn't compromised by being licensable; a buyer's commercial decision isn't reduced to its price tag. Both surfaces are first-class. Neither is the "primary."

The exhibition surface. A casual visitor's first encounter with a piece of cultural property. Composed as stacked tiles — Header, Product Image, Product Info, Creator Card, Action Buttons, Museum Exhibition (masonry detail cards), Stats. Treats the asset as something to be considered, not just transacted on. The two CTAs (Support and License) sit side-by-side as equally weighted paths, signaling that supporting the creator is as legitimate an outcome as licensing the work.

Side-by-side equally-weighted action buttons. Support This Creator opens the donation modal; 100% of the donation routes to the creator with no platform cut. License This Property opens the license flow (which routes to verification if the user isn't a verified buyer). Both buttons are full-width within the tile, flexed equal, with explanatory micro-copy below.

The Support button uses a filled heart icon (fill="currentColor") at currentColor — gentle, warm. The License button uses a stroked document icon — formal, transactional. The icons themselves carry the tone: gift vs. contract.

The "Property Details" section below the action buttons renders as a museum-style masonry grid. Each card carries an icon + small mono category label in its header, a title, and structured body content. The cards are not all the same size — wide cards span 2 columns, standard cards span 1. This irregularity is intentional: it reads as exhibition layout, not data table.

Clicking Support This Creator opens the donation modal. Three steps in the same modal frame, just like the license purchase modal — but the steps reflect the donation intent, not commercial transaction. Step 1: Select Amount (preset tiles like $5/$10/$25/$100 + custom input). Step 2: Select Payment Method (Stripe, Apple Pay, Google Pay — populated by JS). Step 3: Enter Details (Stripe Card Element if selected, otherwise the chosen method's form).

The 100% rule: donations route entirely to the creator. The platform takes no fee on Support transactions. This is the structural distinction from the License path — Support is generosity, License is commerce. The same modal mechanic, two different economic flows, one transparent rule.

The trading-desk surface. A verified buyer's full evaluation surface. Page-level auth gate — only verified buyers can view this surface; anonymous and unverified sessions are redirected to the verification flow before the page renders. Two-column grid: main column carries the gallery + asset metadata + collapsible registration sections + stats grid + price projection chart; side column carries the three-market structure (Primary / IP Sale / Secondary) + license tier picker + financial instruments. Sticky side column keeps the picker visible while the buyer reads the asset details.

Grid: grid-template-columns: 1.5fr 1fr; gap: 32px at desktop. Stacks at ≤960px (main column above, side column below). Sticky position on side column at desktop so the license picker stays visible while reading the asset detail.

Square aspect-ratio container. CX brand watermark floats top-right on alpha (matches the card stamp pattern). Multi-image registrations show prev/next nav arrows + image-count badge. Click expand-icon → lightbox modal. Below: thumbnails strip (one row, horizontal scroll on overflow) and an optional image-specs panel showing total / current / format.

Three collapsible regions stack below the asset header, each scoped to one type of metadata. Toggled via toggleSection(id). Section title row uses 2px border-bottom on hover; chevron rotates 180° when expanded. Inside each section, a responsive .data-grid renders Label/Value pairs at 2 columns (desktop) or 1 column (mobile).

Four stat cards in a responsive grid. Each card carries a label + value + change indicator. Stat values render in var(--text) (NOT green); change indicators carry the directional sign and may be green for positive, neutral text for null states. The All-Time High card omits the change indicator and shows the date instead.

Every cultural asset can transact in three distinct markets. The side column makes this explicit so the buyer always understands which market they're entering. The Primary market (License IP) is foregrounded as the most common path; IP Asset Sale and Secondary Trading are visible but tertiary. This is intentional — most buyers want a license, not full ownership.

Inside the Primary section, license tiers render as selectable rows. Each tier shows price, scope summary, and an inline expand for full terms. Selection updates the Total Price strip below; the Execute button stays disabled until a tier is selected, then activates and routes to handleLicensePurchase().

Clicking Execute License Purchase opens a 3-step modal. Step 1 collects the order form (use case, term, exclusivity, payment). Step 2 shows processing state with the Stripe payment intent confirmation. Step 3 shows success with receipt + ledger link. Each step replaces the previous in the same modal frame — no second modal stack. Cancel is allowed in steps 1 and 2; step 3's only action is a "View in Ledger" forward navigation.

Below the three markets, the side column surfaces partner-routed financial products. Fidelity handles options trading on cultural IP (covered calls, protective puts) for verified investors with approved options agreements. Charles Schwab handles asset-backed loans against verified IP portfolios (Pledged Asset Line, up to 50% LTV). Both buttons open the white-glove modal harness with full disclosure copy — no native browser dialogs. Disclaimer footer below references investment risk, broker-dealer relationships, and forced-liquidation possibility.

Account Settings & Wallet

The account-settings template is the canonical home for the MADE CX Wallet, the Personal Valuation Card, payout funding controls, and connect-method tiles. All wallet-and-card patterns shown elsewhere in the platform are implemented here first and referenced by ID/class.

A two-column live balance (Available / Pending) sourced from Stripe Connect via the get-wallet-balance Edge Function. Status pill shows auto-payout state. Funding-speed picker writes to payout_preference via set-payout-schedule.

Credit-card-shaped visual (1.586:1 ISO/IEC 7810 ID-1 ratio) representing the buyer's MADE CX account in physical form. Black gradient background, green accent border, four hairline corner brackets, top status bar, EMV chip + contactless icon, ticker symbol, masked PAN, cardholder name, network logo, and footer brand mark.

Two-tile radio group. Selection writes to payout_preference via set-payout-schedule and triggers re-fetch of next-payout ETA. Standard = free 1–3 day ACH; Instant = +1% Stripe Instant Payouts (~30 min).

External-service tiles for connecting third-party accounts (Stripe Connect, bank ACH, exchange APIs, social verification). Each tile is a uniform 2px-bordered cell with a leading mono service name, status copy, and a right-aligned action button (CONNECT for unlinked, MANAGE for linked, with green check). The status pattern is reused across all integration surfaces.

The account-settings template stacks tiles in a single column on a centered max-width:1100px page body, each tile separated by 32px vertical gap. Tile order (top→bottom): identity → wallet → personal valuation card → connected methods → notification preferences → security → danger zone. The same tile primitive (.tile = 2px border + 24px padding + var(--card-bg)) is the structural unit; each variant adds its own modifier class (.tile-wallet, .tile-card-promo, etc.) for content-specific layout.

Notifications, Drawers & Header Adaptation

Three platform-wide rules for header components: a single canonical notification taxonomy, a single drawer pattern, and the rule that all headers must adapt to the active theme.

Every header on the platform — including marketing pages (pricing, licensing, about, etc.) — must use the theme tokens for background, text, and borders. Hardcoded background: #000000 and color: white are not allowed in the header CSS block. Use the variables the page already defines.

Used on brand-dashboard.html and account-settings-buyer.html. The class names below are stable and shared — do not invent parallel .notif-* classes. The dropdown shows/hides via the .active class, not the [hidden] attribute.

The single canonical notifications table. All bell components query this table joined by user_email. The icon for each row maps from the icon_type column (or type, fallback) via getNotifIcon():

Always slides in from the left. Header is sticky inside the drawer. Use visibility: hidden, never display: none, while loading state is being decided so the layout doesn't shift.

State-Aware Flow Routing

Multi-step submission flows must check for existing user state before rendering the form. A buyer with an in-flight verification submission should never see the new-application form — they should be redirected to the read-only review page that surfaces their actual status.

Every gated multi-step flow runs a resolve<Entity>State() check immediately after the auth gate clears, before any form rendering. The check returns one of three outcomes:

Three rules to prevent user confusion when redirected:

• Hide the form during the check. Set visibility: hidden on the main layout while the DB query resolves. If we're not redirecting, reveal it. Prevents flicker.
• Use window.location.replace(), not .href. The back button shouldn't loop the buyer back into a redirect cycle.
• Stash a sessionStorage hint. The destination page reads the hint and shows a brief 5-second toast acknowledging the redirect (e.g., "Your application is already in review. Track its status below."). Hint must include a timestamp and be cleared on read — ignore stale hints older than 5 seconds.

Threaded Messaging — Terminal Style

Every message thread surface on MADE CX uses the same visual pattern: sharp-edged panels with mono shell-prompt headers and square avatars. The aesthetic is dev-tool, not chat-app. No rounded bubbles, no circular avatars. The pattern lives on three pages today: admin.html (admin thread view), contact.html (customer thread view, anon and authed), and dashboard.html (creator messaging). Any future messaging surface adopts this same pattern verbatim.

Each message is a flex row containing two children: a 36×36 square avatar and a max-width message card. The card has two stacked sections — a terminal prompt header and a mono body. Side alignment + accent stripe + prompt color together communicate sender role without needing a separate badge.

Whether a message renders as own/admin (right) or incoming/user (left) is determined by sender_role, the canonical column added in migration 2026-05-10e. The role is resilient to admin email renames; never use sender_email === currentUser.email comparisons. Falls back to email match only for legacy pre-migration rows that lack sender_role.

<div class="message [is-admin|is-user|own]">
  <div class="message-avatar">M</div>
  <div class="message-card">
    <div class="message-meta">
      <span class="message-prompt-sigil">$</span>
      <span class="message-author-label">cx-support</span>
      <span class="message-prompt-sep">·</span>
      <span class="message-time">2026-05-10 13:26:03</span>
    </div>
    <div class="message-body">message text here</div>
  </div>
</div>

• Round avatars. The 50% border-radius circle is the chat-app default and breaks the terminal aesthetic. Always square.
• Rounded bubble corners. No border-radius on cards. Sharp 90° corners everywhere.
• Sender labels like "MADE CX Support" or "You". Use the terminal hostname convention (cx-support, jay, you) so the prompt header reads like a real shell.
• Localized timestamps (5/10/2026, 1:26:03 PM). Use ISO-ish YYYY-MM-DD HH:MM:SS for log feel and tnum alignment.
• Mixing prose font with mono. Both header AND body use mono. Don't switch fonts.
• Side alignment without color cue. Always pair side alignment with the colored accent stripe + prompt sigil color. Side alone isn't enough for scanning.

Agentic Operations & Credits

The MADE CX Agent runs on a metered allowance system. Subscribed creators receive a monthly bundle of operations (100/mo at the Verified tier). Operations beyond that draw from paid credits, sold in three packs (25, 100, 500). Creators can enable auto top-up to charge a saved card off-session whenever the balance hits zero. Every surface in this section is a creator-facing billing UI — they live primarily in account-settings.html and licensing-opportunities.html, and route through the billing Edge Function.

The progress strip showing “X of N agentic operations used · Resets {date}”. Lives at the top of any page that consumes agent operations (licensing-opportunities, dashboard agent surface). Border is fully neutral — no green left-edge accent. State changes via full-frame border-color: amber for low, red for exhausted.

The action button at the right edge of the allowance bar. Opens the Agentic Operations Pricing modal. Pure structural styling — black border, white background, black text. Hover inverts.

Triggered by the Manage button. Shows tier cards (Free / Verified / Pro) above paid credit packs (25 / 100 / 500). Catalog is fetched from billing?action=catalog (public, apikey only), then per-user usage from billing?action=overview (best-effort with auth token). Modal opens whether or not overview succeeds — the catalog always renders.

Standalone modal for one-shot pack purchases from the Subscription tile. Self-contained (does not instantiate Supabase client) to avoid GoTrueClient hangs from multi-tab auth coordination. Reads access_token directly from localStorage using the sb-{ref}-auth-token key pattern. POSTs to billing?action=purchase and redirects to Stripe Checkout.

Enables off-session charges when credits hit zero. Two states:

• No payment method: Shows a single button — LINK MY SUBSCRIPTION CARD. Calls billing?action=link-subscription-card which self-heals: looks up the user's Stripe customer (searching by email if stripe_customer_id column is NULL), grabs the default payment method, saves it to creator_payment_method via save_payment_method RPC.
• Card linked: Shows a banner Charging VISA ····4242, an enable toggle, pack dropdown (default 25-Pack), and a max-charges button group (1 / 2 / 3 / 5 / 10) with inverted-active styling.

Selected option uses inversion (filled var(--text) bg, var(--bg) text) — NOT green tint.

A graceful resolution path when user_profiles.stripe_customer_id is NULL despite the user having an active subscription. The link-subscription-card endpoint cascades through four lookup strategies:

Tile-Pair Masonry Layout

A 2-column layout pattern where the left and right columns each pack their tiles flush, with no row-height matching between columns. Used canonically on account-settings.html to stack Subscription + Valuation Card on the left and Wallet + Stripe Connect on the right. Avoids the awkward whitespace that occurs in symmetric grids when tiles have unequal heights.

<div class="tile-pair">
  <div class="tile-pair-left">
    <div class="tile">Subscription</div>
    <div class="tile">Personal Valuation Card</div>
  </div>
  <div class="tile-pair-right">
    <div class="tile">Wallet</div>
    <div class="tile">Stripe Connect</div>
  </div>
</div>

.tile-pair {
  display: grid;
  grid-template-columns: 1fr 1fr;
  gap: 24px;
  max-width: 1400px;
  margin: 0 auto;
}
.tile-pair-left,
.tile-pair-right {
  display: flex;
  flex-direction: column;
  gap: 24px;
}
@media (max-width: 900px) {
  .tile-pair { grid-template-columns: 1fr; }
}

Notice: Tile A (120px) and Tile B (160px) have different heights. The columns pack independently — no awkward whitespace.

• 2×2 layouts where tile heights naturally differ
• Account/settings pages with grouped controls
• Dashboards with paired data widgets

• Symmetric layouts where rows must align (use CSS Grid auto-rows instead)
• 3+ column layouts (use a true masonry library)
• When tile order matters across columns (this layout reads top-to-bottom per column, not left-to-right)

MADE CX Agent Thread

The MADE CX Agent is the creator's autonomous representative inside the platform. It lives as a pinned thread at the top of the messaging drawer — accessible from the messages icon in every creator-facing page header. Each message exchange consumes one agentic operation from the creator's monthly allowance (or one paid credit if the allowance is exhausted).

When opened, the agent thread uses terminal-style message blocks: mono typography, sharp borders, timestamps on every entry. 12-hour clock format. Each agent response is preceded by a small “thinking” indicator while the LLM call is in flight.

UI Patterns

Common patterns: section headers, pull quotes, stats, layer diagrams, form elements, badges, and icons.

Modals are conversations, not interruptions. The platform handles licensing decisions worth thousands of dollars; modal interactions need to feel commensurate with that. White-glove means: titled, considered, dismissable on the user's terms, never auto-closed mid-read, never ambient-lit by browser default chrome. Every modal has a backdrop, a centered card with sharp 2px border, an unambiguous title, body content, and a deliberate action row. Nothing more, nothing less.

Toasts confirm without blocking. Used for ambient confirmations: "Saved." "Payment received." "Verification submitted." A toast slides in from the bottom-right, sits for 4 seconds, then exits unless the user dismisses it. Never used for critical info — if a user must see it, use a modal.

// Promise-based — await the user's decision instead of a callback pyramid
async function wgConfirm(title, body, opts = {}) {
  return new Promise((resolve) => {
    const modal = buildModal({
      label: opts.label || 'Confirm',
      title,
      body,
      destructive: !!opts.destructive,
      actions: [
        { kind: 'ghost', text: 'Cancel', onClick: () => { close(); resolve(false); } },
        { kind: 'primary', text: opts.confirmText || 'Confirm',
          onClick: () => { close(); resolve(true); } }
      ]
    });
    open(modal);
  });
}

// Usage — replaces window.confirm, theme-respectful, testable
const ok = await wgConfirm(
  'Confirm acquisition',
  'You\'re about to acquire a Tier-2 Commercial license for $24,500.',
  { confirmText: 'Confirm Acquisition' }
);
if (ok) await acquireLicense(asset.id);

// Toast for ambient confirmations — never blocks
wgSuccess('License confirmed', '"In My Mind" — Tier 2 Commercial');
wgError('Payment declined', 'Card on file expired — update method');
wgInfo('Verification submitted', 'Review in 1–2 business days');

For LLMs and devs: if you find yourself reaching for alert, confirm, or prompt while writing platform code, stop and use the wg* helpers. If they don't yet exist on the page you're working on, copy them from /account-settings.html. There is no situation in this platform where a native browser dialog is the right answer.

White-Glove Dialogs — MADEDialog

Native browser dialogs (alert(), confirm(), prompt()) are banned across the MADE CX product. They break the editorial aesthetic with browser-chrome styling, can't be themed for dark mode, and feel cheap. Every confirmation, error, and prompt routes through the MADEDialog module: a sharp-corner, mono-typeset, framed modal that matches the rest of the product.

Every alert/confirm call passes a variant string that styles the icon and border. Default is 'info'.

Edge functions return machine-readable error codes (no_subscription, no_payment_method, no_email, etc.). The UI maps these to human-readable messages before showing the dialog — never expose raw error codes as the primary message. Raw codes belong in the detail field.

Anti-Patterns — Never Do These

A concise reference of design and engineering decisions that violate the MADE CX standard. If you spot any of these in code review, flag them — they're either holdovers from prototype phases or shortcuts that compound into incoherence. Each one has been deliberated and rejected; do not relitigate without a strong case.

Self-Contained Modal Pattern

An engineering pattern for modals that must work even when the page's primary Supabase client is hanging or compromised. Used in Buy More Credits, Auto Top-Up, and the Agentic Operations Pricing modal. The modal bypasses supabase.createClient() entirely and reads auth tokens directly from localStorage, hitting Edge Functions via plain fetch().

1. Find the auth token in localStorage. Supabase stores it under a key matching sb-{ref}-auth-token. Iterate localStorage.key(i), match the pattern, parse JSON, extract access_token.
2. Fetch with plain fetch(). No supabase client. Two headers: apikey (anon key, public) and Authorization: Bearer {access_token} (auth, only when needed).
3. Graceful degradation. Public catalog data fetches first with apikey only — always succeeds. User-specific overview fetches second with auth — best-effort. If overview fails, the modal still renders with the catalog.

async function openSelfContainedModal() {
  const cfg = window.MADE_CONFIG || window.APP_CONFIG || {};
  if (!cfg.SUPABASE_URL || !cfg.SUPABASE_ANON_KEY) {
    body.innerHTML = '<div class="pricing-error">Config missing</div>';
    return;
  }

  // Step 1: Find auth token in localStorage
  let accessToken = null;
  for (let i = 0; i < localStorage.length; i++) {
    const k = localStorage.key(i);
    if (k && k.startsWith('sb-') && k.includes('-auth-token')) {
      try {
        const stored = JSON.parse(localStorage.getItem(k));
        accessToken = stored && stored.access_token;
        if (accessToken) break;
      } catch (_) {}
    }
  }

  // Step 2: Public fetch (always works)
  const catRes = await fetch(
    cfg.SUPABASE_URL + '/functions/v1/billing?action=catalog',
    { headers: { apikey: cfg.SUPABASE_ANON_KEY } }
  );
  const catalog = await catRes.json();

  // Step 3: Auth'd fetch (best-effort)
  let usage = {};
  if (accessToken) {
    try {
      const ovRes = await fetch(
        cfg.SUPABASE_URL + '/functions/v1/billing?action=overview',
        {
          headers: {
            apikey: cfg.SUPABASE_ANON_KEY,
            Authorization: 'Bearer ' + accessToken,
          }
        }
      );
      const overview = await ovRes.json();
      if (ovRes.ok && overview.usage) usage = overview.usage;
    } catch (_) { /* fall through with empty usage */ }
  }

  renderModal(catalog, usage);
}

When a page has multiple <script> blocks (e.g. one type="module" and one classic script), helper functions don't cross scope. Modals that live in the bottom script must re-declare their own local esc(), fmtDate(), etc. — copying the implementation is acceptable here; the symptom of forgetting is a silent ReferenceError caught by the modal's try/catch and rendered as “Could not load … : esc is not defined”.

• Modals triggered after the page has been open for a while (when GoTrueClient may have drifted)
• Modals that need to work in incognito / multi-tab scenarios
• Any modal where a loading hang is unrecoverable (no retry UX)

• Page-load data fetches — those should use the normal supabase client
• Real-time subscriptions — those require the client's websocket infrastructure
• Anything that needs RLS policies to be enforced via the client (they're enforced server-side here anyway)

Spacing System

4px base unit. Structure over decoration.

Email Templates

9 production-ready transactional emails triggered by database events. All follow the Culture Exchange Standard: table-based layout, 600px max-width, inline CSS, cross-client compatible.

[First Name]           — User's first name
[PROPERTY_NAME]        — Creative property title
[BCID_NUMBER]          — Blackchain Creative ID
[SUBMISSION_ID]        — Registration submission ID
[CCA_ID]               — Creator Creditor Agreement ID
[LIEN_ID]              — Cultural Lien reference number
[LICENSE_ID]           — Cultural Use License number
[BRAND_NAME]           — Brand/company name
[Brand Contact Name]   — Brand contact person
[DATE_TIME]            — Formatted timestamp
[REVIEWER_NOTES_HERE]  — Admin notes for rejections
[RESUBMIT_URL]         — Link to edit submission
[SUBMISSION_URL]       — New submission link
[LEDGER_URL]           — Public ledger entry
[PROPERTY_URL]         — Product detail page
[CERTIFICATE_PDF_URL]  — Certificate download
[DASHBOARD_URL]        — Dashboard link
[PORTAL_URL]           — Creator portal link
[SHARE_IG]             — Instagram share
[SHARE_TIKTOK]         — TikTok share
[SHARE_X]              — X/Twitter share
[SHARE_LINKEDIN]       — LinkedIn share

CREATE TABLE IF NOT EXISTS email_queue (
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    to_email TEXT NOT NULL,
    to_name TEXT,
    subject TEXT NOT NULL,
    html_content TEXT NOT NULL,
    email_type TEXT NOT NULL,
    user_id UUID REFERENCES auth.users(id),
    created_at TIMESTAMPTZ DEFAULT NOW(),
    sent_at TIMESTAMPTZ,
    error_message TEXT
);

CREATE OR REPLACE FUNCTION queue_registration_approved_email()
RETURNS TRIGGER AS $
BEGIN
    IF NEW.status IN ('approved', 'verified')
       AND (OLD.status IS NULL
            OR OLD.status NOT IN ('approved', 'verified'))
    THEN
        INSERT INTO email_queue (
            to_email, to_name, subject,
            html_content, email_type, user_id
        )
        SELECT
            NEW.email,
            NEW.business_name,
            'Your Creative Property Is Now Protected',
            replace(
              replace(
                replace(template_html,
                  '[First Name]', COALESCE(NEW.first_name, 'there')),
                '[PROPERTY_NAME]', NEW.item_name),
              '[BCID_NUMBER]', NEW.registration_id),
            'registration_approved',
            NEW.auth_user_id;
    END IF;
    RETURN NEW;
END;
$ LANGUAGE plpgsql;

-- Attach trigger
CREATE TRIGGER trigger_registration_approved_email
    AFTER UPDATE OF status ON registrations
    FOR EACH ROW
    EXECUTE FUNCTION queue_registration_approved_email();

-- TRIGGER MAP: Action → Function → Table
--
-- 01  Brand onboarding complete    → queue_brand_welcome_email()
--     ON users AFTER UPDATE OF onboarding_completed
--
-- 02  Registration approved        → queue_registration_approved_email()
--     ON registrations AFTER UPDATE OF status
--
-- 03  Registration needs info      → queue_registration_needs_info_email()
--     ON registrations AFTER UPDATE OF status
--
-- 04  Royalties enabled            → queue_royalties_enabled_email()
--     ON registrations AFTER UPDATE OF royalties_enabled
--
-- 05  CCA signed                   → queue_cca_confirmed_email()
--     ON creator_creditor_agreements AFTER INSERT
--
-- 06  Registration submitted       → queue_registration_under_review_email()
--     ON registrations AFTER INSERT
--
-- 07  Cultural lien filed          → queue_cultural_lien_filed_email()
--     ON cultural_liens AFTER INSERT
--
-- 08  Brand registration approved  → queue_brand_registration_confirmed_email()
--     ON registrations AFTER UPDATE OF status (user_type='brand')
--
-- 09  Brand license approved       → queue_brand_license_approved_email()
--     ON cultural_use_licenses AFTER UPDATE OF status

// supabase/functions/process-email-queue/index.ts
import { serve } from 'https://deno.land/std/http/server.ts';
import { createClient } from 'https://esm.sh/@supabase/supabase-js';

const RESEND_API_KEY = Deno.env.get('RESEND_API_KEY')!;
const SUPABASE_URL = Deno.env.get('SUPABASE_URL')!;
const SUPABASE_KEY = Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!;

serve(async () => {
  const supabase = createClient(SUPABASE_URL, SUPABASE_KEY);

  // Fetch pending emails
  const { data: emails } = await supabase
    .from('email_queue')
    .select('*')
    .is('sent_at', null)
    .is('error_message', null)
    .order('created_at')
    .limit(10);

  if (!emails?.length) return new Response('No emails to send');

  for (const email of emails) {
    try {
      const res = await fetch('https://api.resend.com/emails', {
        method: 'POST',
        headers: {
          'Authorization': `Bearer ${RESEND_API_KEY}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          from: 'MADECX <[email protected]>',
          to: email.to_email,
          subject: email.subject,
          html: email.html_content,
        }),
      });

      if (res.ok) {
        await supabase.from('email_queue')
          .update({ sent_at: new Date().toISOString() })
          .eq('id', email.id);
      } else {
        const err = await res.text();
        await supabase.from('email_queue')
          .update({ error_message: err })
          .eq('id', email.id);
      }
    } catch (e) {
      await supabase.from('email_queue')
        .update({ error_message: e.message })
        .eq('id', email.id);
    }
  }

  return new Response(`Processed ${emails.length} emails`);
});

React Component Library

Production-ready TSX components for the React platform team. Copy these files into your project or download the complete package below.

# 1. Copy the design-system/ folder into your project
# 2. Import tokens in your root layout:
import '@/design-system/tokens.css'

# 3. Import components:
import { Button, Card, Badge, Logo } from '@/design-system/components'

/* MADE CX Design Tokens — v3.2 */
@import url('https://fonts.googleapis.com/css2?family=Inter:wght@300;400;500;600;700;800;900&family=Space+Grotesk:wght@400;500;600;700;800;900&family=IBM+Plex+Mono:wght@400;500;600;700;800&display=swap');

:root {
  --black: #000000;
  --white: #FFFFFF;
  --gray-50: #FAFAFA; --gray-100: #F5F5F5; --gray-200: #E5E5E5;
  --gray-300: #D4D4D4; --gray-400: #A3A3A3; --gray-500: #737373;
  --gray-600: #525252; --gray-700: #404040; --gray-800: #262626;
  --gray-900: #171717;
  --green: #00C805; --green-light: #00E806; --green-dark: #00A804;
  --red: #EF4444;
  --bg: var(--white); --bg-alt: var(--gray-100); --bg-tertiary: var(--gray-50);
  --text: var(--black); --text-secondary: var(--gray-600); --text-muted: var(--gray-500);
  --border: var(--gray-200); --card-bg: var(--white);
  --font-primary: 'Inter', -apple-system, sans-serif;
  --font-display: 'Space Grotesk', sans-serif;
  --font-mono: 'IBM Plex Mono', 'Monaco', monospace;
}
[data-theme="dark"] {
  --bg: var(--black); --bg-alt: var(--gray-900); --bg-tertiary: var(--gray-800);
  --text: var(--white); --text-secondary: var(--gray-400); --text-muted: var(--gray-600);
  --border: var(--gray-800); --card-bg: var(--gray-900);
}
*, *::before, *::after { margin: 0; padding: 0; box-sizing: border-box; }
::selection { background: var(--green); color: var(--black); }

import React from 'react';

interface LogoProps {
  size?: 'sm' | 'md' | 'lg';
  className?: string;
}

const sizes = { sm: '18px', md: '22px', lg: '40px' };
const strokes = { sm: '2px', md: '2.5px', lg: '3px' };

export const Logo: React.FC<LogoProps> = ({ size = 'md', className }) => (
  <span
    className={className}
    style={{
      display: 'flex',
      alignItems: 'baseline',
      fontSize: sizes[size],
      fontWeight: 900,
      letterSpacing: '-0.01em',
      lineHeight: 1,
      fontFamily: 'var(--font-primary)',
    }}
  >
    <span style={{ color: 'var(--text)' }}>MADE</span>
    <span
      style={{
        color: 'transparent',
        WebkitTextStroke: `${strokes[size]} var(--green)`,
        marginLeft: '8px',
      }}
    >
      CX
    </span>
  </span>
);

import React from 'react';

interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  variant?: 'primary' | 'secondary' | 'ghost';
  size?: 'sm' | 'default' | 'lg';
  showArrow?: boolean;
  children: React.ReactNode;
}

const Arrow = () => (
  <svg width="16" height="16" viewBox="0 0 24 24"
    fill="none" stroke="currentColor" strokeWidth="2"
    style={{ color: 'var(--green)', transition: 'transform 0.2s' }}>
    <path d="M5 12h14M12 5l7 7-7 7" />
  </svg>
);

const sizeStyles = {
  sm:      { padding: '8px 16px',  fontSize: '12px' },
  default: { padding: '16px 32px', fontSize: '14px' },
  lg:      { padding: '20px 40px', fontSize: '16px' },
};

const variantStyles = {
  primary:   { background: 'var(--text)', color: 'var(--bg)', borderColor: 'var(--text)' },
  secondary: { background: 'transparent', color: 'var(--text)', borderColor: 'var(--text)' },
  ghost:     { background: 'transparent', color: 'var(--text)', borderColor: 'transparent' },
};

export const Button: React.FC<ButtonProps> = ({
  variant = 'primary', size = 'default', showArrow = true,
  children, style, ...props
}) => (
  <button
    {...props}
    style={{
      display: 'inline-flex', alignItems: 'center', gap: '12px',
      fontFamily: 'var(--font-primary)', fontWeight: 800,
      textTransform: 'uppercase', letterSpacing: '0.1em',
      border: '2px solid', cursor: 'pointer', transition: 'all 0.2s',
      textDecoration: 'none',
      ...sizeStyles[size], ...variantStyles[variant], ...style,
    }}
  >
    {children}
    {showArrow && <Arrow />}
  </button>
);

import React from 'react';

interface ProductCardProps {
  image?: string;
  category: string;
  assetType: string;
  name: string;
  creator: string;
  tag?: string;
  verifiedDate?: string;
  onClick?: () => void;
}

export const ProductCard: React.FC<ProductCardProps> = ({
  image, category, assetType, name, creator, tag, verifiedDate, onClick,
}) => (
  <div onClick={onClick} style={{
    background: 'var(--card-bg)', border: '2px solid var(--border)',
    cursor: 'pointer', transition: 'border-color 0.2s',
    display: 'flex', flexDirection: 'column',
  }}>
    {/* Image */}
    <div style={{ position: 'relative', width: '100%', aspectRatio: '4/3',
      overflow: 'hidden', background: 'var(--bg-alt)' }}>
      {image
        ? <img src={image} alt={name}
            style={{ width: '100%', height: '100%', objectFit: 'cover' }} />
        : <div style={{ width: '100%', height: '100%', display: 'flex',
            alignItems: 'center', justifyContent: 'center' }}>
            <PlaceholderIcon />
          </div>
      }
      <span style={{
        position: 'absolute', top: 16, left: 16, padding: '6px 12px',
        border: '2px solid var(--black)', fontFamily: 'var(--font-mono)',
        fontSize: '11px', fontWeight: 800, textTransform: 'uppercase',
        letterSpacing: '0.15em',
      }}>{category}</span>
    </div>

    {/* Content */}
    <div style={{ padding: 20 }}>
      <div style={{ fontFamily: 'var(--font-mono)', fontSize: '11px',
        fontWeight: 800, textTransform: 'uppercase', letterSpacing: '0.15em',
        color: 'var(--green)', marginBottom: 8 }}>{assetType}</div>
      <h3 style={{ fontFamily: 'var(--font-display)', fontSize: '20px',
        fontWeight: 900, margin: '0 0 8px', lineHeight: 1.2 }}>{name}</h3>
      <p style={{ fontSize: '14px', color: 'var(--text-muted)',
        margin: '0 0 16px' }}>{creator}</p>
      {tag && <span style={{ display: 'inline-block', padding: '6px 12px',
        border: '1px solid var(--border)', fontFamily: 'var(--font-mono)',
        fontSize: '10px', fontWeight: 700, textTransform: 'uppercase',
        letterSpacing: '0.1em', color: 'var(--text-secondary)' }}>{tag}</span>}
      {verifiedDate && (
        <div style={{ display: 'flex', justifyContent: 'space-between',
          marginTop: 20, paddingTop: 16,
          borderTop: '1px solid var(--border)' }}>
          <span style={{ fontFamily: 'var(--font-mono)', fontSize: '11px',
            fontWeight: 600, textTransform: 'uppercase', letterSpacing: '0.1em',
            color: 'var(--text-muted)' }}>{verifiedDate}</span>
          <span style={{ fontFamily: 'var(--font-mono)', fontSize: '11px',
            fontWeight: 800, textTransform: 'uppercase', letterSpacing: '0.1em',
            display: 'flex', alignItems: 'center', gap: 6 }}>
            <CheckIcon /> Asset
          </span>
        </div>
      )}
    </div>
  </div>
);

const PlaceholderIcon = () => (
  <svg width="48" height="48" viewBox="0 0 24 24" fill="none"
    stroke="currentColor" strokeWidth="1.5" style={{ opacity: 0.4 }}>
    <rect x="3" y="3" width="18" height="18" />
    <circle cx="8.5" cy="8.5" r="1.5" />
    <path d="M21 15l-5-5L5 21" />
  </svg>
);

const CheckIcon = () => (
  <svg width="12" height="12" viewBox="0 0 24 24"
    fill="var(--green)" stroke="none">
    <path d="M9 16.17L4.83 12l-1.42 1.41L9 19 21 7l-1.41-1.41z" />
  </svg>
);

import React from 'react';

interface BadgeProps {
  variant?: 'default' | 'outline';
  children: React.ReactNode;
}

export const Badge: React.FC<BadgeProps> = ({ variant = 'default', children }) => (
  <span style={{
    display: 'inline-flex', alignItems: 'center', gap: '8px',
    padding: '8px 16px', fontFamily: 'var(--font-mono)',
    fontSize: '11px', fontWeight: 800, textTransform: 'uppercase',
    letterSpacing: '0.15em',
    background: variant === 'outline' ? 'transparent' : 'var(--bg-alt)',
    border: `2px solid ${variant === 'outline' ? 'var(--text)' : 'var(--border)'}`,
  }}>
    {children}
  </span>
);

import React from 'react';

interface SectionLabelProps {
  children: React.ReactNode;
  centered?: boolean;
}

export const SectionLabel: React.FC<SectionLabelProps> = ({
  children, centered = false,
}) => (
  <div style={{
    fontFamily: 'var(--font-mono)', fontSize: '11px', fontWeight: 800,
    textTransform: 'uppercase', letterSpacing: '0.15em', color: 'var(--green)',
    display: 'flex', alignItems: 'center', gap: '12px',
    justifyContent: centered ? 'center' : 'flex-start',
    marginBottom: '12px',
  }}>
    <span style={{ width: 40, height: 2, background: 'var(--green)' }} />
    {children}
    {centered &&
      <span style={{ width: 40, height: 2, background: 'var(--green)' }} />}
  </div>
);

export { Logo } from './Logo';
export { Button } from './Button';
export { ProductCard } from './ProductCard';
export { Badge } from './Badge';
export { SectionLabel } from './SectionLabel';

design-system/
├── tokens.css                  # CSS custom properties + fonts
├── components/
│   ├── index.ts                # Barrel export
│   ├── Logo.tsx                # Logo wordmark
│   ├── Button.tsx              # Primary / Secondary / Ghost
│   ├── ProductCard.tsx         # Grid view product card
│   ├── Badge.tsx               # Default / Outline badges
│   └── SectionLabel.tsx        # Green accent label
└── assets/
    ├── madecx-logo-light.svg   # Logo on white
    ├── madecx-logo-dark.svg    # Logo on black
    ├── [email protected]
    └── [email protected]

import '@/design-system/tokens.css';
import { Logo, Button, ProductCard, Badge, SectionLabel } from '@/design-system/components';

export default function RegistryPage() {
  return (
    <main>
      <header style={{ display: 'flex', justifyContent: 'space-between',
        padding: '0 40px', height: 72, alignItems: 'center',
        borderBottom: '2px solid var(--border)' }}>
        <Logo size="md" />
        <Button variant="primary" size="default">Register Asset</Button>
      </header>

      <section style={{ padding: '80px 40px', maxWidth: 1200, margin: '0 auto' }}>
        <SectionLabel>Cultural Registry</SectionLabel>
        <h2 style={{ fontFamily: 'var(--font-display)', fontSize: 48,
          fontWeight: 900, letterSpacing: '-0.02em' }}>
          Browse Assets
        </h2>

        <div style={{ display: 'flex', gap: 12, margin: '32px 0' }}>
          <Badge>All</Badge>
          <Badge variant="outline">Music</Badge>
          <Badge variant="outline">Fashion</Badge>
        </div>

        <div style={{ display: 'grid',
          gridTemplateColumns: 'repeat(auto-fill, minmax(340px, 1fr))',
          gap: 24 }}>
          <ProductCard
            category="Product"
            assetType="Product"
            name="When I Get Home"
            creator="Solange Knowles"
            tag="Uncategorized"
            verifiedDate="Verified Jan 2026"
          />
          <ProductCard
            category="Service"
            assetType="Service"
            name="Beat Production Pack"
            creator="ATL Sound Labs"
            tag="Music"
            verifiedDate="Verified Dec 2025"
          />
        </div>
      </section>
    </main>
  );
}

Cultural Valuation Math

The mathematical layer underneath the Culture Market Grid, the registry detail page, and the eventual ticker pricing surfaces. Every cultural signal carries a CPRS score (0–100), a tier classification (1–5), a TCPMV dollar value, and a confidence rating (0.0–1.0). This section documents the formulas, conventions, and visual primitives used to render these values. Auditability is the goal: anyone reading a score on a card should be able to trace it back to the formula here.

Five-dimensional composite. Each dimension is independently scored 0–100 by upstream signal classifiers; the displayed CPRS is the mean of populated dimensions. The five-dim shape is intentional — it lets a viewer read a score's fingerprint at a glance, not just its magnitude.

function cprsScore(dims) {
  // dims is [d1, d2, d3, d4, d5] — values 0..100, or 0 for "not yet scored"
  const valid = dims.filter(d => d > 0);
  if (valid.length === 0) return 0;
  return parseFloat((valid.reduce((s, d) => s + d, 0) / valid.length).toFixed(1));
}

Why mean-of-valid rather than weighted sum: early signals often have only 2–3 dimensions populated. Averaging only the populated dimensions lets a partial-data signal still produce a meaningful score without zero-padding distortion. As more dimensions fill in, the score self-stabilizes. A weighted formula was rejected because dimension importance varies by signal type — a transaction signal weights d2 (commercial) heavily; a heritage piece weights d1 (origin). Tier-1 thresholds work better against the mean.

CPRS scores collapse to tier labels for plain-language surfacing. Tiers drive UI affordances (Tier-1 unlocks priority listings, Tier-4 routes to the early-stage feed, Tier-5 is hidden from buyer-facing surfaces).

function cprsTier(score) {
  if (score >= 80) return 'TIER 1 PREMIUM CULTURAL ASSET';
  if (score >= 60) return 'TIER 2 COMMERCIAL CULTURAL ASSET';
  if (score >= 40) return 'TIER 3 EMERGING CULTURAL ASSET';
  if (score >= 20) return 'TIER 4 EARLY-STAGE CULTURAL SIGNAL';
  return 'TIER 5 UNSCORED';
}

The dollar value of a cultural property when fully exploited across primary + secondary markets. Surfaces as the headline number on registry detail pages, the green stat on registered registry cards, and the running tally in the Culture Market Grid stat bar. The actual computation lives upstream (data pipeline / valuation models); the frontend renders the stored result. This section documents only the render conventions.

Reliability of the CPRS score itself, not the underlying signal. A 0.45 confidence on an 82 score means "we're computing 82 from limited data — treat with care." Surfaces as a small mono indicator next to the score on list/detail surfaces; hidden on space-constrained grid cards.

Five thin segments rendered side-by-side, each filled to a percentage matching its dimension's score. Becomes a visual fingerprint — at-a-glance you can tell whether a signal is "high-origin, low-velocity" (heritage piece), "low-origin, high-velocity" (viral moment without lineage), or fully balanced (Tier-1 candidate).

Permitted green usage: the dim bar fill uses var(--green) for high-tier dimensions. This is an explicit exception to the "green is functional only" principle (section 03) — the dim bar is a verified-status visualization (per-dimension score validity), which the principle permits. Future contributors should not "fix" this back to neutral colors.

.list-dims { display: flex; gap: 2px; margin-top: 3px; }
.list-dims .list-dim { flex: 1; height: 2px; background: var(--bg-alt); position: relative; }
.list-dims .list-dim-fill { position: absolute; top: 0; left: 0; height: 100%; }
.list-dim-fill.high { background: var(--green); }    /* ≥ 60 */
.list-dim-fill.mid  { background: var(--text); }     /* 30..59 */
.list-dim-fill.low  { background: var(--text-muted); } /* < 30 */

function dimClass(val) {
  if (val >= 60) return 'high';
  if (val >= 30) return 'mid';
  return 'low';
}

Five stages turn a raw cultural signal into a commercial license price. Each stage is computed by a different layer of the platform and persisted to the source row. By the time the score reaches a buyer's screen, every value upstream is auditable.

Walking the same album through every stage. This is the canonical instructional asset — used everywhere in the DS to demonstrate the math. The numbers below are illustrative but typed to a real-feeling cultural property at the upper edge of Tier 1.

What each tier actually means in commercial terms. The tier number is the buyer's first read on access, pricing, and exclusivity. The TCPMV is the upstream economic estimate; the license band is the typical buyer-facing price range. Both are anchored to the CPRS score, not invented per-deal.

For LLMs and devs: when surfacing a license price on screen, never compute it client-side from CPRS. Read the tier band from tcpmv_numeric + tier on the source row. The mapping above is illustrative — the real bands live in /culture-market-data.html and may shift as the market matures.

Two assets with the same CPRS can have wildly different commercial profiles. The 5-dim fingerprint reveals what kind of asset you're looking at — not just how good it scores. A balanced asset and a spike-shaped asset behave differently in licensing, even at the same tier. This is why the dim bars exist at all: the magnitude alone is incomplete.

Same tier, very different commercial conversation. The CPRS score tells the buyer "what level," the fingerprint tells them "what kind." Designs that hide the fingerprint behind a single number flatten this — every surface that shows CPRS should show the dim bars too, or link to them.

Confidence is independent of CPRS magnitude. A score of 79 with confidence 0.40 is not the same product as a score of 79 with confidence 0.92, even though both render the same number. Confidence answers "how much classifier evidence underpins this score?" — and it directly affects how aggressively a buyer should act on the price.

The principle: a score is information; a score with confidence is information with epistemics. Designs that surface CPRS without rendering confidence treatment are quietly lying to the buyer about the score's reliability — and exposing the platform to mispriced licensing.

• Culture Market Grid (section 17, forthcoming) — every cell shows CPRS score, dim bars, TCPMV, confidence, tier badge
• Registry detail page (section 09) — TCPMV is the headline number; CPRS + dim bars on the right column
• Registry cards (section 07) — TCPMV in the verified row when present; full CPRS hidden by default
• Personal Valuation Card (section 10) — eventual surface for creator-level CPRS rollups (post-ticker launch)
• Ticker pages (section 18, forthcoming) — per-creator CPRS aggregate computed across all owned/licensed registrations
• Admin signals dashboard — full dim breakdown + raw classifier outputs for ops review

Design Tokens

Complete CSS custom properties. Copy into any project to implement the MADE CX design system.

:root {
    /* ── Primary Colors ── */
    --black: #000000;
    --white: #FFFFFF;

    /* ── Gray Scale ── */
    --gray-50:  #FAFAFA;
    --gray-100: #F5F5F5;
    --gray-200: #E5E5E5;
    --gray-300: #D4D4D4;
    --gray-400: #A3A3A3;
    --gray-500: #737373;
    --gray-600: #525252;
    --gray-700: #404040;
    --gray-800: #262626;
    --gray-900: #171717;

    /* ── Accent — FUNCTIONAL ONLY ── */
    --green: #00C805;
    --green-light: #00E806;
    --green-dark: #00A804;
    --red: #EF4444;

    /* ── Theme (Light) ── */
    --bg: var(--white);
    --bg-alt: var(--gray-100);
    --bg-tertiary: var(--gray-50);
    --text: var(--black);
    --text-secondary: var(--gray-600);
    --text-muted: var(--gray-500);
    --border: var(--gray-200);
    --card-bg: var(--white);

    /* ── Typography ── */
    --font-primary: 'Inter', -apple-system, sans-serif;
    --font-display: 'Space Grotesk', sans-serif;
    --font-mono: 'IBM Plex Mono', 'Monaco', monospace;

    /* ── Spacing (4px base) ── */
    --space-1: 4px;   --space-2: 8px;
    --space-3: 12px;  --space-4: 16px;
    --space-6: 24px;  --space-8: 32px;
    --space-10: 40px; --space-12: 48px;
    --space-16: 64px; --space-20: 80px;

    /* ── Borders — Always 2px, sharp ── */
    --border-width: 2px;
    --border-color: var(--gray-200);
}

/* ── Dark Mode ── */
[data-theme="dark"] {
    --bg: var(--black);
    --bg-alt: var(--gray-900);
    --bg-tertiary: var(--gray-800);
    --text: var(--white);
    --text-secondary: var(--gray-400);
    --text-muted: var(--gray-600);
    --border: var(--gray-800);
    --card-bg: var(--gray-900);
    --border-color: var(--gray-800);
}