diff --git a/packages/blade-core/src/styles/Button/button.module.css b/packages/blade-core/src/styles/Button/button.module.css
index 260284568ae..adc658ff85d 100644
--- a/packages/blade-core/src/styles/Button/button.module.css
+++ b/packages/blade-core/src/styles/Button/button.module.css
@@ -8,7 +8,19 @@
   outline: none;
   text-decoration: none;
   overflow: hidden;
-  border-radius: var(--border-radius-small);
+  /*
+   * Instance-level styling seam (Option B). `--btn-radius` defaults to the
+   * existing token so unspecified instances render pixel-identical; a per-instance
+   * styleOverride sets `--btn-radius` inline to override just this button.
+   */
+  border-radius: var(--btn-radius, var(--border-radius-small));
+  /*
+   * Content color seam. When a `textColor` override is present the component sets
+   * `--btn-content-color` and passes `color="currentColor"` to the text/icon, which
+   * then inherit this value. Defaults to `inherit` so without an override the
+   * token-class color on the text/icon is unaffected.
+   */
+  color: var(--btn-content-color, inherit);
   transition-property: background-color, background-image, box-shadow;
   transition-timing-function: var(--easing-standard);
   transition-duration: var(--duration-xquick);
@@ -66,7 +78,8 @@
 .large {
   --btn-gradient-size: 72px;
   min-height: 48px;
-  border-radius: var(--border-radius-medium);
+  /* Large's larger default radius, still overridable via `--btn-radius`. */
+  border-radius: var(--btn-radius, var(--border-radius-medium));
   padding-left: var(--spacing-5);
   padding-right: var(--spacing-5);
   padding-top: 0;
diff --git a/packages/blade-core/src/styles/Button/buttonOverrides.ts b/packages/blade-core/src/styles/Button/buttonOverrides.ts
new file mode 100644
index 00000000000..648add6c38d
--- /dev/null
+++ b/packages/blade-core/src/styles/Button/buttonOverrides.ts
@@ -0,0 +1,115 @@
+import { deriveColorStates, isOverrideColorValue } from '../../utils/colorOverrides';
+
+/**
+ * ## Option B — `styleOverrides` → element-scoped CSS variables (recommended core)
+ *
+ * The Button CSS module is already parameterized by element-scoped custom
+ * properties (`--btn-accent-bg-default/highlighted/disabled`, `--btn-content-color`,
+ * `--btn-radius`). `resolveButtonOverrides` maps a bounded, typed override object
+ * onto exactly those variables and *derives* the interaction states the consumer
+ * never sends (the centerpiece of v1 — see instance-level-styling-proposal §4
+ * Option B and §7).
+ *
+ * Because the override feeds the *same* variables the `:hover` / `:active` /
+ * `:focus-visible` / `[disabled]` rules already read, state variants keep working —
+ * making this a strict improvement over the flat-inline-style Option A.
+ *
+ * `blade-core` stays framework-agnostic: this is a pure function returning a
+ * `Record<cssVarName, value>`. The Svelte (or future React) layer just spreads
+ * the result onto the element's `style`.
+ *
+ * **v1 vocabulary is an opaque hex passthrough.** Values are emitted to CSS as-is;
+ * no token validation happens here (sanitization stays in the consumer). Token
+ * support / explicit per-state keys are a later-phase extension of this same
+ * resolver (proposal §7 "Later phases").
+ */
+export type ButtonStyleOverrides = Partial<{
+  /**
+   * Base background color (an opaque CSS color string, e.g. a 6-digit hex from
+   * checkout's `getUIConfigColor`). Hover/active/focus and disabled backgrounds
+   * are derived from this automatically.
+   */
+  backgroundColor: string;
+  /**
+   * Text + icon color (opaque CSS color string).
+   */
+  textColor: string;
+  /**
+   * Base border color. Highlighted border is derived from this.
+   */
+  borderColor: string;
+  /**
+   * Border radius (any CSS length, e.g. `24px`). Maps to the `--btn-radius` seam.
+   */
+  borderRadius: string;
+}>;
+
+/**
+ * Element-scoped CSS variable names the Button module consumes. Centralized here
+ * so the CSS seam and the resolver never drift.
+ */
+export const BUTTON_OVERRIDE_VARS = {
+  bgDefault: '--btn-accent-bg-default',
+  bgHighlighted: '--btn-accent-bg-highlighted',
+  bgDisabled: '--btn-accent-bg-disabled',
+  borderDefault: '--btn-accent-border-default',
+  borderHighlighted: '--btn-accent-border-highlighted',
+  contentColor: '--btn-content-color',
+  radius: '--btn-radius',
+} as const;
+
+/**
+ * Resolve a Button override object into element-scoped CSS variables, synthesizing
+ * the hover/active/focus and disabled states from the single base color.
+ *
+ * @example
+ * resolveButtonOverrides({ backgroundColor: '#1a59ff', textColor: '#ffffff' })
+ * // {
+ * //   '--btn-accent-bg-default':     '#1a59ff',
+ * //   '--btn-accent-bg-highlighted': '#0042e6',   // derived (darken)
+ * //   '--btn-accent-bg-disabled':    'rgba(26,89,255,0.5)', // derived (alpha)
+ * //   '--btn-content-color':         '#ffffff',
+ * // }
+ */
+export function resolveButtonOverrides(
+  overrides: ButtonStyleOverrides | undefined,
+): Record<string, string> {
+  if (!overrides) return {};
+  const vars: Record<string, string> = {};
+
+  if (isOverrideColorValue(overrides.backgroundColor)) {
+    const states = deriveColorStates(overrides.backgroundColor);
+    vars[BUTTON_OVERRIDE_VARS.bgDefault] = states.default;
+    vars[BUTTON_OVERRIDE_VARS.bgHighlighted] = states.highlighted;
+    vars[BUTTON_OVERRIDE_VARS.bgDisabled] = states.disabled;
+  }
+
+  if (isOverrideColorValue(overrides.borderColor)) {
+    const states = deriveColorStates(overrides.borderColor);
+    vars[BUTTON_OVERRIDE_VARS.borderDefault] = states.default;
+    vars[BUTTON_OVERRIDE_VARS.borderHighlighted] = states.highlighted;
+  }
+
+  if (isOverrideColorValue(overrides.textColor)) {
+    vars[BUTTON_OVERRIDE_VARS.contentColor] = overrides.textColor;
+  }
+
+  if (isOverrideColorValue(overrides.borderRadius)) {
+    vars[BUTTON_OVERRIDE_VARS.radius] = overrides.borderRadius;
+  }
+
+  return vars;
+}
+
+/**
+ * Serialize a CSS-variable map into an inline `style` string. Shared helper so
+ * every component/option emits overrides the same way.
+ *
+ * @example
+ * styleObjectToString({ '--btn-content-color': '#fff' }) // '--btn-content-color:#fff'
+ */
+export function styleObjectToString(vars: Record<string, string | number>): string {
+  return Object.entries(vars)
+    .map(([key, value]) => `${key}:${value}`)
+    .join(';');
+}
diff --git a/packages/blade-core/src/styles/Button/index.ts b/packages/blade-core/src/styles/Button/index.ts
index 762a5db962a..0445a364d72 100644
--- a/packages/blade-core/src/styles/Button/index.ts
+++ b/packages/blade-core/src/styles/Button/index.ts
@@ -21,3 +21,9 @@ export {
   getButtonSpinnerSize,
 } from './button';
 export type { ButtonVariants, ButtonColor, ButtonVariant, ActionStatesType } from './button';
+export {
+  resolveButtonOverrides,
+  styleObjectToString,
+  BUTTON_OVERRIDE_VARS,
+} from './buttonOverrides';
+export type { ButtonStyleOverrides } from './buttonOverrides';
diff --git a/packages/blade-core/src/styles/Card/card.module.css b/packages/blade-core/src/styles/Card/card.module.css
index ab1d9a9b568..4388233a0dc 100644
--- a/packages/blade-core/src/styles/Card/card.module.css
+++ b/packages/blade-core/src/styles/Card/card.module.css
@@ -82,12 +82,35 @@
   box-sizing: border-box;
   text-align: left;
   border: none;
-  background-image: linear-gradient(to bottom, hsla(0, 0%, 100%, 1) 0%, hsla(0, 0%, 100%, 1) 100%),
-    linear-gradient(to bottom, hsla(0, 0%, 100%, 1) 0%, hsla(0, 0%, 97%, 1) 100%);
+  /*
+   * Instance-level styling seam (Option B, composite "parts" — see §4.5 seam audit
+   * in instance-level-styling-proposal). The surface background was a hardcoded
+   * gradient of raw hsla() (no CSS variable existed). The gradient *stops* are now
+   * re-expressed as `var(--card-surface-bg, <default>)`, so a merchant override
+   * (resolveCardOverrides → `--card-surface-bg`) recolors only this card's surface
+   * while preserving the subtle bottom-edge treatment. Unset → pixel-identical.
+   */
+  background-image: linear-gradient(
+      to bottom,
+      var(--card-surface-bg, hsla(0, 0%, 100%, 1)) 0%,
+      var(--card-surface-bg, hsla(0, 0%, 100%, 1)) 100%
+    ),
+    linear-gradient(
+      to bottom,
+      var(--card-surface-bg, hsla(0, 0%, 100%, 1)) 0%,
+      var(--card-surface-bg, hsla(0, 0%, 97%, 1)) 100%
+    );
   background-position: center top, center calc(100% - 2px);
   background-size: calc(100% - 2px) 16px, calc(100% - 2px) 16px;
   background-repeat: no-repeat;
-  box-shadow: inset 0px 0px 0px 1px var(--interactive-border-gray-disabled),
+  /*
+   * Border seam. The border is drawn as the inner-ring layer of this box-shadow
+   * (not `border-color`). That inner ring's color is now `var(--card-surface-border-color,
+   * <default token>)` so it can be overridden per-instance without touching the
+   * elevation/lip layers. Unset → identical to before.
+   */
+  box-shadow: inset 0px 0px 0px 1px
+      var(--card-surface-border-color, var(--interactive-border-gray-disabled)),
     0px 6px 32px 4px hsla(205, 8%, 71%, 0.06),
     inset 0px -1.5px 0px 1px var(--surface-background-gray-intense);
 }
diff --git a/packages/blade-core/src/styles/Card/cardOverrides.ts b/packages/blade-core/src/styles/Card/cardOverrides.ts
new file mode 100644
index 00000000000..f60daaed352
--- /dev/null
+++ b/packages/blade-core/src/styles/Card/cardOverrides.ts
@@ -0,0 +1,74 @@
+import { deriveColorStates, isOverrideColorValue } from '../../utils/colorOverrides';
+
+/**
+ * ## Option B extended to internal parts (axis E) — Card
+ *
+ * Card is the *composite* counterpart to Button: its visible surface lives on a
+ * **child** element (`.cardSurface`), and v1 demonstrates the "seam audit"
+ * (instance-level-styling-proposal §4.5). Before any part can be overridden, that
+ * part's target property must be expressed as a CSS variable on the right element.
+ * `card.module.css` was given additive, backward-compatible seams:
+ *
+ *   --card-surface-bg        (gradient stop → flat fill when set)
+ *   --card-surface-border-color
+ *
+ * `resolveCardOverrides` proves the "bounded, per-component **parts** vocabulary"
+ * that is the slice of Option D we keep — addressing parts via *nested keys*
+ * (`surface: { ... }`) rather than a centralized cross-repo slot taxonomy.
+ *
+ * The carrier is identical to Button's: a pure `Record<cssVarName, value>` that the
+ * framework layer spreads as inline CSS vars. The only difference is *which element*
+ * the vars must land on — here, the surface child (handled by the component).
+ */
+
+/** Overrides for the Card's surface part (the `.cardSurface` child element). */
+export type CardSurfaceOverrides = Partial<{
+  backgroundColor: string;
+  borderColor: string;
+}>;
+
+/**
+ * Card's bounded, typed override object. Keys are *named parts*, each exposing only
+ * the properties whose CSS seam exists. Growth = add a part key + the matching
+ * `var(--part-prop, <default>)` seam in the CSS module (proposal §4.5
+ * "Extensibility contract").
+ */
+export type CardStyleOverrides = Partial<{
+  surface: CardSurfaceOverrides;
+}>;
+
+export const CARD_OVERRIDE_VARS = {
+  surfaceBg: '--card-surface-bg',
+  surfaceBorderColor: '--card-surface-border-color',
+} as const;
+
+/**
+ * Resolve the Card override object into CSS variables destined for the surface
+ * child element.
+ *
+ * @example
+ * resolveCardOverrides({ surface: { backgroundColor: '#ffffff', borderColor: '#1a59ff' } })
+ * // { '--card-surface-bg': '#ffffff', '--card-surface-border-color': '#1a59ff' }
+ */
+export function resolveCardOverrides(
+  overrides: CardStyleOverrides | undefined,
+): Record<string, string> {
+  if (!overrides) return {};
+  const vars: Record<string, string> = {};
+
+  const surface = overrides.surface;
+  if (surface) {
+    if (isOverrideColorValue(surface.backgroundColor)) {
+      vars[CARD_OVERRIDE_VARS.surfaceBg] = surface.backgroundColor;
+    }
+    if (isOverrideColorValue(surface.borderColor)) {
+      // Derive a slightly darker selected/hover border for parity with Button,
+      // even though Card only consumes `default` today — keeps the resolver shape
+      // consistent and ready for state-aware parts later.
+      const states = deriveColorStates(surface.borderColor);
+      vars[CARD_OVERRIDE_VARS.surfaceBorderColor] = states.default;
+    }
+  }
+
+  return vars;
+}
diff --git a/packages/blade-core/src/styles/Card/index.ts b/packages/blade-core/src/styles/Card/index.ts
index ec50312d635..685eba8cb98 100644
--- a/packages/blade-core/src/styles/Card/index.ts
+++ b/packages/blade-core/src/styles/Card/index.ts
@@ -11,3 +11,5 @@ export type {
   CardHeaderVariants,
   CardFooterVariants,
 } from './card';
+export { resolveCardOverrides, CARD_OVERRIDE_VARS } from './cardOverrides';
+export type { CardStyleOverrides, CardSurfaceOverrides } from './cardOverrides';
diff --git a/packages/blade-core/src/styles/index.ts b/packages/blade-core/src/styles/index.ts
index 370b1733dcb..0dd01473d48 100644
--- a/packages/blade-core/src/styles/index.ts
+++ b/packages/blade-core/src/styles/index.ts
@@ -41,8 +41,17 @@ export {
   getButtonIconSize,
   getButtonIconOnlySize,
   getButtonSpinnerSize,
+  resolveButtonOverrides,
+  styleObjectToString,
+  BUTTON_OVERRIDE_VARS,
 } from './Button';
-export type { ButtonVariants, ButtonColor, ButtonVariant } from './Button';
+export type { ButtonVariants, ButtonColor, ButtonVariant, ButtonStyleOverrides } from './Button';
+// Instance-level styling — Option D (slot-keyed theme map) and Option C (scoped
+// theme provider) framework-agnostic resolvers. See instance-level-styling-proposal.
+export { resolveSlotTheme } from './slotTheme';
+export type { SlotThemeMap, SlotThemeComponent } from './slotTheme';
+export { flattenThemeOverridesToVars } from './themeScope';
+export type { ThemeOverrideTree } from './themeScope';
 export { utilityClasses, getUtilityClass } from './utilities';
 // @ts-expect-error - CSS modules may not have type definitions in build
 export { default as utilities } from './utilities.module.css';
@@ -127,11 +136,14 @@ export {
   getCardFooterClasses,
   getCardTemplateClasses,
 } from './Card';
+export { resolveCardOverrides, CARD_OVERRIDE_VARS } from './Card';
 export type {
   CardRootVariants,
   CardSurfaceVariants,
   CardHeaderVariants,
   CardFooterVariants,
+  CardStyleOverrides,
+  CardSurfaceOverrides,
 } from './Card';
 export {
   animatedChipCva,
diff --git a/packages/blade-core/src/styles/slotTheme/index.ts b/packages/blade-core/src/styles/slotTheme/index.ts
new file mode 100644
index 00000000000..0a72d1c79b1
--- /dev/null
+++ b/packages/blade-core/src/styles/slotTheme/index.ts
@@ -0,0 +1,2 @@
+export { resolveSlotTheme } from './slotTheme';
+export type { SlotThemeMap, SlotThemeComponent } from './slotTheme';
diff --git a/packages/blade-core/src/styles/slotTheme/slotTheme.ts b/packages/blade-core/src/styles/slotTheme/slotTheme.ts
new file mode 100644
index 00000000000..a541271dc26
--- /dev/null
+++ b/packages/blade-core/src/styles/slotTheme/slotTheme.ts
@@ -0,0 +1,52 @@
+import { resolveButtonOverrides, type ButtonStyleOverrides } from '../Button/buttonOverrides';
+import { resolveCardOverrides, type CardStyleOverrides } from '../Card/cardOverrides';
+
+/**
+ * ## Option D — Slot-keyed theme map (component "parts" theming, à la shadcn/Stitches)
+ *
+ * A single declarative object keyed by `component → slotKey → overrides`, consumed
+ * via context. A component opts into a slot with `themeKey="primaryCta"` and the
+ * map is looked up to produce the same CSS variables Option B emits.
+ *
+ * Included for evaluation. The proposal's verdict (instance-level-styling-proposal
+ * §4 Option D, §6): **reject the centralized cross-repo slot taxonomy** (it invents
+ * a naming dimension that must be documented and synced across Blade + checkout) but
+ * **keep the parts-addressing instinct**, folded into Option B as nested keys.
+ *
+ * Note this is explicitly a *sugar layer, not a mechanism*: it still needs Option
+ * B's carrier underneath — `resolveSlotTheme` just routes a slot's overrides into
+ * the per-component resolver, so the var output is byte-identical to calling
+ * `resolveButtonOverrides` / `resolveCardOverrides` directly.
+ */
+export type SlotThemeMap = {
+  button?: Record<string, ButtonStyleOverrides>;
+  card?: Record<string, CardStyleOverrides>;
+};
+
+export type SlotThemeComponent = keyof SlotThemeMap;
+
+/**
+ * Look up a component+slot in the theme map and resolve it to CSS variables using
+ * the matching per-component resolver (Option B carrier).
+ *
+ * @example
+ * const map = { button: { primaryCta: { backgroundColor: '#1a59ff' } } };
+ * resolveSlotTheme(map, 'button', 'primaryCta');
+ * // -> same vars as resolveButtonOverrides({ backgroundColor: '#1a59ff' })
+ */
+export function resolveSlotTheme(
+  themeMap: SlotThemeMap | undefined,
+  component: SlotThemeComponent,
+  slotKey: string | undefined,
+): Record<string, string> {
+  if (!themeMap || !slotKey) return {};
+
+  if (component === 'button') {
+    return resolveButtonOverrides(themeMap.button?.[slotKey]);
+  }
+  if (component === 'card') {
+    return resolveCardOverrides(themeMap.card?.[slotKey]);
+  }
+
+  return {};
+}
diff --git a/packages/blade-core/src/styles/themeScope/index.ts b/packages/blade-core/src/styles/themeScope/index.ts
new file mode 100644
index 00000000000..8e5edb2ccb8
--- /dev/null
+++ b/packages/blade-core/src/styles/themeScope/index.ts
@@ -0,0 +1,2 @@
+export { flattenThemeOverridesToVars } from './themeScope';
+export type { ThemeOverrideTree } from './themeScope';
diff --git a/packages/blade-core/src/styles/themeScope/themeScope.ts b/packages/blade-core/src/styles/themeScope/themeScope.ts
new file mode 100644
index 00000000000..325075ad4f3
--- /dev/null
+++ b/packages/blade-core/src/styles/themeScope/themeScope.ts
@@ -0,0 +1,51 @@
+import { tokenToCSSVariable } from '../../utils/tokenToCSSVariable';
+
+/**
+ * ## Option C — Scoped theme via `BladeProvider` + wrapper CSS variables (subtree)
+ *
+ * Instead of repainting `:root`, a `BladeProvider` re-declares the affected token
+ * CSS variables on its **own wrapper element**, establishing a scoped cascade so
+ * every Blade component inside inherits the override. This finally gives Svelte the
+ * provider parity React has (instance-level-styling-proposal §4 Option C).
+ *
+ * `flattenThemeOverridesToVars` is the framework-agnostic half: it walks a partial,
+ * nested token override (mirroring the `interactive`/`surface`/… token shape) and
+ * flattens it into `{ '--interactive-background-primary-default': '#1a59ff', … }`
+ * using the same `tokenToCSSVariable` mapping the rest of Blade uses.
+ *
+ * Verdict (proposal §6): C is **complementary** to B, not a substitute — great for
+ * region/brand theming ("make this whole drawer festive"), too coarse for isolating
+ * a single sibling instance. Both ship; pick per use case.
+ */
+export type ThemeOverrideTree = {
+  [key: string]: string | number | ThemeOverrideTree;
+};
+
+/**
+ * Recursively flatten a nested token override tree into a flat CSS-variable map.
+ *
+ * @example
+ * flattenThemeOverridesToVars({
+ *   interactive: { background: { primary: { default: '#1a59ff' } } },
+ * });
+ * // { '--interactive-background-primary-default': '#1a59ff' }
+ */
+export function flattenThemeOverridesToVars(
+  overrides: ThemeOverrideTree | undefined,
+  path: string[] = [],
+): Record<string, string> {
+  if (!overrides) return {};
+  const vars: Record<string, string> = {};
+
+  for (const [key, value] of Object.entries(overrides)) {
+    const nextPath = [...path, key];
+    if (value !== null && typeof value === 'object') {
+      Object.assign(vars, flattenThemeOverridesToVars(value, nextPath));
+    } else if (value !== undefined && value !== '') {
+      const cssVar = tokenToCSSVariable(nextPath.join('.'));
+      vars[cssVar] = String(value);
+    }
+  }
+
+  return vars;
+}
diff --git a/packages/blade-core/src/utils/colorOverrides/deriveColorStates.ts b/packages/blade-core/src/utils/colorOverrides/deriveColorStates.ts
new file mode 100644
index 00000000000..61335407c16
--- /dev/null
+++ b/packages/blade-core/src/utils/colorOverrides/deriveColorStates.ts
@@ -0,0 +1,100 @@
+import tinycolor from 'tinycolor2';
+import type { ColorInput } from 'tinycolor2';
+
+/**
+ * v1 instance-styling vocabulary is an *opaque color passthrough*: checkout's
+ * `getUIConfigColor` only ever emits a single 6-digit hex per slot (no per-state
+ * values). The centerpiece of v1 is therefore *deriving* the interaction states
+ * the consumer never sends — so an overridden component keeps a working
+ * hover/active/focus and disabled appearance instead of dead-ending (the bug in
+ * checkout's current inline-style CTAs — see instance-level-styling-proposal §1.1).
+ *
+ * These offsets are intentionally small and are tuned to visually approximate
+ * Blade's existing `highlighted` / `disabled` token steps. They are scheme-agnostic
+ * by design (checkout runs a single color scheme per session; dark-mode-aware
+ * derivation is out of scope for v1 — see proposal §Non-goals).
+ */
+
+/** How much to darken the base color for the hover/active/focus state. */
+export const HIGHLIGHTED_DARKEN_AMOUNT = 8;
+/** Alpha applied to the base color for the disabled state. */
+export const DISABLED_ALPHA = 0.5;
+
+/**
+ * Returns true when the value is a non-empty string Blade can hand to CSS as-is.
+ * v1 does no format validation (security/sanitization stays in the consumer —
+ * checkout already hex-validates). Empty string means "merchant did not set it",
+ * so we skip it and let the token cascade keep the default.
+ */
+export const isOverrideColorValue = (value: unknown): value is string => {
+  return typeof value === 'string' && value.trim().length > 0;
+};
+
+/**
+ * Darken a color by a percentage. Falls back to the original string if tinycolor
+ * cannot parse it (v1 treats values as opaque — never throw on a merchant value).
+ */
+export const darkenColor = (
+  color: ColorInput,
+  amount: number = HIGHLIGHTED_DARKEN_AMOUNT,
+): string => {
+  const parsed = tinycolor(color);
+  if (!parsed.isValid()) {
+    return String(color);
+  }
+  return parsed.darken(amount).toHexString();
+};
+
+/**
+ * Apply an alpha channel to a color, returning an `rgba()` string. Falls back to
+ * the original string if tinycolor cannot parse it.
+ */
+export const fadeColor = (color: ColorInput, alpha: number = DISABLED_ALPHA): string => {
+  const parsed = tinycolor(color);
+  if (!parsed.isValid()) {
+    return String(color);
+  }
+  return parsed.setAlpha(alpha).toRgbString();
+};
+
+export type DerivedColorStates = {
+  /** The base color, unchanged. */
+  default: string;
+  /** Darkened base — used for hover / active / focus. */
+  highlighted: string;
+  /** Faded base — used for the disabled state. */
+  disabled: string;
+};
+
+/**
+ * Synthesize the default / highlighted / disabled triplet from a single base
+ * color. This is what makes the per-instance override *state-aware* even though
+ * the consumer only provides one value.
+ *
+ * @example
+ * deriveColorStates('#1a59ff')
+ * // { default: '#1a59ff', highlighted: '#0042e6', disabled: 'rgba(26, 89, 255, 0.5)' }
+ */
+export const deriveColorStates = (baseColor: string): DerivedColorStates => {
+  return {
+    default: baseColor,
+    highlighted: darkenColor(baseColor),
+    disabled: fadeColor(baseColor),
+  };
+};
+
+/**
+ * Pick the most readable foreground (black or white) for a given background.
+ * Useful as an a11y guard when a merchant sets a background but not a text color.
+ * Returns undefined when the background can't be parsed.
+ */
+export const getReadableForeground = (
+  backgroundColor: string,
+  candidates: [string, string] = ['#ffffff', '#0c1117'],
+): string | undefined => {
+  const parsed = tinycolor(backgroundColor);
+  if (!parsed.isValid()) {
+    return undefined;
+  }
+  return tinycolor.mostReadable(backgroundColor, candidates).toHexString();
+};
diff --git a/packages/blade-core/src/utils/colorOverrides/index.ts b/packages/blade-core/src/utils/colorOverrides/index.ts
new file mode 100644
index 00000000000..de742e4516c
--- /dev/null
+++ b/packages/blade-core/src/utils/colorOverrides/index.ts
@@ -0,0 +1,2 @@
+export * from './deriveColorStates';
+export * from './visualStyledProps';
diff --git a/packages/blade-core/src/utils/colorOverrides/visualStyledProps.ts b/packages/blade-core/src/utils/colorOverrides/visualStyledProps.ts
new file mode 100644
index 00000000000..37ad689d75e
--- /dev/null
+++ b/packages/blade-core/src/utils/colorOverrides/visualStyledProps.ts
@@ -0,0 +1,64 @@
+import { getTokenCSSVariable } from '../tokenToCSSVariable';
+
+/**
+ * ## Option A — Visual styled props (inline-style fallback)
+ *
+ * Extends the styled-props idea to *visual* properties (background, color, border,
+ * radius). Resolves a token string to a `var(--token)` reference, otherwise passes
+ * the raw value straight through to an inline style declaration — exactly mirroring
+ * how spacing styled props fall back from `spacing.4` to `12px`.
+ *
+ * ⚠️ This option is included for side-by-side evaluation. It is intentionally
+ * **state-unaware**: writing `background-color` directly *dead-ends* a stateful
+ * component's hover/active/disabled background (those come from token classes the
+ * inline value now shadows). This is the shipped bug in checkout's Contact CTA and
+ * NotificationBanner (proposal §1.1). Prefer Option B (`resolveButtonOverrides`)
+ * for stateful components. See instance-level-styling-proposal §4 Option A.
+ */
+export type VisualStyledProps = Partial<{
+  backgroundColor: string;
+  color: string;
+  borderColor: string;
+  borderRadius: string;
+}>;
+
+const TOKEN_PREFIXES = ['surface.', 'interactive.', 'feedback.', 'spacing.', 'border.'];
+
+/**
+ * If the value looks like a Blade dot-notation token, return a `var(--token)`
+ * reference; otherwise return the raw value (arbitrary CSS string passthrough).
+ */
+const resolveVisualValue = (value: string): string => {
+  const isToken = TOKEN_PREFIXES.some((prefix) => value.startsWith(prefix));
+  return isToken ? getTokenCSSVariable(value) : value;
+};
+
+/**
+ * Convert visual styled props into a flat inline-style map (camelCase keys, as
+ * the Svelte/React layer would spread onto a `style` attribute).
+ *
+ * @example
+ * resolveVisualStyledProps({ backgroundColor: '#1a59ff', borderRadius: '24px' })
+ * // { backgroundColor: '#1a59ff', borderRadius: '24px' }
+ */
+export const resolveVisualStyledProps = (
+  props: VisualStyledProps | undefined,
+): Record<string, string> => {
+  if (!props) return {};
+  const styles: Record<string, string> = {};
+
+  if (props.backgroundColor) {
+    styles.backgroundColor = resolveVisualValue(props.backgroundColor);
+  }
+  if (props.color) {
+    styles.color = resolveVisualValue(props.color);
+  }
+  if (props.borderColor) {
+    styles.borderColor = resolveVisualValue(props.borderColor);
+  }
+  if (props.borderRadius) {
+    styles.borderRadius = resolveVisualValue(props.borderRadius);
+  }
+
+  return styles;
+};
diff --git a/packages/blade-core/src/utils/index.ts b/packages/blade-core/src/utils/index.ts
index f693e8965b1..907958388a4 100644
--- a/packages/blade-core/src/utils/index.ts
+++ b/packages/blade-core/src/utils/index.ts
@@ -11,6 +11,7 @@ export * from './lodashButBetter/isNumber';
 export * from './lodashButBetter/isUndefined';
 export * from './lodashButBetter/kebabCase';
 export * from './lodashButBetter/throttle';
+export * from './colorOverrides';
 export * from './getFloatingPlacementParts';
 export * from './hasSameObjectStructure';
 export * from './isPartialMatchObjectKeys';
diff --git a/packages/blade-svelte/docs/instance-level-styling-proposal.md b/packages/blade-svelte/docs/instance-level-styling-proposal.md
new file mode 100644
index 00000000000..17fb28648f4
--- /dev/null
+++ b/packages/blade-svelte/docs/instance-level-styling-proposal.md
@@ -0,0 +1,481 @@
+# Instance-Level Styling for Blade Svelte — Design Proposal
+
+> **Status:** Draft / RFC
+> **Author:** Staff Frontend (Blade)
+> **Scope:** `@razorpay/blade-svelte` + `@razorpay/blade-core`
+> **Purpose:** **Adoption-readiness / API-fit review.** Checkout V2 just shipped a deep merchant-configurability layer (Config V2, PR [checkout#11286](https://github.com/razorpay/checkout/pull/11286)) but **does not consume Blade Svelte yet** — it styles its own components. This doc evaluates the architectural/API changes Blade Svelte needs so checkout can drop those bespoke components and adopt Blade *without losing the merchant-config surface*.
+> **Related:** `docs/theming-and-classnames.md`, `checkout/app/v2/docs/CONFIG_V2_SPEC.md`, `checkout/app/v2/utils/config-driver/*`
+
+> **📦 Reference implementations (all 5 options are now buildable & inspectable).** To make this RFC concrete, every option A–E has a working spike landed in the codebase so the team can compare them side-by-side in Storybook (especially hover/disabled behaviour) rather than from prose alone. **These are evaluation spikes, not a final API commitment** — the recommendation (B core + C complementary) is unchanged.
+>
+> | Option | `blade-core` (framework-agnostic) | `blade-svelte` wiring |
+> |---|---|---|
+> | **A** — visual styled props | `utils/colorOverrides/visualStyledProps.ts` (`resolveVisualStyledProps`) | `Button` prop `visualProps` |
+> | **B** — `styleOverrides` → CSS vars (**recommended**) | `styles/Button/buttonOverrides.ts` (`resolveButtonOverrides`), `styles/Card/cardOverrides.ts` (`resolveCardOverrides`, parts), `utils/colorOverrides/deriveColorStates.ts` (state synthesis) | `Button`/`Card` prop `styleOverrides`; CSS seams added to `button.module.css` (`--btn-content-color`, `--btn-radius`) and `card.module.css` (`--card-surface-bg`, `--card-surface-border-color`) |
+> | **C** — scoped provider | `styles/themeScope/themeScope.ts` (`flattenThemeOverridesToVars`) | `BladeProvider.svelte` (`themeOverrides`) |
+> | **D** — slot-keyed map | `styles/slotTheme/slotTheme.ts` (`resolveSlotTheme`) | `BladeProvider` (`slotTheme`) + `Button` prop `themeKey` |
+> | **E** — `className` | — | `Button` prop `className` |
+>
+> **See it:** Storybook → *Patterns / Instance-Level Styling* (`src/components/Button/StyleOverrides.stories.svelte`). The “A vs B · hover & disabled” story is the money shot — A dead-ends states, B derives them. Everything is additive/backward-compatible (`svelte-check` + `blade-core` typecheck green; unspecified instances render pixel-identical via `var(--x, <default>)`).
+
+---
+
+## 1. Problem statement
+
+Blade theming is **global or color-scheme scoped**. Tokens are flat CSS custom properties on `:root` (and re-declared under `body[data-theme='dark']`). White-labelling (`createTheme`) regenerates that **one** global palette from a single brand color. (Note: blade-svelte has **no `BladeProvider`/ThemeProvider component at all** — theming is the `theme.css` import + `data-theme` attribute; `createTheme` injects vars into `:root` via JS. Verified in `docs/theming-and-classnames.md`.)
+
+Checkout's Config V2 needs **instance-level** customization. On a single Contact page there can be two `Button`s that must look different *at the same time*:
+
+| Instance | border radius | background |
+|----------|---------------|------------|
+| Primary CTA | `24px` | blue |
+| Secondary CTA | `8px` | white |
+
+Traditional DS theming only expresses `theme.button.primary` / `theme.button.secondary` — a **type-level** axis, not an **instance-level** one.
+
+The merchant config expresses CTA intent today as **surface-scoped** paths (per *screen*, not per sibling instance), and they **inherit from the global theme** when unset:
+
+```ts
+// checkout/app/v2/utils/config-driver/paths.ts
+CONTACT_CTA_BG:        'surface.contact.cta.primary.background',
+CONTACT_CTA_TEXT_COLOR:'surface.contact.cta.primary.text_color',
+```
+
+```ts
+// checkout/app/v2/utils/config-driver/resolver.ts — applyHierarchyInheritance()
+// surface.contact.cta.primary.background ← global.theme.cta.primary.background (when empty)
+```
+
+So even today the config axis is **surface/type-level**: there is no path by which two sibling CTAs on the *same* screen can differ. That gap — true per-instance precision — is precisely what a Blade API must add. And on the Blade side there is currently **no API to receive even the surface-level value**: `StyledPropsBlade` deliberately excludes color/background/border-radius (verified — it lists only margin/layout/flex/position/grid), components expose no `className`/`style`, and the only override knob (`:root` variables) repaints every instance on the page.
+
+### Goals
+- G1. Per-instance override of a **bounded, growable** set of visual properties (start: bg + text color; later: border color, radius, and **internal parts** of composite components — see §4.5).
+- G2. Two instances of the same component, same page, styled differently.
+- G3. Preserve interaction states (hover/focus/disabled), WCAG behavior, and the class-first token architecture.
+- G4. Clean mapping from Checkout `config-driver` output → Blade overrides, so adoption is a near drop-in swap.
+- G5. Zero / opt-in change for existing Blade consumers (`blade-core` must stay framework-agnostic so React can adopt the same resolver later).
+
+### Non-goals
+- Arbitrary free-form CSS injection by merchants (security/brand risk).
+- Re-theming via per-instance `createTheme` (palette regeneration is global + expensive).
+- Changing the global token names or the `data-theme` mechanism.
+- **Dark-mode-aware overrides for the checkout use case.** Checkout runs a single color scheme per session and de-scopes dark mode for merchant overrides; v1 state derivation (Option B, §4) is scheme-agnostic by design. Dark-mode-aware *parts* remain a concern for general Blade adoption (composite components like Card already ship `body[data-theme='dark']` part rules) but are explicitly out of scope for v1.
+
+---
+
+## 1.1 Current state in checkout (the anti-pattern this replaces)
+
+Checkout already solves per-component merchant styling — with the **flat inline-`style` approach this doc calls Option A** (§4). Two shipped examples:
+
+**Contact CTA** reads the config color and writes it straight onto `background`/`color`:
+
+```svelte
+<!-- checkout/app/v2/modules/contact/components/Contact.svelte -->
+const ctaBg$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_BG);
+const ctaTextColor$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_TEXT_COLOR);
+...
+<Button style={`${$ctaBg$ ? `background: ${$ctaBg$};` : ''}${$ctaTextColor$ ? ` color: ${$ctaTextColor$};` : ''}`}>
+```
+
+**NotificationBanner** does the same for bg/text and adds `fontSize`/`fontWeight`:
+
+```svelte
+<!-- checkout/app/v2/modules/common/notification-banner/NotificationBanner.svelte -->
+<div style={`...; ${backgroundColor ? `background-color:${backgroundColor};` : ''}`}>
+  <div style={`${textColor ? `color:${textColor};` : ''}${fontSizeStyle}`}>
+```
+
+This is **direct evidence for why Option A is insufficient**, not a hypothetical:
+- Writing `background` directly **dead-ends interaction states** — the overridden CTA loses its `:hover`/`:active`/`disabled` background (those came from Tailwind/token classes the inline color now shadows). An overridden button is visually *more* broken than an unstyled one.
+- The Config V2 spec itself documents this as the generic component-level mechanism (`CONFIG_V2_SPEC.md` §4.2: "read → props → inline-style/class"). So adopting Blade naïvely (passing these same values to a `style` prop) would **carry the bug across**.
+
+The job of this proposal is therefore not "give Blade a color knob" — it's "give Blade a knob that feeds the **state-driving** variables so adoption is an *improvement* over the status quo, not a regression."
+
+---
+
+## 2. Key architectural facts (grounding)
+
+These constrain every option below (verified in code):
+
+1. **Class-first, value-second.** Components emit *class names* + *token strings*; CSS Modules reference `var(--token)`. Components never emit raw colors. (`blade-core/styles/Button/button.ts`, `button.module.css`)
+2. **CSS variables already cascade per element.** The Button CSS module is *already* parameterized by **element-scoped** custom properties:
+   ```css
+   .color-primary { --btn-accent-bg-default: var(--interactive-background-primary-default); }
+   .color-primary.primary { background-color: var(--btn-accent-bg-default); }
+   ```
+   Setting `--btn-accent-bg-default` inline on one `<button>` overrides only that instance — the seam already exists.
+3. **Token→variable mapping util exists.** `getTokenCSSVariable('interactive.background.primary.default')` → `'var(--interactive-background-primary-default)'`. (`utils/tokenToCSSVariable`)
+4. **Arbitrary-value precedent exists.** Styled props already fall back from tokens (`spacing.4`) to raw values (`12px`) via `getSpacingValue`. We *can* mirror this for visual props later, but **v1's vocabulary is narrower than the precedent** — see fact #6: checkout only ever emits a 6-digit hex or `''`, so v1 treats the value as an **opaque string passthrough** and defers token resolution.
+5. **Svelte has no theming context/provider.** `setContext`/`getContext` is used only for compound-component state (Chip/Tooltip); there is no theming provider component (see §1).
+6. **The consumer's output contract is narrow and known.** `getUIConfigColor` returns **only** a 6-digit hex (`^#[0-9A-Fa-f]{6}$`) or `''` — no 3-digit hex, `rgb()`, or named colors. Config text is sanitized; resolution is a 6-step precedence pipeline. This **bounds v1's job**: accept one opaque base color per slot and *derive* the rest. Bundle budget: `v2-entry-app` +1KB max, lazy-load. No `<style>` blocks in SFCs.
+7. **Composite components have no single override seam.** Button was already refactored to read element-scoped `--btn-accent-*` vars — which is *why* Option B looks cheap there. Other components have **not**: e.g. `Card`'s visible surface lives on a *child* (`.cardSurface`), its background is a **hardcoded `linear-gradient` of raw `hsla()`** (not a `var()`), and its border is a layered `inset box-shadow` (not `border-color`). So "override the card background/border" is impossible until those properties are first re-expressed as variables. This is the real, per-component cost — see §4.5 and §7.
+
+---
+
+## 3. Design axes
+
+Any solution must answer five questions:
+
+- **A. Carrier** — how does an override value reach the element? (inline CSS var / class / context / attribute)
+- **B. API shape** — how does the developer/merchant express it? (per-instance prop / theme map keyed by slot / styled-prop extension)
+- **C. Vocabulary** — what can be overridden, and with what values? (semantic tokens only / tokens + arbitrary / opaque passthrough / freeform)
+- **D. Scope** — instance / subtree / page.
+- **E. Surface** — top-level visual props only, or **named internal parts** of composite components? (This axis is what "configure something internal" — e.g. an Input's field vs. label vs. placeholder — forces; see §4.5.)
+
+The options below are concrete combinations of these axes. **v1 decision (locked):** Carrier = inline element-scoped CSS vars (B); Vocabulary = opaque hex passthrough with derived states (C); Surface grows from top-level props → named parts (E).
+
+---
+
+## 4. Options evaluated
+
+### Option A — Extend styled props with visual props (inline-style fallback)
+
+Add `backgroundColor`, `color`, `borderColor`, `borderRadius`, etc. to `StyledPropsBlade`. They resolve like spacing: token → utility class where possible, arbitrary → inline style. Components already call `getStyledPropsClasses(rest)`, so the plumbing is partly there.
+
+```svelte
+<Button backgroundColor="#1a59ff" borderRadius="24px">Pay</Button>
+```
+
+**Pros**
+- Smallest conceptual surface; reuses the existing styled-props pipeline and the token/arbitrary duality.
+- Naturally per-instance; two buttons differ trivially.
+- Framework-agnostic (logic stays in `blade-core`).
+
+**Cons**
+- **Semantically wrong for stateful components — and we have shipped proof.** A Button's background isn't one value — it's `default/hover/focus/disabled` (+ gradient + box-shadow). A flat `backgroundColor` can't express hover/disabled, so overridden buttons lose interaction states. This is **exactly the bug in checkout's Contact CTA and NotificationBanner today** (§1.1); adopting Blade via this path would import the regression rather than fix it.
+- Note the *only* real difference between A and B (under v1's hex-passthrough vocabulary) is **plumbing, not vocabulary**: both take a hex string. A writes it to `background-color` directly (dead-ends state); B writes it into the state-driving custom prop (`--btn-accent-bg-default`) so `:hover`/`disabled` keep resolving. That single distinction is the whole argument for B.
+- Encourages "anything goes" inline styling → erodes design-system guardrails; hard to lint/govern.
+- Explodes the styled-prop matrix (every visual prop × responsive × component) and **can't address internal parts** (axis E) — a flat top-level prop has no way to target an Input's placeholder vs. its field.
+
+**Scalability:** Poor for stateful components; OK for static ones. **Backward-compat:** Additive (✓). **Blade impact:** Medium — pollutes the styled-props contract.
+
+---
+
+### Option B — Per-component `styleOverrides` prop → element-scoped CSS variables (**recommended core**)
+
+Each component accepts a typed, **bounded** `styleOverrides` object. The component maps it to its **own** CSS-module custom properties and emits them as an inline `style="--…: …"` on the right element. CSS already consumes those variables, so **state variants keep working** (hover/disabled read the same `--btn-accent-*` vars).
+
+```svelte
+<Button
+  variant="primary"
+  styleOverrides={{
+    backgroundColor: '#1a59ff', // opaque hex from getUIConfigColor — v1 vocabulary
+    textColor: '#ffffff',       // opaque hex
+  }}
+/>
+```
+
+**v1 vocabulary = opaque hex passthrough + derived states.** Checkout only ever sends one base hex per slot (fact #6), so the resolver's *primary* job is to **synthesize the interaction states** the merchant didn't provide:
+
+```ts
+// resolveButtonOverrides({ backgroundColor: '#1a59ff', textColor: '#ffffff' })
+//   -> Record<cssVarName, value>
+{
+  '--btn-accent-bg-default':     '#1a59ff',
+  '--btn-accent-bg-highlighted': '<derive: darken(#1a59ff)>',  // hover/active/focus
+  '--btn-accent-bg-disabled':    '<derive: alpha(#1a59ff)>',
+  '--btn-content-color':         '#ffffff',
+}
+```
+
+This makes B a **strict improvement over the shipped Option A** (§1.1): same input (one hex), but hover/disabled now work instead of breaking. State derivation is therefore the **centerpiece of v1**, not a "nice to have" — `tinycolor` is already a dependency (via `createTheme`) for the darken/alpha math, and the derived steps should visually match Blade's existing `highlighted`/`disabled` token offsets.
+
+**Reactivity is a hard requirement.** `useUIConfigColor` returns a live `Readable<T>` so the Studio editor repaints on change (`CONFIG_V2_SPEC.md` §3.5). Inline CSS vars satisfy this trivially (re-spread the `style` map on change); a class-based carrier would not. This is an additional reason the carrier must be inline vars.
+
+*(Tokens and explicit per-state overrides — e.g. accepting `backgroundColorHovered` or `'surface.text…'` token strings — are a later-phase extension of the same resolver, not v1. See §11.)*
+
+**Pros**
+- **Preserves the architecture**: still class-first; overrides are just *scoped variable values* layered over the cascade.
+- **State-aware** by design — the same custom props drive default/hover/focus/disabled, and v1 *derives* the states checkout omits.
+- **Reactive-friendly** — inline vars update cleanly when the config `Readable` changes (editor live-edit).
+- True per-instance; no `:root` pollution.
+- `blade-core` stays framework-agnostic (pure resolver fn); Svelte just spreads the `style` map. React can adopt the same resolver later.
+- Tree-shake safe — values are inline styles, not classes, so nothing to shake.
+
+**Cons**
+- **Per-component CSS-seam refactor — and its cost is non-uniform.** Button is cheap *only because it was already refactored* to read `--btn-accent-*`. Composite components (Card, future Input) need their target properties re-expressed as variables first; for box-shadow borders and gradient backgrounds that is a real DS-owned change, not a one-liner (fact #7, §4.5, §7).
+- Needs a typed contract per component (and, for composites, a **parts** contract — §4.5).
+- Requires discipline so `styleOverrides` doesn't become a freeform `style` escape hatch (mitigate: typed keys only, no `& CSSProperties`).
+
+**Scalability:** Good as a *pattern*, but per-component effort scales with how variable-ized the component already is. **Backward-compat:** Fully additive; defaulted variables (`var(--x, <current default>)`) preserve current pixels (✓✓). **Blade impact:** Low for Button; Medium for composites that need seam work.
+
+---
+
+### Option C — Scoped theme via `BladeProvider` + Svelte context (subtree override)
+
+Implement a real `BladeProvider.svelte` that takes a partial token override and **re-declares the affected CSS variables on its own wrapper element** (not `:root`), establishing a scoped cascade. Optionally exposes overrides via Svelte context for components that need JS-level values.
+
+```svelte
+<BladeProvider themeOverrides={{ interactive: { background: { primary: { default: '#1a59ff' }}}}}>
+  <Button>Pay</Button>   <!-- every primary button in here is blue -->
+</BladeProvider>
+```
+
+**Pros**
+- Solves *subtree* theming elegantly (e.g. "make this whole drawer use the festive palette").
+- Reuses `overrideTheme` deep-merge + `tokenToCSSVariable`; conceptually clean.
+- No per-component schema; works for all components at once.
+- Finally gives Svelte the provider parity React has.
+
+**Cons**
+- **Doesn't solve the core ask alone.** Two *sibling* buttons differing on the same page would each need their own provider wrapper → awkward, extra DOM, and still type-level (`primary` vs `secondary`), not instance-level.
+- Overriding semantic tokens at subtree scope is **coarse**: changing `interactive.background.primary.default` recolors *all* primary interactives in scope (buttons, links, etc.), not just the CTA.
+- Risk of deep nesting / cascade reasoning complexity.
+
+**Scalability:** Great for *regions/brand*, weak for *sibling instances*. **Backward-compat:** Additive (✓). **Blade impact:** Medium — new component + provider semantics, but no breaking change.
+
+> Conclusion: C is **complementary** to B, not a substitute. Use C for surface/region theming, B for instance precision.
+
+---
+
+### Option D — Slot-keyed theme map (component "parts" theming, à la shadcn/Stitches)
+
+A single theme object keyed by component → slot → state, consumed via context. Components look up their slot.
+
+```ts
+{ button: { primaryCta: { bg: '#1a59ff', radius: '24px' },
+            secondaryCta:{ bg: '#fff',     radius: '8px' } } }
+```
+
+Component opts into a slot: `<Button themeKey="primaryCta" />`.
+
+**Pros**
+- Centralizes all overrides in one declarative object — close to how `config-driver` already thinks (path → value).
+- Designers/merchants reason about "slots", not props.
+
+**Cons**
+- Introduces a **new naming dimension** (slot keys) that must be invented, documented, and kept in sync across Blade + checkout. High coordination cost.
+- Indirection: the override lives far from the usage; harder to trace.
+- Still needs the *carrier* of Option B underneath (something must set the element vars). It's a sugar layer, not a mechanism.
+- Over-engineered for the current need (a handful of CTAs).
+
+**Scalability:** Good *if* an org commits to a slot taxonomy; otherwise sprawl. **Backward-compat:** Additive (✓). **Blade impact:** High — new cross-repo contract.
+
+> **Revised conclusion (see §4.5):** D's *global slot map* is over-engineered, but D's underlying instinct — **a named-parts dimension** — is **required** the moment overrides go beyond a top-level color (e.g. an Input's field vs. label vs. placeholder). We therefore **fold a *bounded, per-component* parts vocabulary into Option B** rather than reject D outright. We reject D's *centralized cross-repo slot taxonomy*; we keep its *parts addressing*, expressed locally as nested `styleOverrides` keys.
+
+---
+
+### Option E — `className` / `class` passthrough (let consumer style it)
+
+Expose `className`; consumer ships CSS (Tailwind/util classes) to override.
+
+**Pros**
+- Trivial to add; CVA's `getButtonClasses` already accepts `className`.
+- Infinitely flexible.
+
+**Cons**
+- **Specificity wars** with CSS-module rules + box-shadow-based borders; merchant overrides will silently lose or require `!important`.
+- **Banned on checkout**: V2 forbids `<style>` blocks / arbitrary CSS in SFCs; merchant config is data (hex strings), not classes. Doesn't map to `config-driver` at all.
+- Escapes the DS entirely → no governance, no dark-mode awareness, no tokens.
+
+**Scalability:** Poor (governance + specificity). **Backward-compat:** Additive (✓). **Blade impact:** Low to add, High to regret.
+
+---
+
+### 4.5 Extending B to internal parts (the "configure something internal" case)
+
+Button is the *easy* case: one element, one set of already-variable-ized accent props. The harder — and explicitly in-scope-for-the-future — case is **configuring an internal part of a composite component**, e.g. an Input where a merchant wants to set the *field* background, the *border* color, and the *placeholder* color independently. (Note: blade-svelte has **no `Input` component yet** — when it lands, this is the contract it should be built to.)
+
+A flat top-level `styleOverrides={{ backgroundColor }}` cannot express this — "which background, the field or the wrapper?" So **Option B's object must support named parts** (design axis E):
+
+```svelte
+<!-- Future Input -->
+<Input styleOverrides={{
+  field:       { backgroundColor: '#fff', borderColor: '#1a59ff' },
+  label:       { color: '#111' },
+  placeholder: { color: '#888' },
+}} />
+
+<!-- Card -->
+<Card styleOverrides={{
+  surface: { backgroundColor: '#fff' },   // targets .cardSurface (a CHILD), not root
+}} />
+```
+
+The **carrier is unchanged** — the resolver still returns `Record<cssVarName, value>` and the values are emitted as inline CSS vars — but they must land on (or cascade to) the **correct part element**, and each part exposes only a **bounded, typed** set of keys. This is the bounded slice of Option D we keep.
+
+#### The hidden precondition: a per-component "seam audit"
+
+Before any part can be overridden, that part's target property must be **expressed as a CSS variable on the right element**. Most components fail this today. Concrete audit of `Card` (`blade-core/src/styles/Card/card.module.css`):
+
+| Want to override | Reality in code | Seam work required |
+|---|---|---|
+| Card background | `.cardSurface` uses a **hardcoded `linear-gradient` of raw `hsla()`** (comment: raw palette colors that "don't exist as CSS custom properties") | Re-express gradient stops as `var(--card-surface-bg-*, <default>)`; non-trivial |
+| Card border color | Drawn via layered `inset box-shadow`, **not** `border-color` | Re-architect the box-shadow into per-channel color vars (like Button's `--btn-accent-border-*`) |
+| Target element | The styled element is `.cardSurface`, a **child** of `.cardRoot` | Override vars must be set on / inherited to the child, not the root |
+
+So the **unit of work per overridable property** is:
+1. ensure it's `var(--part-prop, <current default>)` on the correct part element (additive, backward-compat);
+2. map the override into that var in `resolve<Component>Overrides`;
+3. for **box-shadow borders / gradient backgrounds**, first re-architect the shadow/gradient into per-channel vars (the invasive step Button already paid).
+
+`--btn-radius` (§7) is the *simplest possible instance* of step 1. Card's background/border is the *expensive* instance (step 3). **This is the real adoption gradient** and the §5 matrix's "implementation cost" must be read per-component, not globally.
+
+**Extensibility contract (commitment):** growth = for each new overridable property, add (a) one typed key to that component/part's override type, and (b) if not already a variable, one `var(--x, <default>)` seam in its CSS module. `blade-core` exposes one pure `resolve<Component>Overrides(overrides) → Record<cssVar,value>` per component; Svelte/React just spread the result.
+
+#### How each option addresses internal parts (axis E)
+
+Line 136 (Option A's con) is "a flat top-level prop has no way to target an Input's placeholder vs. its field." Addressing a part needs two independent things: an **addressing** mechanism (the API can *name* the part) and a **carrier + seam** (the named value reaches the right sub-element, which must expose the property as a CSS variable — the seam audit above). The options differ only on the *addressing* half; the carrier/seam half is shared.
+
+| Option | How it names a part | Verdict for parts |
+|---|---|---|
+| **A** — visual styled props | Cannot. A flat top-level `backgroundColor` can't say *which* background (field vs. wrapper). | ✗ — this is the line-136 gap itself. |
+| **B** — `styleOverrides` (chosen) | **Nested keys**: the part is a key in the per-component object (`field`/`label`/`placeholder`/`surface`), each exposing a bounded, typed set; `resolve<Component>Overrides` emits each part's vars onto/cascading to the correct sub-element. | ✓ — local, bounded, typed. The "bounded slice of D we keep." |
+| **C** — scoped provider | By **semantic token** on a subtree wrapper, not by part. Overriding `interactive.background.primary.default` recolors *all* primary interactives in scope; it can't isolate one part if siblings resolve from the same token. | ~ — coarse; only works if a part maps 1:1 to an otherwise-unused token. |
+| **D** — slot-keyed map | The **slot key** *is* the part dimension (`<Input themeKey="field">`), looked up via context. Works, but invents a new naming dimension that must be documented and synced across Blade + checkout, and still needs B's carrier underneath ("sugar layer, not a mechanism"). | ~ — reject the centralized taxonomy; keep the parts-addressing instinct, folded into B as nested keys. |
+| **E** — `className` | Per-part **class hooks** (`.input-field`, `.input-placeholder`) the consumer styles with their own CSS / `::placeholder`. | ✗ — specificity wars vs. CSS-module + box-shadow rules; banned in checkout SFCs; escapes DS governance/tokens. |
+
+**The shared half (option-independent):** whichever option *names* the part, the value still has to land on a sub-element that exposes the property as a variable — the per-component seam audit. Card's `surface` is a *child* of root, and its gradient/box-shadow must first be re-expressed as per-channel vars (table above). No option escapes this: D reaches it via B's carrier, E via class hooks fighting specificity. **Addressing is necessary but not sufficient; the seam audit is the real enabling cost.**
+
+> Net: **B is the parts mechanism** (nested keys). D is the only other true parts mechanism, and B absorbs its good half locally without the cross-repo taxonomy. C is too coarse to isolate a single part; E is ungovernable and checkout-banned.
+
+---
+
+## 5. Comparison matrix
+
+| Criterion | A: Visual styled props | **B: styleOverrides → CSS vars** | C: Scoped provider | D: Slot-keyed map | E: className |
+|---|---|---|---|---|---|
+| Solves sibling instances (same page) | ✓ | ✓✓ | ✗ (needs wrapper each) | ✓ | ✓ |
+| Preserves interaction states (hover/disabled) | ✗ (proven broken in checkout §1.1) | ✓✓ (derives states) | ✓ | ✓ | ~ |
+| Addresses **internal parts** (axis E) | ✗ | ✓ (via nested keys, §4.5) | ~ (coarse, subtree only) | ✓✓ | ~ (specificity) |
+| Reactive to live editor edits | ✓ | ✓✓ (inline vars) | ✓ | ✓ | ~ |
+| Keeps class-first architecture | ~ | ✓✓ | ✓✓ | ✓ | ✗ |
+| Matches consumer vocabulary (opaque hex) | ✓ | ✓✓ | ~ (token-shaped) | ✓ | ✗ |
+| `blade-core` stays framework-agnostic | ✓ | ✓ | ✓ | ✓ | ✓ |
+| Maps cleanly to Config V2 output | ~ | ✓✓ | ~ | ✓ | ✗ |
+| Backward compatible | ✓ | ✓✓ | ✓ | ✓ | ✓ |
+| Bundle cost | Low | Low | Low | Med | Low |
+| Net new naming/coordination | Low | Low | Low | **High** | None |
+| Implementation cost | Low | **Low (Button) → Med/High (composites needing seam work, §4.5)** | Med | High | Low |
+
+---
+
+## 6. Recommendation
+
+**Adopt Option B as the core mechanism — carrier = inline element-scoped CSS vars, vocabulary = opaque hex passthrough with derived states, surface = top-level props growing into named parts (§4.5). Keep Option C as a complementary, later layer.**
+
+- **B (instance precision):** typed `styleOverrides` per component → element-scoped CSS variables, **state-aware by derivation** (the resolver synthesizes hover/disabled from the single base hex checkout sends). v1 ships **Button** and is a strict improvement over checkout's current inline-style CTA (§1.1).
+- **B extends to internals** via a bounded, per-component **parts** vocabulary (§4.5) — this is the part of Option D we keep. The future Input is the target case.
+- **C (region/brand):** a real `BladeProvider.svelte` that scopes variable overrides to a subtree, for "theme this whole surface" cases (festivities, co-brand drawers). Later phase.
+- Explicitly **reject E** (ungovernable; checkout forbids arbitrary CSS in SFCs and emits data, not classes) and **reject D's centralized cross-repo slot taxonomy** (premature, high coordination) — while **keeping D's parts-addressing** inside B. **A** is the shipped status quo we are replacing.
+
+This is the lowest-architecture-churn path *for Button*; for composite components the honest cost is the **per-component seam audit** (§4.5), which is the real gating work for full adoption.
+
+### Layering with Checkout (proposed — no wiring exists yet)
+
+> Checkout does **not** consume Blade today; the adapter row below is the proposed bridge, not shipped code.
+
+```
+merchant config (hex)                config-driver (sanitize + resolve, 6-step)
+ surface.contact.cta.primary.background ─────────────► getUIConfigColor() → '#1a59ff' | ''
+                                                              │
+                                  [PROPOSED] checkout adapter maps path → Blade styleOverrides
+                                                              ▼
+        <Button styleOverrides={{ backgroundColor: '#1a59ff', textColor }}/>
+                                                              ▼
+        blade-core resolver → { '--btn-accent-bg-default':'#1a59ff',
+                                 '--btn-accent-bg-highlighted': <derived>,  ← state synthesis
+                                 '--btn-accent-bg-disabled':    <derived> }
+                                                              ▼
+                          BaseButton emits style="--btn-accent-bg-default:#1a59ff; …"
+                                                              ▼
+                  CSS module rule paints only this instance — hover/disabled still work
+```
+
+Security stays in checkout (hex regex, sanitization). Blade treats v1 values as **opaque CSS strings** (no token validation in v1). Reminder (fact #6): `getUIConfigColor` only emits 6-digit hex; if other (non-checkout) consumers send arbitrary formats, Blade-side validation must be added then.
+
+---
+
+## 7. Proposed contract (sketch, for Phase 3)
+
+### v1 — Button (hex passthrough + derived states)
+
+`blade-core` (framework-agnostic):
+
+```ts
+// styles/Button/buttonOverrides.ts
+// v1 vocabulary: opaque string (a 6-digit hex from getUIConfigColor). NOT tokens yet.
+type ColorValue = string;
+
+export type ButtonStyleOverrides = Partial<{
+  backgroundColor: ColorValue;
+  textColor: ColorValue;
+}>;
+
+export function resolveButtonOverrides(
+  o: ButtonStyleOverrides | undefined
+): Record<string, string> {
+  if (!o) return {};
+  const vars: Record<string, string> = {};
+  if (o.backgroundColor) {
+    vars['--btn-accent-bg-default'] = o.backgroundColor;
+    // State synthesis is the core of v1 — checkout sends only the base color.
+    vars['--btn-accent-bg-highlighted'] = darken(o.backgroundColor, 0.08); // tinycolor
+    vars['--btn-accent-bg-disabled']    = alpha(o.backgroundColor, 0.5);
+  }
+  if (o.textColor) vars['--btn-content-color'] = o.textColor;
+  return vars;
+}
+```
+
+`blade-svelte`:
+
+```svelte
+const overrideVars = $derived(resolveButtonOverrides(styleOverrides));
+// style={ Object.entries(overrideVars).map(([k,v]) => `${k}:${v}`).join(';') }
+// Reactive: re-spreads when styleOverrides (a config Readable) changes → live editor.
+```
+
+### Later phases — extensions of the same resolver
+
+- **Explicit states / tokens (Phase 3c+):** widen `ColorValue` to `ColorTokenOrValue` and accept optional `backgroundColorHovered`/`Disabled`, resolving token strings via `getTokenCSSVariable`. Purely additive to `resolveButtonOverrides`.
+- **Radius (`--btn-radius`) — the simplest seam, but NOT an adoption blocker:**
+
+```css
+/* one-line, backward-compatible seam (matches button.module.css today) */
+.btn { border-radius: var(--btn-radius, var(--border-radius-small)); }
+.large { --btn-radius: var(--border-radius-medium); } /* preserves current default */
+```
+
+  ⚠️ **Checkout caveat:** checkout radius is a **global `rounded`/`sharp` enum**, not a per-instance value, and `sharp` emits `border-radius: 0px !important` (`checkout/app/v2/lib/theme.ts`). That `!important` would **override** a per-instance `--btn-radius`. So radius override (a) doesn't unblock any current checkout need and (b) collides with checkout's global rule — treat it as an *extensibility demonstration*, not Phase-3a work.
+
+- **Composite parts (Input/Card):** per §4.5 — nested override types + per-part seam audits. Each composite gets its own `resolve<Component>Overrides`.
+
+---
+
+## 8. Backward compatibility & migration
+
+- **Additive only.** `styleOverrides` is optional; absent → identical output. CSS uses `var(--x, <current default>)`, so unspecified instances render pixel-identical today.
+- **No global token rename**, no `data-theme` change.
+- **React/`blade-core`**: resolver is pure TS; React Blade can adopt later with zero forced change now.
+- **Checkout adoption is the goal, not a current dependency.** Nothing in checkout imports Blade yet; this contract is what makes the eventual swap a drop-in. When wired, it reuses checkout's existing `getUIConfigColor`/sanitization and adds no `<style>` blocks or bundle entry.
+
+## 9. Risks & mitigations
+
+| Risk | Mitigation |
+|------|------------|
+| `styleOverrides` becomes a freeform escape hatch | Typed keys only; no `CSSProperties` spread; lint rule |
+| **Override target property isn't a variable yet** (Card gradient bg, box-shadow borders) | Per-component **seam audit** (§4.5) before exposing keys; ship Button first (already variable-ized); treat seam work as DS-owned, scoped per component |
+| Merchant picks low-contrast bg/text (a11y) | Reuse `tinycolor` contrast checks (already a dep of `createTheme`) to warn/auto-pick foreground; checkout already sanitizes input |
+| State variants forgotten on override (hover looks wrong) | **v1 resolver derives hover/disabled from the base** (darken/alpha) — this is the default path, not a fallback (Option B, §4) |
+| Derived states are scheme-agnostic (don't adapt to dark mode) | Accepted for checkout (single scheme, dark mode de-scoped). For general Blade adoption, revisit per-scheme derivation — out of v1 scope |
+| Composite parts addressed by the wrong element | Parts contract maps each key to a specific part element; vars set on / inherited to that child (§4.5) |
+| Specificity / `!important` collisions | Override via the *same* custom props the module already reads (no new selectors). Note checkout's global `sharp` radius rule uses `!important` and would beat `--btn-radius` (§7) |
+
+## 10. Phased rollout
+
+1. **Phase 3a — Button reference impl:** `ButtonStyleOverrides` (`backgroundColor`/`textColor`, hex passthrough) + `resolveButtonOverrides` with **state derivation** in `blade-core`; `styleOverrides` prop on `BaseButton`; stories + tests (incl. hover/disabled snapshots); contrast guard. *(Radius seam optional/demo only — see §7 caveat.)*
+2. **Phase 3b — Checkout adoption bridge:** adapter mapping Config V2 CTA values (`getUIConfigColor`) → `styleOverrides`; swap the Contact CTA `Button` to Blade and verify it fixes the §1.1 state regression.
+3. **Phase 3c — Generalize + first composite:** extract shared `resolve*Overrides` helper; widen vocabulary (optional tokens/explicit states); run the **first composite seam audit** (Input when it exists, or Card) per §4.5.
+4. **Phase 3d — `BladeProvider.svelte` (Option C):** subtree token scoping for surface/brand theming.
+5. **Phase 4 — Governance:** lint rules, docs, contrast tooling, Studio playground integration.
+
+---
+
+## 11. Open questions
+
+- **Vocabulary growth:** v1 is hex-only passthrough. When do we add token support / explicit per-state keys? (Recommendation: only when a *consumer other than checkout* needs it, since `getUIConfigColor` is hex-only.)
+- **Derivation rule:** what exact `darken`/`alpha` offsets keep derived hover/disabled both WCAG-safe and visually consistent with Blade's existing `highlighted`/`disabled` token steps? (Needs a defined spec + snapshot baseline before 3a.)
+- **First composite target:** build Input fresh to the §4.5 parts contract, or retrofit Card first to prove the seam-audit cost? 
+- **Responsive overrides:** should `styleOverrides` accept responsive objects like styled props? (Defer; CTAs aren't responsive-styled today.)
+- **Naming:** `styleOverrides` vs `themeOverrides` vs `appearance`. (Leaning `styleOverrides`.)
diff --git a/packages/blade-svelte/docs/styling-approaches-categorised.md b/packages/blade-svelte/docs/styling-approaches-categorised.md
new file mode 100644
index 00000000000..c19437af3ae
--- /dev/null
+++ b/packages/blade-svelte/docs/styling-approaches-categorised.md
@@ -0,0 +1,83 @@
+# Instance-Level Styling — Approaches, Categorised
+
+> Companion to `instance-level-styling-proposal.md`. A compact mental model: factor
+> every approach into **two independent questions**, which reveals that several
+> "options" are the same mechanism in different syntax.
+
+## The two questions
+
+1. **Selector hook** — what does the consumer put on the element so styles can reach it?
+   (a prop value, a class, an attribute, a wrapper, or nothing)
+2. **Value source** — where do the override values live, and who authors them?
+   (a typed prop the component resolves, an authored stylesheet, a central map)
+
+> A common shape for selector-based options:
+> *"a selector hook the consumer puts on the element, plus a stylesheet the consumer authors that targets that hook."*
+
+## All approaches, factored
+
+| Approach | Selector hook | Value source | Carrier (what applies the value) |
+|---|---|---|---|
+| **A** — visual styled props | none (prop → inline `style`) | typed prop on instance | inline style → **final property** (`background-color`) |
+| **B** — `styleOverrides` | none (prop → inline CSS vars) | typed prop; resolver derives states | inline style → **element-scoped CSS vars** |
+| **C** — `BladeProvider` | **wrapper element** | token-override object on provider | vars re-declared on wrapper → cascade |
+| **D** — slot-keyed map | **slot key** prop, read via context | central **theme map** (slot → values) | resolves to B's vars underneath |
+| **E** — `className` | **class** on element | **stylesheet authored by consumer** | author's choice: final property *or* vars |
+| **F** — `data-*` attribute | **attribute** on element | **stylesheet authored by consumer** | author's choice: final property *or* vars |
+
+## Two families
+
+**Family 1 — values travel *with* the instance (prop-carried): A, B, D**
+Consumer hands Blade a value (or a key → value); Blade resolves and writes the carrier.
+No external stylesheet. Maps cleanly to config data (hex strings).
+- A vs B differ **only in carrier** (final property vs vars) → why A breaks hover/disabled and B doesn't.
+- D is B + indirection (key → value via a central map).
+
+**Family 2 — values live in a stylesheet; instance only carries a hook (selector-carried): C, E, F**
+Consumer puts a hook on the element and authors CSS elsewhere.
+- C, E, F differ **only in hook syntax**: wrapper (C) / class (E) / attribute (F).
+- Shared limits: values are authored CSS not data → poor Config-V2 fit, `<style>`-ban friction in checkout SFCs, manual state authoring (unless states are generated via `deriveColorStates`).
+
+## Scope (independent dial)
+
+- **Instance-only:** A, B; E/F with an exact selector.
+- **Subtree / region:** C (wrapper); E/F with a descendant selector.
+- **Centralised / global map:** D.
+
+## Collapsed view — three distinct mechanisms
+
+1. **Prop → final property** (A) — per-instance; writes the final property directly, so interaction states (hover/disabled) aren't expressed unless each is passed explicitly.
+2. **Prop → CSS vars, component-resolved** (B; D = B + central map) — per-instance; values are data, component resolves/derives states.
+3. **Hook → authored stylesheet** (C / E / F) — region/static theming; **C, E, F are wrapper- / class- / attribute-flavoured spellings of the same idea**.
+
+## Takeaways
+
+- **E ≡ F** — `className` and `data-*` are the same mechanism; only the hook syntax differs. A var-only `className` neutralises E's specificity con.
+- **C, E, F** are one mechanism (selector-carried theming) at different scopes/syntaxes.
+- **A, B, D** carry values as data on the instance; **C, E, F** carry a hook and rely on authored CSS. Which family fits depends on whether overrides arrive as **data** (e.g. config hex) or as **authored stylesheets**, and whether the scope is **per-instance** or **per-region**.
+
+---
+
+## Worked example — `TextInput` / `PhoneInput`
+
+A composite input is the real test: merchants want to style **internal parts** independently,
+e.g. **field bg**, **border** (default/focus/error), **label**, **placeholder**, **prefix/leading**
+(country code `+91`), and **helper/error text** — not one flat color.
+
+> Precondition for **all** approaches: each part must already expose its property as a
+> `var(--…)` on the right sub-element (the per-component **seam audit**, proposal §4.5).
+> Addressing a part is necessary but not sufficient — no approach escapes this.
+
+| Approach | Express it as | Tradeoff for a composite input |
+|---|---|---|
+| **A** — visual styled props | `<TextInput backgroundColor=… />` | Simple, per-instance. A flat top-level prop can't say *which* part (field vs wrapper) and can't reach placeholder/border-focus; states aren't expressed unless passed per state. |
+| **B** — `styleOverrides` | `styleOverrides={{ field:{ backgroundColor, borderColor }, placeholder:{ color }, label:{ color } }}` | Named keys per part, typed + bounded; values are data; resolver can derive focus/error from base; reactive to live config. Cost: typed parts contract + seam audit per part. |
+| **C** — `BladeProvider` | wrap subtree, override `interactive.border.*` tokens | One wrapper themes all inputs in scope; no per-part schema. Coarse: recolors *every* input/interactive in scope, can't isolate one field's placeholder; siblings sharing a token can't differ. |
+| **D** — slot-keyed map | `<TextInput themeKey="phoneField" />` + central map | Centralises overrides in one declarative map (close to `config-driver`'s path→value). Cost: invents a slot taxonomy to document + sync; indirection from usage; still needs a vars carrier underneath. |
+| **E** — `className` | `class="m-phone"` + author `.m-phone ::placeholder{…}` | Infinitely flexible; reaches any part via selectors. Author hand-writes every part/state; specificity vs CSS-module + `::placeholder`; `<style>` banned in checkout SFCs; values are CSS, not config data. |
+| **F** — `data-*` | `data-blade-style="phone"` + author `[…] [data-part=field]{…}` | Same capability/cost as E (≡ E) — attribute hook instead of class; intent-signalling name + var-only discipline can avoid specificity wars. Still authored CSS, not config data. |
+
+**Reading it:** approaches that name a part *and* accept values as data (A, B, D) map directly to a
+per-part config source like `getUIConfigColor`; selector-carried ones (C, E, F) excel at theming a
+whole region/many inputs at once but express per-field, per-part merchant data less directly. Pick
+along those two axes (data vs authored-CSS, per-instance vs per-region) for the case at hand.
diff --git a/packages/blade-svelte/docs/theming-and-classnames.md b/packages/blade-svelte/docs/theming-and-classnames.md
new file mode 100644
index 00000000000..0d2e31620a5
--- /dev/null
+++ b/packages/blade-svelte/docs/theming-and-classnames.md
@@ -0,0 +1,153 @@
+# Theming & Class Names in blade-svelte
+
+## ThemeProvider
+
+React Blade wraps the app in a `<BladeProvider>` component. blade-svelte has **no ThemeProvider component** — theming is handled entirely through CSS variables and HTML attributes.
+
+### How it works
+
+`@razorpay/blade-core/tokens/theme.css` declares all design tokens as CSS custom properties on `:root`. Components consume these variables directly.
+
+```ts
+// src/main.ts or src/routes/+layout.svelte
+import '@razorpay/blade-core/tokens/theme.css';
+import '@razorpay/blade-core/fonts.css';
+```
+
+That single import is the equivalent of mounting `<BladeProvider>`.
+
+### Dark mode
+
+Set `data-theme="dark"` on `<body>` (or any ancestor). The theme CSS uses attribute selectors to override tokens:
+
+```svelte
+<script>
+  let isDark = $state(false);
+
+  function toggleTheme() {
+    isDark = !isDark;
+    document.body.setAttribute('data-theme', isDark ? 'dark' : 'light');
+  }
+</script>
+
+<button onclick={toggleTheme}>Toggle theme</button>
+```
+
+A convenience `ThemeSwitcher.svelte` component does the same and is available for storybook/dev use.
+
+### White labelling
+
+Use `createTheme()` from `@razorpay/blade-core` to generate a custom theme, then inject the resulting CSS variables into the document:
+
+```ts
+import { createTheme } from '@razorpay/blade-core/tokens/theme';
+
+const theme = createTheme({ brandColor: '#your-brand-hex' });
+
+// Apply CSS variables to :root
+Object.entries(theme.cssVariables).forEach(([key, value]) => {
+  document.documentElement.style.setProperty(key, value);
+});
+```
+
+---
+
+## Class Names
+
+### Component styles: CVA + CSS Modules
+
+Component visual variants are defined in `blade-core` using [class-variance-authority (CVA)](https://cva.style/docs):
+
+```ts
+// packages/blade-core/src/styles/Button/button.ts
+import { cva } from 'class-variance-authority';
+
+export const buttonClasses = cva(baseClass, {
+  variants: {
+    variant: { primary: '...', secondary: '...' },
+    size: { medium: '...', large: '...' },
+  },
+  defaultVariants: { variant: 'primary', size: 'medium' },
+});
+```
+
+The Svelte component calls the getter and applies the result:
+
+```svelte
+<!-- BaseButton.svelte -->
+<script lang="ts">
+  import { getButtonClasses } from '@razorpay/blade-core/styles';
+
+  const buttonClass = $derived(
+    getButtonClasses({ variant, color, size, isDisabled, isFullWidth, isIconOnly })
+  );
+</script>
+
+<button class={buttonClass} ...>
+  <slot />
+</button>
+```
+
+### Tree-shaking guard
+
+Svelte's compiler tree-shakes CSS classes that only appear in template expressions (not in `<style>`). Each style module exports a `get*TemplateClasses()` function that references all dynamic classes to prevent this:
+
+```ts
+// In your component — call once at module level
+void getButtonTemplateClasses();
+```
+
+Without this, classes assigned via `$derived` expressions get stripped from the CSS bundle.
+
+### Styled props: `getStyledPropsClasses`
+
+Components accept layout props (`margin`, `display`, `position`, etc.) as styled props. These are converted to utility class names at runtime:
+
+```ts
+import { getStyledPropsClasses } from '@razorpay/blade-core/utils';
+
+const { classes, inlineStyles } = getStyledPropsClasses(styledProps);
+```
+
+**Spacing tokens** (`spacing.0`–`spacing.11`) map to utility classes:
+
+| Prop | Token | Class |
+|------|-------|-------|
+| `marginTop="spacing.4"` | `spacing.4` | `margin-top-spacing-4` |
+| `marginX="spacing.2"` | `spacing.2` | `margin-x-spacing-2` |
+| `display="flex"` | — | `display-flex` |
+
+**Arbitrary values** (e.g. `marginTop="12px"`) can't map to a class, so they fall back to `inlineStyles` and are applied via the `style` attribute.
+
+Apply both in the template:
+
+```svelte
+<div
+  class={[...componentClasses, ...styledPropsClasses.classes].join(' ')}
+  style={Object.entries(styledPropsClasses.inlineStyles)
+    .map(([k, v]) => `${k}:${v}`)
+    .join(';')}
+>
+```
+
+### Responsive values
+
+All styled props accept a responsive object:
+
+```svelte
+<Alert marginTop={{ base: 'spacing.2', m: 'spacing.4' }} />
+```
+
+`getStyledPropsClasses` accepts an optional `breakpoint` parameter and resolves the correct value for that breakpoint. The base breakpoint is used server-side / for SSR.
+
+---
+
+## Summary
+
+| Concept | React Blade | blade-svelte |
+|---------|------------|-------------|
+| Theme setup | `<BladeProvider>` | Import `theme.css` |
+| Dark mode | `colorScheme` prop | `data-theme="dark"` on body |
+| White labelling | `createTheme` + `BladeProvider` | `createTheme` + inject CSS vars |
+| Component variants | styled-components | CVA + CSS Modules |
+| Layout props | styled-system via emotion | `getStyledPropsClasses` |
diff --git a/packages/blade-svelte/src/components/BladeProvider/BladeProvider.svelte b/packages/blade-svelte/src/components/BladeProvider/BladeProvider.svelte
new file mode 100644
index 00000000000..344bc433ed1
--- /dev/null
+++ b/packages/blade-svelte/src/components/BladeProvider/BladeProvider.svelte
@@ -0,0 +1,48 @@
+<script lang="ts">
+  import type { Snippet } from 'svelte';
+  import {
+    flattenThemeOverridesToVars,
+    styleObjectToString,
+    type ThemeOverrideTree,
+    type SlotThemeMap,
+  } from '@razorpay/blade-core/styles';
+  import { setSlotThemeContext } from './bladeProviderContext';
+
+  /**
+   * BladeProvider — instance-level styling Options C & D (evaluation surfaces).
+   *
+   * **Option C (scoped theme):** `themeOverrides` is a partial, nested token tree
+   * (same shape as Blade tokens). It is flattened to CSS variables and declared on
+   * THIS wrapper element, so every Blade component inside inherits the override via
+   * the natural CSS cascade — without repainting `:root`. Great for region/brand
+   * theming ("make this whole drawer festive").
+   *
+   * **Option D (slot-keyed map):** `slotTheme` is published via context; components
+   * opt in with a `themeKey` and resolve against it. Included for comparison — the
+   * recommendation rejects the centralized taxonomy in favor of Option B's nested
+   * `styleOverrides`.
+   *
+   * Recommended default remains Option B (per-instance `styleOverrides`, no provider
+   * needed). See instance-level-styling-proposal §4 (Options C, D) and §6.
+   */
+  let {
+    themeOverrides,
+    slotTheme,
+    children,
+  }: {
+    themeOverrides?: ThemeOverrideTree;
+    slotTheme?: SlotThemeMap;
+    children: Snippet;
+  } = $props();
+
+  // Option C: flatten the token override tree into scoped CSS variables.
+  const scopedVars = $derived(flattenThemeOverridesToVars(themeOverrides));
+  const scopedStyle = $derived(styleObjectToString(scopedVars));
+
+  // Option D: publish the slot-keyed theme map to descendants (getter for reactivity).
+  setSlotThemeContext(() => slotTheme);
+</script>
+
+<div data-blade-component="blade-provider" style={scopedStyle}>
+  {@render children()}
+</div>
diff --git a/packages/blade-svelte/src/components/BladeProvider/bladeProviderContext.ts b/packages/blade-svelte/src/components/BladeProvider/bladeProviderContext.ts
new file mode 100644
index 00000000000..d56972320a1
--- /dev/null
+++ b/packages/blade-svelte/src/components/BladeProvider/bladeProviderContext.ts
@@ -0,0 +1,31 @@
+import { getContext, setContext } from 'svelte';
+import type { SlotThemeMap } from '@razorpay/blade-core/styles';
+
+/**
+ * Context plumbing for the two *map-based* instance-styling options:
+ *
+ *  - **Option C** (scoped theme provider): the provider re-declares token CSS
+ *    variables on its wrapper element, so components inherit purely via the CSS
+ *    cascade — no JS lookup needed. The provider still publishes the override tree
+ *    here for completeness / introspection.
+ *  - **Option D** (slot-keyed theme map): components call `getSlotThemeMap()` and
+ *    resolve their `themeKey` against the map (via `resolveSlotTheme`).
+ *
+ * Both are evaluation surfaces; the recommended path is Option B's per-instance
+ * `styleOverrides` (no context required). See instance-level-styling-proposal.
+ */
+
+const SLOT_THEME_CONTEXT_KEY = 'blade-slot-theme-context';
+
+/** Provide the Option D slot-keyed theme map to descendants. */
+export function setSlotThemeContext(getMap: () => SlotThemeMap | undefined): void {
+  setContext(SLOT_THEME_CONTEXT_KEY, getMap);
+}
+
+/** Read the nearest Option D slot-keyed theme map (undefined if no provider). */
+export function getSlotThemeMap(): SlotThemeMap | undefined {
+  const getter = getContext<(() => SlotThemeMap | undefined) | undefined>(
+    SLOT_THEME_CONTEXT_KEY,
+  );
+  return getter?.();
+}
diff --git a/packages/blade-svelte/src/components/BladeProvider/index.ts b/packages/blade-svelte/src/components/BladeProvider/index.ts
index 98791d9ff88..57a1a36540f 100644
--- a/packages/blade-svelte/src/components/BladeProvider/index.ts
+++ b/packages/blade-svelte/src/components/BladeProvider/index.ts
@@ -1 +1,3 @@
 export type { Theme } from './types';
+export { default as BladeProvider } from './BladeProvider.svelte';
+export { setSlotThemeContext, getSlotThemeMap } from './bladeProviderContext';
diff --git a/packages/blade-svelte/src/components/Button/BaseButton/BaseButton.svelte b/packages/blade-svelte/src/components/Button/BaseButton/BaseButton.svelte
index 6a3e6ea56b4..8c81b4e47e6 100644
--- a/packages/blade-svelte/src/components/Button/BaseButton/BaseButton.svelte
+++ b/packages/blade-svelte/src/components/Button/BaseButton/BaseButton.svelte
@@ -6,6 +6,7 @@
   import type { BaseButtonProps } from './types';
   import type { TextColors } from '../../Typography/BaseText/types';
   import { getStyledPropsClasses } from '@razorpay/blade-core/utils';
+  import { resolveVisualStyledProps } from '@razorpay/blade-core/utils';
   import {
     getButtonClasses,
     getButtonTemplateClasses,
@@ -14,9 +15,13 @@
     getButtonSpinnerSize,
     getButtonIconSize,
     getButtonIconOnlySize,
+    resolveButtonOverrides,
+    resolveSlotTheme,
+    styleObjectToString,
     type ActionStatesType as ButtonActionStatesType,
     type SpinnerColor,
   } from '@razorpay/blade-core/styles';
+  import { getSlotThemeMap } from '../../BladeProvider/bladeProviderContext';
   import type { IconColor } from '../../Icons/types';
 
   // Get template classes via function call to prevent Svelte tree-shaking
@@ -40,6 +45,10 @@
     tabIndex,
     accessibilityProps,
     testID,
+    styleOverrides,
+    visualProps,
+    themeKey,
+    className,
     onClick,
     onBlur,
     onFocus,
@@ -55,6 +64,22 @@
     ...rest
   }: BaseButtonProps = $props();
 
+  // ===== Instance-level styling (Options A–E) =====
+  // Option D: resolve this button's slot from the nearest BladeProvider slotTheme.
+  const slotThemeMap = getSlotThemeMap();
+  const slotOverrideVars = $derived(resolveSlotTheme(slotThemeMap, 'button', themeKey));
+  // Option B: per-instance styleOverrides → element-scoped CSS vars (derived states).
+  const instanceOverrideVars = $derived(resolveButtonOverrides(styleOverrides));
+  // B and D share the same carrier; instance styleOverrides win over the slot map.
+  const overrideVars = $derived({ ...slotOverrideVars, ...instanceOverrideVars });
+  // Option A: flat visual styled props → inline styles (state-unaware, for compare).
+  const visualInlineStyles = $derived(resolveVisualStyledProps(visualProps));
+  // True when text color is being overridden (B/D var or A's `color`) — the text/icon
+  // must then inherit via `currentColor` so the override actually paints them.
+  const hasContentColorOverride = $derived(
+    Boolean(overrideVars['--btn-content-color']) || Boolean(visualInlineStyles.color),
+  );
+
   // Validation - check if we have either icon or children
   $effect(() => {
     if (typeof window !== 'undefined' && window.location.hostname === 'localhost') {
@@ -119,8 +144,13 @@
   // Get text sizes
   const textSizes = getButtonTextSizes();
 
-  // Compute text color token reactively
-  const textColorToken = $derived.by((): TextColors => {
+  // Compute text color token reactively.
+  // When a text-color override is active (Option A/B/D), defer to `currentColor`
+  // so the text inherits the overridden color set on the button element.
+  const textColorToken = $derived.by((): TextColors | 'currentColor' => {
+    if (hasContentColorOverride) {
+      return 'currentColor';
+    }
     return getButtonTextColorToken({
       variant,
       color,
@@ -129,8 +159,11 @@
     }) as TextColors;
   });
 
-  // Compute icon color token reactively
+  // Compute icon color token reactively (same currentColor deferral as text).
   const iconColorToken = $derived.by((): IconColor => {
+    if (hasContentColorOverride) {
+      return 'currentColor';
+    }
     return getButtonTextColorToken({
       variant,
       color,
@@ -206,7 +239,7 @@
   // Extract styled props
   const styledProps = $derived(getStyledPropsClasses(rest));
 
-  // Combine classes for button element
+  // Combine classes for button element (Option E appends a raw className passthrough).
   const combinedClasses = $derived(() => {
     const classes = [
       baseButtonClasses,
@@ -216,9 +249,25 @@
     if (styledProps.classes) {
       classes.push(...styledProps.classes);
     }
+    if (className) {
+      classes.push(className);
+    }
     return classes.filter(Boolean).join(' ');
   });
 
+  // Combine the inline style for the button element:
+  //  - styled-props arbitrary values (existing behavior, e.g. numeric zIndex/margins)
+  //  - Option A visual inline styles (background-color/color/border written directly)
+  //  - Option B/D override CSS variables (state-aware, the recommended carrier)
+  // Override vars are emitted last so they take precedence over A on the same concern.
+  const combinedInlineStyle = $derived(
+    styleObjectToString({
+      ...styledProps.inlineStyles,
+      ...visualInlineStyles,
+      ...overrideVars,
+    }),
+  );
+
   // Animated content wrapper classes (for scale animation)
   const animatedContentClasses = $derived(() => {
     const classes = [
@@ -339,6 +388,7 @@
 <svelte:element
   this={elementTag}
   class={combinedClasses()}
+  style={combinedInlineStyle}
   {id}
   {...accessibilityAttrs}
   {...metaAttrs}
diff --git a/packages/blade-svelte/src/components/Button/BaseButton/types.ts b/packages/blade-svelte/src/components/Button/BaseButton/types.ts
index bb2bc03ced4..68983c25795 100644
--- a/packages/blade-svelte/src/components/Button/BaseButton/types.ts
+++ b/packages/blade-svelte/src/components/Button/BaseButton/types.ts
@@ -1,11 +1,41 @@
 import type { Snippet, Component } from 'svelte';
 import type { StyledPropsBlade } from '@razorpay/blade-core/utils';
+import type { VisualStyledProps } from '@razorpay/blade-core/utils';
+import type { ButtonStyleOverrides } from '@razorpay/blade-core/styles';
 import type { IconProps } from '../../Icons/types';
 
 // Icon component type - Svelte component that accepts IconProps
 export type IconComponent = Component<IconProps>;
 
 export interface BaseButtonProps extends StyledPropsBlade {
+  /**
+   * **Instance-level styling — Option B (recommended).**
+   * Bounded, typed per-instance visual overrides mapped to element-scoped CSS
+   * variables. Interaction states (hover/active/focus/disabled) are *derived* from
+   * the base color, so an override keeps working states. Reactive — re-spreads when
+   * the object changes (e.g. a live config editor).
+   *
+   * @example
+   * <Button styleOverrides={{ backgroundColor: '#1a59ff', textColor: '#ffffff' }} />
+   */
+  styleOverrides?: ButtonStyleOverrides;
+  /**
+   * **Instance-level styling — Option A (evaluation only).**
+   * Flat visual styled props written straight to inline styles. ⚠️ State-unaware:
+   * a `backgroundColor` here dead-ends hover/disabled. Prefer `styleOverrides`.
+   */
+  visualProps?: VisualStyledProps;
+  /**
+   * **Instance-level styling — Option D (evaluation only).**
+   * Opts this button into a slot in a `BladeProvider`'s `slotTheme.button` map.
+   */
+  themeKey?: string;
+  /**
+   * **Instance-level styling — Option E (evaluation only).**
+   * Raw class passthrough. ⚠️ Specificity wars vs CSS-module rules; banned in
+   * checkout SFCs. Included for comparison.
+   */
+  className?: string;
   children?: Snippet | string;
   icon?: IconComponent;
   iconPosition?: 'left' | 'right';
diff --git a/packages/blade-svelte/src/components/Button/StyleOverrides.stories.svelte b/packages/blade-svelte/src/components/Button/StyleOverrides.stories.svelte
new file mode 100644
index 00000000000..495202f54fb
--- /dev/null
+++ b/packages/blade-svelte/src/components/Button/StyleOverrides.stories.svelte
@@ -0,0 +1,1246 @@
+<script module>
+  import { defineMeta } from '@storybook/addon-svelte-csf';
+  import Button from './Button.svelte';
+  import Card from '../Card/Card.svelte';
+  import CardBody from '../Card/CardBody.svelte';
+  import BladeProvider from '../BladeProvider/BladeProvider.svelte';
+  import Text from '../Typography/Text/Text.svelte';
+  import Heading from '../Typography/Heading/Heading.svelte';
+  // Import the REAL resolvers so the interactive stories below show the actual
+  // blade-core output (not a copy) — these are the same functions the components run.
+  import {
+    resolveButtonOverrides,
+    resolveSlotTheme,
+    flattenThemeOverridesToVars,
+  } from '@razorpay/blade-core/styles';
+
+  /**
+   * Instance-level styling — A/B/C/D/E side-by-side.
+   *
+   * These stories are the concrete reference for the RFC at
+   * `docs/instance-level-styling-proposal.md`. Each story maps 1:1 to an option so
+   * the team can compare them in the browser (especially hover/disabled behaviour).
+   *
+   * Each option has an **Interactive** story driven by the Storybook Controls panel:
+   * change `backgroundColor` / `textColor` / `borderRadius` / `isDisabled` and watch
+   * the real component + the resolved CSS variables update live.
+   *
+   * TL;DR recommendation: **Option B** (`styleOverrides` → element-scoped CSS vars
+   * with derived states) is the core; **Option C** (`BladeProvider`) is the
+   * complementary region/brand layer. A/D/E are shown for evaluation only.
+   */
+  const { Story } = defineMeta({
+    title: 'Patterns/Instance-Level Styling',
+    component: Button,
+    // Shared interactive controls for every *Interactive* story below. These flat
+    // args stand in for a merchant's getUIConfigColor() output; the stories map
+    // them onto each option's real prop/config shape.
+    args: {
+      label: 'Pay now',
+      backgroundColor: '#7c3aed',
+      textColor: '#ffffff',
+      borderColor: '',
+      borderRadius: '8px',
+      isDisabled: false,
+    },
+    argTypes: {
+      label: { control: 'text', description: 'Button text' },
+      backgroundColor: {
+        control: 'color',
+        description: 'Base background (one hex; hover/disabled are DERIVED from it)',
+      },
+      textColor: { control: 'color', description: 'Text + icon color' },
+      borderColor: {
+        control: 'color',
+        description: 'Base border color (highlighted border derived). Leave empty to skip.',
+      },
+      borderRadius: { control: 'text', description: 'Any CSS length, e.g. 24px' },
+      isDisabled: { control: 'boolean', description: 'Toggle to see the derived disabled state' },
+    },
+    parameters: {
+      // Only surface the flat args we actually wire into the *Interactive*
+      // stories. Without this, `component: Button` auto-infers every Button
+      // prop as a (dead) control, drowning the 6 knobs that do anything.
+      controls: {
+        include: ['label', 'backgroundColor', 'textColor', 'borderColor', 'borderRadius', 'isDisabled'],
+      },
+      docs: {
+        description: {
+          component:
+            'Reference implementations for the instance-level styling RFC. ' +
+            'Compare Option A (flat inline style — breaks hover/disabled) against ' +
+            'Option B (styleOverrides — derives working states). C = scoped ' +
+            'BladeProvider, D = slot-keyed map, E = className passthrough. ' +
+            'The *Interactive* stories expose live Controls.',
+        },
+      },
+    },
+  });
+
+  // The single base color a merchant would send via checkout's getUIConfigColor()
+  // (always a 6-digit hex). Every static option below is fed THIS one value.
+  const MERCHANT_BG = '#7c3aed';
+  const MERCHANT_TEXT = '#ffffff';
+
+  // Option D — a slot-keyed theme map (would live once, app-level, in a provider).
+  const slotTheme = {
+    button: {
+      primaryCta: { backgroundColor: MERCHANT_BG, textColor: MERCHANT_TEXT },
+      secondaryCta: { backgroundColor: '#0ea5e9', textColor: '#ffffff', borderRadius: '4px' },
+    },
+  };
+
+  // Option C — a partial token override tree scoping a whole subtree.
+  const festiveTheme = {
+    interactive: {
+      background: {
+        primary: { default: MERCHANT_BG, highlighted: '#6d28d9' },
+      },
+    },
+  };
+
+  // ---- Helpers for the Interactive stories -------------------------------------
+  // Build a Button styleOverrides object from the flat Controls args, dropping
+  // empty strings (mirrors how a merchant only sets the slots they care about).
+  function argsToStyleOverrides(args) {
+    const o = {};
+    if (args.backgroundColor) o.backgroundColor = args.backgroundColor;
+    if (args.textColor) o.textColor = args.textColor;
+    if (args.borderColor) o.borderColor = args.borderColor;
+    if (args.borderRadius) o.borderRadius = args.borderRadius;
+    return o;
+  }
+  // Pretty-print any resolver's output for the live readout panel.
+  function showVars(vars) {
+    const entries = Object.entries(vars);
+    if (entries.length === 0) return '(no overrides — renders the default token look)';
+    return entries.map(([k, v]) => `${k}: ${v};`).join('\n');
+  }
+
+  // =================================================================
+  // Consuming-app (checkout) snippets — verbatim source for the buy-in
+  // walkthrough. These files live in the `checkout` repo (proposed), not
+  // here; they're rendered as read-only code so the team can see the FULL
+  // wrapper/component API surface a consumer touches end-to-end.
+  // =================================================================
+
+  // The shipped anti-pattern today (proposal §1.1): config color written
+  // straight to `style` → dead-ends hover/disabled.
+  const CHECKOUT_BEFORE = `<!-- checkout/app/v2/modules/contact/components/Contact.svelte (TODAY) -->
+<script lang="ts">
+  import { Button } from 'blade-checkout-shim';
+  import { useUIConfigColor } from '$lib/config-driver';
+  import { CONFIG_PATHS } from '$lib/config-driver/paths';
+
+  const ctaBg$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_BG);
+  const ctaText$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_TEXT_COLOR);
+<\/script>
+
+<!-- Flat inline style. The merchant hex shadows the token classes, so
+     :hover / :active / [disabled] backgrounds are gone. (Option A) -->
+<Button
+  style={\`\${$ctaBg$ ? \`background:\${$ctaBg$};\` : ''}\${
+    $ctaText$ ? \`color:\${$ctaText$};\` : ''
+  }\`}
+>
+  Continue
+</Button>`;
+
+  // After adoption: same config inputs, but routed through a typed
+  // styleOverrides object → derived states (proposal §6 layering diagram).
+  const CHECKOUT_AFTER = `<!-- checkout/app/v2/modules/contact/components/Contact.svelte (AFTER) -->
+<script lang="ts">
+  import { Button } from '@razorpay/blade-svelte';
+  import { useUIConfigColor } from '$lib/config-driver';
+  import { CONFIG_PATHS } from '$lib/config-driver/paths';
+
+  // Same live Readables as before — no config-driver change.
+  const ctaBg$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_BG);
+  const ctaText$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_TEXT_COLOR);
+
+  // Map config paths → Blade's typed override shape. Empty hex ('') is
+  // dropped so unset slots fall back to the default token look.
+  const ctaOverrides = $derived({
+    ...($ctaBg$ ? { backgroundColor: $ctaBg$ } : {}),
+    ...($ctaText$ ? { textColor: $ctaText$ } : {}),
+  });
+<\/script>
+
+<!-- One typed prop. blade-core derives hover/active/focus/disabled from
+     the base hex, so states keep working. (Option B) -->
+<Button styleOverrides={ctaOverrides}>Continue</Button>`;
+
+  // The reusable adapter — the only net-new code a consumer writes.
+  // Security/sanitization stay in config-driver; this is a pure shape map.
+  const CHECKOUT_ADAPTER = `// checkout/app/v2/utils/blade-adapter/toButtonOverrides.ts
+import type { ButtonStyleOverrides } from '@razorpay/blade-core/styles';
+
+/**
+ * Map config-driver CTA color outputs → Blade Button styleOverrides.
+ * getUIConfigColor() returns a 6-digit hex or '' (proposal fact #6),
+ * so we just drop empties; Blade derives the interaction states.
+ */
+export function toButtonOverrides(input: {
+  background?: string;
+  textColor?: string;
+  borderColor?: string;
+  borderRadius?: string;
+}): ButtonStyleOverrides {
+  const o: ButtonStyleOverrides = {};
+  if (input.background) o.backgroundColor = input.background;
+  if (input.textColor) o.textColor = input.textColor;
+  if (input.borderColor) o.borderColor = input.borderColor;
+  if (input.borderRadius) o.borderRadius = input.borderRadius;
+  return o;
+}`;
+
+  // Consumer usage of the adapter inside a component.
+  const CHECKOUT_ADAPTER_USAGE = `<script lang="ts">
+  import { Button } from '@razorpay/blade-svelte';
+  import { toButtonOverrides } from '$lib/utils/blade-adapter/toButtonOverrides';
+  import { useUIConfigColor } from '$lib/config-driver';
+  import { CONFIG_PATHS } from '$lib/config-driver/paths';
+
+  const bg$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_BG);
+  const text$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_TEXT_COLOR);
+
+  const overrides = $derived(
+    toButtonOverrides({ background: $bg$, textColor: $text$ })
+  );
+<\/script>
+
+<Button styleOverrides={overrides}>Continue</Button>`;
+
+  // Option C in a consuming app — region/brand theming via provider.
+  const CHECKOUT_PROVIDER = `<!-- checkout/app/v2/modules/festivity/FestiveDrawer.svelte -->
+<script lang="ts">
+  import { BladeProvider, Button, Card } from '@razorpay/blade-svelte';
+  import { getFestiveTheme } from '$lib/festivity';
+
+  // A partial token tree (same shape as Blade tokens) for the whole subtree.
+  const themeOverrides = getFestiveTheme(); // { interactive: { background: ... } }
+<\/script>
+
+<!-- Everything inside inherits the festive palette via scoped CSS vars —
+     no per-instance prop needed. (Option C, complementary to B) -->
+<BladeProvider {themeOverrides}>
+  <Card>...festive content...</Card>
+  <Button>Pay now</Button>
+</BladeProvider>`;
+
+  // =================================================================
+  // Per-option consuming-app snippets (compact) — what a checkout
+  // component looks like adopting each option. Embedded in the meeting
+  // cards so the decision doc is self-contained. Same merchant inputs
+  // each time (getUIConfigColor → 6-digit hex or ''), only the carrier
+  // differs. Keyed by option id for the OPTIONS loop below.
+  // =================================================================
+  const APP_SNIPPETS = {
+    // A — flat inline style: the shipped anti-pattern (§1.1).
+    A: `<!-- Contact.svelte — Option A (shipped today) -->
+<script lang="ts">
+  import { Button } from 'blade-checkout-shim';
+  import { useUIConfigColor } from '$lib/config-driver';
+  import { CONFIG_PATHS } from '$lib/config-driver/paths';
+
+  const ctaBg$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_BG);
+  const ctaText$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_TEXT_COLOR);
+<\/script>
+
+<!-- Hex written straight to style → :hover / [disabled] dead-end. -->
+<Button
+  style={\`\${$ctaBg$ ? \`background:\${$ctaBg$};\` : ''}\${
+    $ctaText$ ? \`color:\${$ctaText$};\` : ''
+  }\`}
+>
+  Continue
+</Button>`,
+
+    // B — typed styleOverrides: states derived. The recommended path.
+    B: `<!-- Contact.svelte — Option B (recommended) -->
+<script lang="ts">
+  import { Button } from '@razorpay/blade-svelte';
+  import { useUIConfigColor } from '$lib/config-driver';
+  import { CONFIG_PATHS } from '$lib/config-driver/paths';
+
+  // Same config Readables as A — no config-driver change.
+  const ctaBg$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_BG);
+  const ctaText$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_TEXT_COLOR);
+
+  // Drop empty hex ('') so unset slots keep the default token look.
+  const ctaOverrides = $derived({
+    ...($ctaBg$ ? { backgroundColor: $ctaBg$ } : {}),
+    ...($ctaText$ ? { textColor: $ctaText$ } : {}),
+  });
+<\/script>
+
+<!-- One typed prop. blade-core derives hover/active/focus/disabled. -->
+<Button styleOverrides={ctaOverrides}>Continue</Button>`,
+
+    // C — scoped provider: region/brand theming, complementary to B.
+    C: `<!-- FestiveDrawer.svelte — Option C (region/brand) -->
+<script lang="ts">
+  import { BladeProvider, Button, Card } from '@razorpay/blade-svelte';
+  import { getFestiveTheme } from '$lib/festivity';
+
+  // Partial token tree (Blade token shape) for the whole subtree.
+  const themeOverrides = getFestiveTheme();
+<\/script>
+
+<!-- Everything inside inherits via scoped CSS vars — no per-instance prop.
+     Coarse on purpose: both buttons recolor together. -->
+<BladeProvider {themeOverrides}>
+  <Card>...festive content...</Card>
+  <Button>Pay now</Button>
+  <Button variant="secondary">Maybe later</Button>
+</BladeProvider>`,
+
+    // D — slot-keyed map: one declarative object, opt in via themeKey.
+    D: `<!-- App-level theme (provided once) — Option D -->
+<script lang="ts">
+  import { BladeProvider, Button } from '@razorpay/blade-svelte';
+  import { useUIConfigColor } from '$lib/config-driver';
+  import { CONFIG_PATHS } from '$lib/config-driver/paths';
+
+  const bg$ = useUIConfigColor(CONFIG_PATHS.CONTACT_CTA_BG);
+
+  // New naming dimension: slot keys must be invented + kept in sync
+  // across Blade + checkout (the coordination cost).
+  const slotTheme = $derived({
+    button: { primaryCta: $bg$ ? { backgroundColor: $bg$ } : {} },
+  });
+<\/script>
+
+<!-- Override lives far from usage; opt in by key. Sugar over B's carrier. -->
+<BladeProvider {slotTheme}>
+  <Button themeKey="primaryCta">Continue</Button>
+</BladeProvider>`,
+
+    // E — className passthrough: banned in checkout SFCs. (No literal
+    // <style> block here — V2 forbids it, and a real one would also trip
+    // svelte-preprocess parsing this file. The CSS lives in a separate
+    // sheet, which is itself the governance/specificity problem.)
+    E: `/* cta-override.css — a separate sheet (V2 bans <style> in SFCs) */
+.my-cta-override {
+  /* Static, hand-authored — can't take a merchant hex at runtime,
+     and won't reliably beat the box-shadow/module rules without
+     !important → specificity war, escapes DS governance. */
+  background: #7c3aed !important;
+}
+
+<!-- SomeScreen.svelte — Option E (NOT allowed in checkout) -->
+<script lang="ts">
+  import { Button } from '@razorpay/blade-svelte';
+  import './cta-override.css';
+<\/script>
+
+<Button className="my-cta-override">Continue</Button>`,
+  };
+
+  // =================================================================
+  // Meeting view — structured pros/cons of each proposed option.
+  // Single source the "Decision · pros & cons" story renders from, so
+  // the doc story stays in sync with the RFC (proposal §4 + §5 matrix).
+  // =================================================================
+
+  // verdict: 'core' | 'complementary' | 'rejected' | 'status-quo'
+  const OPTIONS = [
+    {
+      id: 'A',
+      title: 'Visual styled props',
+      summary: 'Add backgroundColor / color / borderRadius to StyledPropsBlade (token → class, arbitrary → inline style).',
+      verdict: 'status-quo',
+      verdictLabel: 'Shipped status quo — being replaced',
+      pros: [
+        'Smallest conceptual surface — reuses the existing styled-props pipeline.',
+        'Naturally per-instance; two buttons differ trivially.',
+        'Framework-agnostic (logic stays in blade-core).',
+      ],
+      cons: [
+        'Dead-ends interaction states — a flat backgroundColor can’t express hover/active/disabled. This is the shipped checkout bug (§1.1).',
+        'Only difference vs B is plumbing: A writes the hex to background-color directly; B writes it to the state-driving var.',
+        'Encourages "anything goes" inline styling — erodes DS guardrails, hard to lint.',
+        'Can’t target internal parts (axis E) — no way to address an Input’s field vs placeholder.',
+      ],
+    },
+    {
+      id: 'B',
+      title: 'styleOverrides → element-scoped CSS vars',
+      summary: 'Typed, bounded styleOverrides object per component → mapped to the component’s own CSS-module custom props. States derived from one base hex.',
+      verdict: 'core',
+      verdictLabel: 'Recommended core',
+      pros: [
+        'Preserves the class-first architecture — overrides are just scoped variable values over the cascade.',
+        'State-aware by design — the resolver derives hover/active/focus/disabled from the single base hex.',
+        'Reactive-friendly — inline vars update cleanly when the config Readable changes (live editor).',
+        'True per-instance; no :root pollution.',
+        'blade-core stays framework-agnostic (pure resolver); React can adopt the same fn later.',
+        'Addresses internal parts via nested keys (the bounded slice of D we keep, §4.5).',
+      ],
+      cons: [
+        'Per-component CSS-seam refactor, non-uniform cost — Button is cheap (already var-ized); composites (Card gradient bg, box-shadow border) need real seam work (§4.5).',
+        'Needs a typed contract per component (and a parts contract for composites).',
+        'Requires discipline so it doesn’t become a freeform style escape hatch (mitigate: typed keys only, no & CSSProperties).',
+      ],
+    },
+    {
+      id: 'C',
+      title: 'Scoped BladeProvider (subtree)',
+      summary: 'A real BladeProvider that re-declares affected token vars on its own wrapper (not :root), establishing a scoped cascade.',
+      verdict: 'complementary',
+      verdictLabel: 'Complementary (region/brand) — later phase',
+      pros: [
+        'Solves subtree theming elegantly ("make this whole drawer festive").',
+        'Reuses deep-merge + tokenToCSSVariable; conceptually clean.',
+        'No per-component schema — works for all components at once.',
+        'Gives Svelte the provider parity React has.',
+      ],
+      cons: [
+        'Doesn’t solve the core ask alone — sibling buttons each need their own wrapper, and it stays type-level (primary vs secondary), not instance-level.',
+        'Overriding semantic tokens at subtree scope is coarse — recolors all primary interactives in scope, not just the CTA.',
+        'Risk of deep nesting / cascade-reasoning complexity.',
+      ],
+    },
+    {
+      id: 'D',
+      title: 'Slot-keyed theme map',
+      summary: 'One theme object keyed by component → slot → state, consumed via context; components opt in with themeKey.',
+      verdict: 'rejected',
+      verdictLabel: 'Rejected as primary API (parts-instinct folded into B)',
+      pros: [
+        'Centralizes all overrides in one declarative object — close to how config-driver already thinks (path → value).',
+        'Designers/merchants reason about "slots", not props.',
+        'Its parts-addressing instinct is genuinely needed (kept, folded into B as nested keys).',
+      ],
+      cons: [
+        'Introduces a new naming dimension (slot keys) to invent, document, and keep in sync across Blade + checkout — high coordination cost.',
+        'Indirection — the override lives far from the usage; harder to trace.',
+        'Still needs B’s carrier underneath — it’s sugar, not a mechanism.',
+        'Over-engineered for the current need (a handful of CTAs).',
+      ],
+    },
+    {
+      id: 'E',
+      title: 'className / class passthrough',
+      summary: 'Expose className; consumer ships their own CSS / utility classes to override.',
+      verdict: 'rejected',
+      verdictLabel: 'Rejected (ungovernable; banned in checkout)',
+      pros: [
+        'Trivial to add — CVA’s getButtonClasses already accepts className.',
+        'Infinitely flexible.',
+      ],
+      cons: [
+        'Specificity wars vs CSS-module + box-shadow borders — overrides silently lose or need !important.',
+        'Banned in checkout V2 — no <style>/arbitrary CSS in SFCs; config is data (hex), not classes.',
+        'Escapes the DS entirely — no governance, no dark-mode awareness, no tokens.',
+      ],
+    },
+  ];
+
+  // =================================================================
+  // API cheat-sheet snippets (one per approach, A–E) — defined here in
+  // the module script so raw `<Button>` / `<style>` / `<\/script>` text
+  // inside the strings isn't parsed as real markup by the compiler.
+  // =================================================================
+  const CHEAT_IMPORTS = `import { Button, Card, BladeProvider } from '@razorpay/blade-svelte';
+import type { ButtonStyleOverrides } from '@razorpay/blade-core/styles';`;
+
+  const CHEAT_A = `<!-- Hex written straight to background/color. No state derivation:
+     :hover / :active / [disabled] dead-end. The shipped bug (§1.1). -->
+<Button visualProps={{ backgroundColor: '#7c3aed', color: '#ffffff' }} />`;
+
+  const CHEAT_B = `// One base hex per slot → hover/active/focus/disabled are DERIVED.
+<Button styleOverrides={{
+  backgroundColor: '#7c3aed',  // base hex → hover/active/disabled derived
+  textColor:       '#ffffff',
+  borderColor:     '#6d28d9',  // optional; highlighted border derived
+  borderRadius:    '24px',     // optional; any CSS length
+}} />
+
+// Composite parts (nested keys) — e.g. Card surface:
+<Card styleOverrides={{ surface: { backgroundColor: '#f5f3ff', borderColor: '#7c3aed' } }} />`;
+
+  const CHEAT_C = `// A partial token tree (Blade token shape) re-declared on the wrapper.
+// Everything inside inherits via scoped CSS vars — no per-instance prop.
+<BladeProvider themeOverrides={{ interactive: { background: { primary: { default: '#7c3aed' } } } }}>
+  <Card>...subtree inherits the scoped palette...</Card>
+  <Button>Pay now</Button>
+</BladeProvider>`;
+
+  const CHEAT_D = `// One declarative map keyed by component → slot, opt in via themeKey.
+// Resolves through B's carrier; adds a cross-repo naming dimension.
+<BladeProvider slotTheme={{
+  button: {
+    primaryCta:   { backgroundColor: '#7c3aed', textColor: '#ffffff' },
+    secondaryCta: { backgroundColor: '#0ea5e9', borderRadius: '4px' },
+  },
+}}>
+  <Button themeKey="primaryCta">Continue</Button>
+  <Button variant="secondary" themeKey="secondaryCta">Maybe later</Button>
+</BladeProvider>`;
+
+  const CHEAT_E = `<!-- Needs hand-written CSS, can't take a merchant hex at runtime,
+     fights CSS-module specificity, and V2 bans <style>/util classes. -->
+<Button className="my-cta-override">Continue</Button>
+
+<style>
+  /* Won't reliably beat the module rules without !important. */
+  :global(.my-cta-override) { background: #7c3aed; }
+<\/style>`;
+
+  // §5 comparison matrix — rows = criteria, cells keyed by option id.
+  // Scores: '++' strong yes · '+' yes · '~' partial · 'x' no (rendered as glyphs).
+  const MATRIX = [
+    { criterion: 'Solves sibling instances (same page)', A: '+', B: '++', C: 'x', D: '+', E: '+' },
+    { criterion: 'Preserves interaction states (hover/disabled)', A: 'x', B: '++', C: '+', D: '+', E: '~' },
+    { criterion: 'Addresses internal parts (axis E)', A: 'x', B: '+', C: '~', D: '++', E: '~' },
+    { criterion: 'Reactive to live editor edits', A: '+', B: '++', C: '+', D: '+', E: '~' },
+    { criterion: 'Keeps class-first architecture', A: '~', B: '++', C: '++', D: '+', E: 'x' },
+    { criterion: 'Matches consumer vocabulary (opaque hex)', A: '+', B: '++', C: '~', D: '+', E: 'x' },
+    { criterion: 'blade-core stays framework-agnostic', A: '+', B: '+', C: '+', D: '+', E: '+' },
+    { criterion: 'Maps cleanly to Config V2 output', A: '~', B: '++', C: '~', D: '+', E: 'x' },
+    { criterion: 'Backward compatible', A: '+', B: '++', C: '+', D: '+', E: '+' },
+    { criterion: 'Bundle cost', A: 'Low', B: 'Low', C: 'Low', D: 'Med', E: 'Low' },
+    { criterion: 'Net new naming / coordination', A: 'Low', B: 'Low', C: 'Low', D: 'High', E: 'None' },
+    { criterion: 'Implementation cost', A: 'Low', B: 'Low→Med/High', C: 'Med', D: 'High', E: 'Low' },
+  ];
+
+  // Visual styling per verdict (border accent + badge colors). Plain hex so the
+  // doc reads identically regardless of the active Blade theme.
+  const VERDICT_STYLE = {
+    core: { accent: '#1a7f37', badgeBg: '#dafbe1', badgeText: '#0a5223', label: 'CORE' },
+    complementary: { accent: '#0969da', badgeBg: '#ddf4ff', badgeText: '#0a3069', label: 'COMPLEMENTARY' },
+    rejected: { accent: '#cf222e', badgeBg: '#ffebe9', badgeText: '#82071e', label: 'REJECTED' },
+    'status-quo': { accent: '#9a6700', badgeBg: '#fff8c5', badgeText: '#7a5a00', label: 'STATUS QUO' },
+  };
+
+  // Render glyph + color for a matrix cell score.
+  function cellView(v) {
+    switch (v) {
+      case '++':
+        return { text: '✓✓', color: '#1a7f37' };
+      case '+':
+        return { text: '✓', color: '#2da44e' };
+      case '~':
+        return { text: '~', color: '#9a6700' };
+      case 'x':
+        return { text: '✗', color: '#cf222e' };
+      default:
+        return { text: v, color: '#57606a' };
+    }
+  }
+</script>
+
+<!-- Shared readout: shows the live resolver output as a CSS-vars block. -->
+{#snippet varsReadout(title, vars)}
+  <div
+    style="background:#0c1117; color:#7ee787; border-radius:8px; padding:12px 14px; font-family:ui-monospace,'SF Mono',Menlo,monospace; font-size:12px; line-height:1.5; white-space:pre; overflow-x:auto;"
+  >
+    <div style="color:#8b949e; margin-bottom:6px;">{title}</div>{showVars(vars)}</div>
+{/snippet}
+
+<!-- Shared code block: renders a static source snippet (consuming-app files that -->
+<!-- live in the checkout repo, shown here for the buy-in walkthrough). `label` is -->
+<!-- the file path / caption, `code` is the verbatim source. -->
+{#snippet codeBlock(label, code)}
+  <div style="border:1px solid #30363d; border-radius:8px; overflow:hidden;">
+    <div
+      style="background:#161b22; color:#8b949e; padding:8px 14px; font-family:ui-monospace,'SF Mono',Menlo,monospace; font-size:11px; border-bottom:1px solid #30363d;"
+    >
+      {label}
+    </div>
+    <pre
+      style="background:#0c1117; color:#c9d1d9; margin:0; padding:14px; font-family:ui-monospace,'SF Mono',Menlo,monospace; font-size:12px; line-height:1.55; white-space:pre; overflow-x:auto;">{code}</pre>
+  </div>
+{/snippet}
+
+<!-- ============================================================= -->
+<!-- Option A vs B — the state regression, made visible            -->
+<!-- ============================================================= -->
+<Story
+  name="A vs B · hover &amp; disabled"
+  exportName="AvsBStatic"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:560px;">
+    <Heading size="small">Option A (flat inline) vs Option B (styleOverrides)</Heading>
+    <Text color="surface.text.gray.muted">
+      Both get the SAME base hex. Hover each, then look at the disabled column.
+      Option A dead-ends hover/disabled (the shipped checkout bug, proposal §1.1);
+      Option B derives them.
+    </Text>
+
+    <div style="display:grid; grid-template-columns:auto 1fr 1fr; gap:12px 20px; align-items:center;">
+      <span></span>
+      <Text weight="semibold">default / hover</Text>
+      <Text weight="semibold">disabled</Text>
+
+      <Text color="surface.text.gray.muted">A — visualProps</Text>
+      <Button visualProps={{ backgroundColor: MERCHANT_BG, color: MERCHANT_TEXT }}>
+        Hover me
+      </Button>
+      <Button visualProps={{ backgroundColor: MERCHANT_BG, color: MERCHANT_TEXT }} isDisabled>
+        Disabled
+      </Button>
+
+      <Text color="surface.text.gray.muted">B — styleOverrides</Text>
+      <Button styleOverrides={{ backgroundColor: MERCHANT_BG, textColor: MERCHANT_TEXT }}>
+        Hover me
+      </Button>
+      <Button styleOverrides={{ backgroundColor: MERCHANT_BG, textColor: MERCHANT_TEXT }} isDisabled>
+        Disabled
+      </Button>
+    </div>
+  </div>
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option A vs B — INTERACTIVE (same args, both carriers)         -->
+<!-- ============================================================= -->
+<Story name="A vs B · Interactive (try me)" exportName="AvsBInteractive">
+  {#snippet template(args)}
+    {@const overrides = argsToStyleOverrides(args)}
+    <div style="display:flex; flex-direction:column; gap:16px; max-width:620px;">
+      <Heading size="small">A (flat inline) vs B (styleOverrides) — same Controls</Heading>
+      <Text color="surface.text.gray.muted">
+        Both columns read the SAME args. Hover each button and toggle
+        <code>isDisabled</code>: Option A dead-ends hover/disabled (the shipped
+        checkout bug), Option B derives them.
+      </Text>
+
+      <div style="display:grid; grid-template-columns:auto 1fr 1fr; gap:12px 20px; align-items:center;">
+        <span></span>
+        <Text weight="semibold">default / hover</Text>
+        <Text weight="semibold">disabled</Text>
+
+        <Text color="surface.text.gray.muted">A — visualProps</Text>
+        <Button visualProps={{ backgroundColor: args.backgroundColor, color: args.textColor }} isDisabled={args.isDisabled}>
+          {args.label}
+        </Button>
+        <Button visualProps={{ backgroundColor: args.backgroundColor, color: args.textColor }} isDisabled>
+          Disabled
+        </Button>
+
+        <Text color="surface.text.gray.muted">B — styleOverrides</Text>
+        <Button styleOverrides={overrides} isDisabled={args.isDisabled}>
+          {args.label}
+        </Button>
+        <Button styleOverrides={overrides} isDisabled>
+          Disabled
+        </Button>
+      </div>
+    </div>
+  {/snippet}
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option B — styleOverrides (RECOMMENDED CORE)                   -->
+<!-- ============================================================= -->
+<Story
+  name="B · styleOverrides (recommended)"
+  exportName="BStatic"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:520px;">
+    <Heading size="small">Option B — per-instance `styleOverrides`</Heading>
+    <Text color="surface.text.gray.subtle">
+      One base hex in; default/hover/active/focus and disabled are derived. Hover and
+      disable these to confirm states still work. This is the recommended mechanism.
+    </Text>
+
+    <Card>
+      {#snippet children()}
+        <CardBody>
+          {#snippet children()}
+            <div style="display:flex; flex-direction:column; gap:12px;">
+              <Text weight="semibold">1 · Derived states from a single base hex</Text>
+              <Text size="small" color="surface.text.gray.muted">
+                Both buttons get the same <code>backgroundColor</code>; the disabled
+                state is synthesized — not passed in.
+              </Text>
+              <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap;">
+                <Button styleOverrides={{ backgroundColor: MERCHANT_BG, textColor: MERCHANT_TEXT }}>
+                  Primary CTA
+                </Button>
+                <Button styleOverrides={{ backgroundColor: MERCHANT_BG, textColor: MERCHANT_TEXT }} isDisabled>
+                  Disabled (derived)
+                </Button>
+              </div>
+            </div>
+          {/snippet}
+        </CardBody>
+      {/snippet}
+    </Card>
+
+    <Card>
+      {#snippet children()}
+        <CardBody>
+          {#snippet children()}
+            <div style="display:flex; flex-direction:column; gap:12px;">
+              <Text weight="semibold">2 · Two siblings, same page, different styles</Text>
+              <Text size="small" color="surface.text.gray.muted">
+                The core ask — independent color, border, and radius per instance.
+              </Text>
+              <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap;">
+                <Button styleOverrides={{ backgroundColor: '#1a59ff', textColor: '#ffffff', borderRadius: '24px' }}>
+                  Rounded blue
+                </Button>
+                <Button
+                  variant="secondary"
+                  styleOverrides={{ backgroundColor: '#ffffff', textColor: '#1a59ff', borderColor: '#1a59ff', borderRadius: '4px' }}
+                >
+                  Sharp white
+                </Button>
+              </div>
+            </div>
+          {/snippet}
+        </CardBody>
+      {/snippet}
+    </Card>
+  </div>
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option B — INTERACTIVE (Controls panel drives the real Button) -->
+<!-- ============================================================= -->
+<Story name="B · Interactive (try me)" exportName="BInteractive">
+  {#snippet template(args)}
+    {@const overrides = argsToStyleOverrides(args)}
+    <div style="display:flex; flex-direction:column; gap:16px; max-width:560px;">
+      <Heading size="small">Option B — interactive `styleOverrides`</Heading>
+      <Text color="surface.text.gray.muted">
+        Edit <strong>backgroundColor / textColor / borderRadius / isDisabled</strong>
+        in the <strong>Controls</strong> panel below. The same base hex drives the
+        button; hover it and toggle <code>isDisabled</code> — the hover/disabled
+        states are derived by the real <code>resolveButtonOverrides</code>.
+      </Text>
+
+      <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap;">
+        <Button styleOverrides={overrides} isDisabled={args.isDisabled}>
+          {args.label}
+        </Button>
+        <Button styleOverrides={overrides} isDisabled>
+          Always disabled
+        </Button>
+      </div>
+
+      {@render varsReadout('resolveButtonOverrides(styleOverrides) →', resolveButtonOverrides(overrides))}
+    </div>
+  {/snippet}
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option B (parts) — composite component (Card)                 -->
+<!-- ============================================================= -->
+<Story
+  name="B · parts (Card surface)"
+  exportName="BPartsStatic"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:420px;">
+    <Heading size="small">Option B — named parts (axis E)</Heading>
+    <Text color="surface.text.gray.muted">
+      Card's surface lives on a child element with a gradient bg + box-shadow border.
+      After the seam audit (§4.5) those are CSS vars, so `styleOverrides.surface`
+      retints only this card.
+    </Text>
+
+    <Card styleOverrides={{ surface: { backgroundColor: '#f5f3ff', borderColor: '#7c3aed' } }}>
+      {#snippet children()}
+        <CardBody>
+          {#snippet children()}
+            <Text>Overridden surface (lavender bg, purple border)</Text>
+          {/snippet}
+        </CardBody>
+      {/snippet}
+    </Card>
+
+    <Card>
+      {#snippet children()}
+        <CardBody>
+          {#snippet children()}
+            <Text>Default card (no override) — for comparison</Text>
+          {/snippet}
+        </CardBody>
+      {/snippet}
+    </Card>
+  </div>
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option C — BladeProvider (scoped subtree theming)             -->
+<!-- ============================================================= -->
+<Story
+  name="C · BladeProvider (scoped)"
+  exportName="CStatic"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:520px;">
+    <Heading size="small">Option C — scoped `BladeProvider`</Heading>
+    <Text color="surface.text.gray.muted">
+      The provider re-declares token vars on its wrapper, so EVERY primary
+      interactive inside inherits — great for region/brand, coarse for single
+      siblings (note both buttons change together).
+    </Text>
+
+    <BladeProvider themeOverrides={festiveTheme}>
+      {#snippet children()}
+        <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap; padding:16px; border:1px dashed var(--surface-border-gray-muted); border-radius:8px;">
+          <Button>Inside provider</Button>
+          <Button>Also inside</Button>
+        </div>
+      {/snippet}
+    </BladeProvider>
+
+    <div style="display:flex; gap:12px; align-items:center;">
+      <Button>Outside provider (unchanged)</Button>
+    </div>
+  </div>
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option C — INTERACTIVE (provider scope, args drive token tree) -->
+<!-- ============================================================= -->
+<Story name="C · Interactive (try me)" exportName="CInteractive">
+  {#snippet template(args)}
+    {@const themeOverrides = {
+      interactive: { background: { primary: { default: args.backgroundColor } } },
+    }}
+    <div style="display:flex; flex-direction:column; gap:16px; max-width:560px;">
+      <Heading size="small">Option C — interactive `BladeProvider`</Heading>
+      <Text color="surface.text.gray.muted">
+        The <code>backgroundColor</code> control feeds a token override on the
+        provider wrapper. Note BOTH buttons inside change together (subtree scope),
+        while the one outside stays default — that's the coarseness trade-off.
+      </Text>
+
+      <BladeProvider {themeOverrides}>
+        {#snippet children()}
+          <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap; padding:16px; border:1px dashed var(--surface-border-gray-muted); border-radius:8px;">
+            <Button>{args.label}</Button>
+            <Button>Also inside</Button>
+          </div>
+        {/snippet}
+      </BladeProvider>
+
+      <Button>Outside provider (unchanged)</Button>
+
+      {@render varsReadout('flattenThemeOverridesToVars(themeOverrides) →', flattenThemeOverridesToVars(themeOverrides))}
+    </div>
+  {/snippet}
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option D — slot-keyed theme map                               -->
+<!-- ============================================================= -->
+<Story
+  name="D · slot-keyed map"
+  exportName="DStatic"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:520px;">
+    <Heading size="small">Option D — slot-keyed theme map</Heading>
+    <Text color="surface.text.gray.muted">
+      One declarative map (provided once), components opt in via `themeKey`. Resolves
+      through Option B's carrier. Rejected as the primary API (new cross-repo naming
+      dimension) but shown for completeness.
+    </Text>
+
+    <BladeProvider {slotTheme}>
+      {#snippet children()}
+        <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap;">
+          <Button themeKey="primaryCta">themeKey="primaryCta"</Button>
+          <Button variant="secondary" themeKey="secondaryCta">themeKey="secondaryCta"</Button>
+          <Button themeKey="primaryCta" isDisabled>disabled (still derived)</Button>
+        </div>
+      {/snippet}
+    </BladeProvider>
+  </div>
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option D — INTERACTIVE (slot map keyed by themeKey)            -->
+<!-- ============================================================= -->
+<Story name="D · Interactive (try me)" exportName="DInteractive">
+  {#snippet template(args)}
+    {@const liveSlotTheme = {
+      button: { primaryCta: argsToStyleOverrides(args) },
+    }}
+    <div style="display:flex; flex-direction:column; gap:16px; max-width:560px;">
+      <Heading size="small">Option D — interactive slot-keyed map</Heading>
+      <Text color="surface.text.gray.muted">
+        The Controls feed a <code>slotTheme.button.primaryCta</code> entry; the
+        button opts in via <code>themeKey="primaryCta"</code>. Output is identical
+        to Option B (D is sugar over B's carrier) — see the readout.
+      </Text>
+
+      <BladeProvider slotTheme={liveSlotTheme}>
+        {#snippet children()}
+          <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap;">
+            <Button themeKey="primaryCta" isDisabled={args.isDisabled}>{args.label}</Button>
+            <Button themeKey="primaryCta" isDisabled>disabled (still derived)</Button>
+          </div>
+        {/snippet}
+      </BladeProvider>
+
+      {@render varsReadout('resolveSlotTheme(slotTheme, "button", "primaryCta") →', resolveSlotTheme(liveSlotTheme, 'button', 'primaryCta'))}
+    </div>
+  {/snippet}
+</Story>
+
+<!-- ============================================================= -->
+<!-- Option E — className passthrough                               -->
+<!-- ============================================================= -->
+<Story
+  name="E · className (discouraged)"
+  exportName="EStatic"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:520px;">
+    <Heading size="small">Option E — `className` passthrough</Heading>
+    <Text color="surface.text.gray.muted">
+      Trivial to add, but: specificity wars vs CSS-module rules, escapes DS
+      governance, and is banned in checkout SFCs (config is data, not classes).
+      Here a utility class is appended — note it can't drive derived states.
+    </Text>
+
+    <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap;">
+      <Button variant="secondary" className="background-interactive-background-primary-faded">
+        With utility className
+      </Button>
+    </div>
+  </div>
+</Story>
+
+<!-- ============================================================= -->
+<!-- CONSUMING APP — what the wrapper / component API looks like    -->
+<!-- end-to-end in checkout (for the buy-in walkthrough).           -->
+<!-- ============================================================= -->
+
+<!-- 1 · Before vs After — the migration at the call site ---------- -->
+<Story
+  name="App · Before vs After (call site)"
+  exportName="AppBeforeAfter"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:760px;">
+    <Heading size="small">Consuming app — the call-site diff</Heading>
+    <Text color="surface.text.gray.muted">
+      What a checkout component looks like <strong>today</strong> vs <strong>after</strong>
+      adopting Blade's <code>styleOverrides</code>. Same config inputs
+      (<code>useUIConfigColor</code>), same merchant hex — the only change is routing it
+      through a typed prop instead of a flat <code>style</code> string. Hover/disabled
+      go from broken (A) to derived (B).
+    </Text>
+
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">Before — Option A (shipped bug §1.1)</Text>
+      {@render codeBlock('Contact.svelte (today)', CHECKOUT_BEFORE)}
+    </div>
+
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">After — Option B (states derived)</Text>
+      {@render codeBlock('Contact.svelte (after)', CHECKOUT_AFTER)}
+    </div>
+
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">Live result of the "after" snippet</Text>
+      <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap;">
+        <Button styleOverrides={{ backgroundColor: MERCHANT_BG, textColor: MERCHANT_TEXT }}>
+          Continue
+        </Button>
+        <Button styleOverrides={{ backgroundColor: MERCHANT_BG, textColor: MERCHANT_TEXT }} isDisabled>
+          Disabled (derived)
+        </Button>
+      </div>
+    </div>
+  </div>
+</Story>
+
+<!-- 2 · The adapter — the only net-new consumer code -------------- -->
+<Story
+  name="App · Adapter (config → overrides)"
+  exportName="AppAdapter"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:760px;">
+    <Heading size="small">Consuming app — the adapter layer</Heading>
+    <Text color="surface.text.gray.muted">
+      The bridge between checkout's <code>config-driver</code> and Blade. It's a pure
+      shape map: config paths → Blade's typed <code>ButtonStyleOverrides</code>. Security
+      and sanitization stay in <code>config-driver</code>; Blade treats values as opaque
+      strings and derives states. This is the <em>entire</em> net-new surface a consumer owns.
+    </Text>
+
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">1 · The adapter (write once, reuse everywhere)</Text>
+      {@render codeBlock('utils/blade-adapter/toButtonOverrides.ts', CHECKOUT_ADAPTER)}
+    </div>
+
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">2 · Using it in a component</Text>
+      {@render codeBlock('SomeScreen.svelte', CHECKOUT_ADAPTER_USAGE)}
+    </div>
+  </div>
+</Story>
+
+<!-- 3 · Provider usage — region/brand theming (Option C) ---------- -->
+<Story
+  name="App · Provider (region theming)"
+  exportName="AppProvider"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:760px;">
+    <Heading size="small">Consuming app — region/brand theming</Heading>
+    <Text color="surface.text.gray.muted">
+      For "theme this whole surface" cases (festivities, co-brand drawers), a consumer
+      wraps a subtree in <code>BladeProvider</code> with a partial token tree. Complementary
+      to <code>styleOverrides</code> — use the provider for regions, the prop for instances.
+    </Text>
+
+    {@render codeBlock('FestiveDrawer.svelte', CHECKOUT_PROVIDER)}
+
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">Live result</Text>
+      <BladeProvider themeOverrides={festiveTheme}>
+        {#snippet children()}
+          <div style="display:flex; gap:12px; align-items:center; flex-wrap:wrap; padding:16px; border:1px dashed var(--surface-border-gray-muted); border-radius:8px;">
+            <Button>Pay now</Button>
+            <Button variant="secondary">Cancel</Button>
+          </div>
+        {/snippet}
+      </BladeProvider>
+    </div>
+  </div>
+</Story>
+
+<!-- 4 · API cheat sheet — the full wrapper surface at a glance ----- -->
+<Story
+  name="App · API cheat sheet"
+  exportName="AppApiCheatSheet"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:16px; max-width:760px;">
+    <Heading size="small">Consuming app — API surface at a glance</Heading>
+    <Text color="surface.text.gray.muted">
+      Every approach a consuming app could touch, A–E, with a full snippet each. The
+      recommended path is <strong>B</strong> (per-instance) + <strong>C</strong>
+      (region/brand); A/D/E are shown verbatim for evaluation only.
+    </Text>
+
+    <!-- Imports — shared across the recommended path -->
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">0 · Imports (recommended path)</Text>
+      {@render codeBlock('imports', CHEAT_IMPORTS)}
+    </div>
+
+    <!-- A — visual styled props (status quo, dead-ends states) -->
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">A · visualProps — status quo (dead-ends hover/disabled)</Text>
+      {@render codeBlock('Option A — flat visual props', CHEAT_A)}
+    </div>
+
+    <!-- B — styleOverrides (recommended core) -->
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">B · styleOverrides — recommended core (state-aware)</Text>
+      {@render codeBlock('Option B — per-instance, states derived', CHEAT_B)}
+    </div>
+
+    <!-- C — scoped BladeProvider (complementary) -->
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">C · BladeProvider — complementary region/brand theming</Text>
+      {@render codeBlock('Option C — scoped subtree theming', CHEAT_C)}
+    </div>
+
+    <!-- D — slot-keyed map (rejected as primary; sugar over B) -->
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">D · slotTheme — slot-keyed map (rejected as primary; sugar over B)</Text>
+      {@render codeBlock('Option D — slot-keyed theme map', CHEAT_D)}
+    </div>
+
+    <!-- E — className passthrough (banned in checkout) -->
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Text weight="semibold" color="surface.text.gray.subtle">E · className — passthrough (banned in checkout SFCs)</Text>
+      {@render codeBlock('Option E — className passthrough', CHEAT_E)}
+    </div>
+  </div>
+</Story>
+
+<!-- ============================================================= -->
+<!-- MEETING VIEW — structured pros / cons of every option.        -->
+<!-- Pure documentation (no live components): a single scannable    -->
+<!-- artifact to drive the decision discussion. Maps to proposal    -->
+<!-- §4 (option write-ups) + §5 (comparison matrix) + §6 (rec).     -->
+<!-- ============================================================= -->
+<Story
+  name="Decision · pros &amp; cons (meeting)"
+  exportName="DecisionProsCons"
+  parameters={{ controls: { exclude: /.*/g } }}
+  asChild
+>
+  <div style="display:flex; flex-direction:column; gap:24px; max-width:980px;">
+    <!-- Header + TL;DR verdict -->
+    <div style="display:flex; flex-direction:column; gap:8px;">
+      <Heading size="large">Instance-Level Styling — options at a glance</Heading>
+      <Text color="surface.text.gray.muted">
+        Pros / cons of each proposed mechanism, for the decision meeting. Full write-up:
+        <code>docs/instance-level-styling-proposal.md</code> (§4 options, §5 matrix, §6 recommendation).
+        Live behaviour is in the other stories under this folder — start with
+        <strong>"A vs B · hover &amp; disabled"</strong>.
+      </Text>
+    </div>
+
+    <div
+      style="border:1px solid #d0d7de; border-left:4px solid #1a7f37; border-radius:8px; padding:14px 16px; background:#f6fff9; display:flex; flex-direction:column; gap:6px;"
+    >
+      <Text weight="semibold">Recommendation</Text>
+      <Text size="small" color="surface.text.gray.subtle">
+        Adopt <strong>B</strong> (<code>styleOverrides</code> → element-scoped CSS vars, states derived
+        from one base hex) as the core. Keep <strong>C</strong> (<code>BladeProvider</code>) as the
+        complementary region/brand layer. <strong>A</strong> is the shipped status quo being replaced;
+        <strong>D</strong>’s parts-addressing is folded into B; <strong>D</strong>’s slot taxonomy and
+        <strong>E</strong> are rejected.
+      </Text>
+    </div>
+
+    <!-- Legend for the verdict badges -->
+    <div style="display:flex; gap:8px; flex-wrap:wrap; align-items:center;">
+      {#each Object.values(VERDICT_STYLE) as v}
+        <span
+          style="font-family:ui-monospace,'SF Mono',Menlo,monospace; font-size:10px; font-weight:600; letter-spacing:0.04em; padding:3px 8px; border-radius:999px; background:{v.badgeBg}; color:{v.badgeText};"
+        >
+          {v.label}
+        </span>
+      {/each}
+    </div>
+
+    <!-- Per-option pros/cons cards -->
+    <div style="display:flex; flex-direction:column; gap:16px;">
+      {#each OPTIONS as opt}
+        {@const vs = VERDICT_STYLE[opt.verdict]}
+        <div
+          style="border:1px solid #d0d7de; border-left:4px solid {vs.accent}; border-radius:8px; overflow:hidden; background:#ffffff;"
+        >
+          <!-- Card header: option id + title + verdict badge -->
+          <div
+            style="display:flex; align-items:center; gap:12px; flex-wrap:wrap; padding:12px 16px; background:#f6f8fa; border-bottom:1px solid #d0d7de;"
+          >
+            <span
+              style="display:inline-flex; align-items:center; justify-content:center; width:28px; height:28px; border-radius:6px; background:{vs.accent}; color:#ffffff; font-weight:700; font-size:14px;"
+            >
+              {opt.id}
+            </span>
+            <span style="font-size:15px; font-weight:600; color:#1f2328;">{opt.title}</span>
+            <span
+              style="margin-left:auto; font-family:ui-monospace,'SF Mono',Menlo,monospace; font-size:10px; font-weight:600; letter-spacing:0.04em; padding:3px 8px; border-radius:999px; background:{vs.badgeBg}; color:{vs.badgeText};"
+            >
+              {opt.verdictLabel}
+            </span>
+          </div>
+
+          <div style="padding:14px 16px; display:flex; flex-direction:column; gap:14px;">
+            <Text size="small" color="surface.text.gray.muted">{opt.summary}</Text>
+
+            <!-- Pros / cons two-column -->
+            <div style="display:grid; grid-template-columns:1fr 1fr; gap:20px;">
+              <div style="display:flex; flex-direction:column; gap:8px;">
+                <Text size="small" weight="semibold" color="feedback.text.positive.intense">
+                  Pros
+                </Text>
+                <ul style="margin:0; padding-left:18px; display:flex; flex-direction:column; gap:6px;">
+                  {#each opt.pros as pro}
+                    <li style="font-size:13px; line-height:1.5; color:#1f2328;">{pro}</li>
+                  {/each}
+                </ul>
+              </div>
+
+              <div style="display:flex; flex-direction:column; gap:8px;">
+                <Text size="small" weight="semibold" color="feedback.text.negative.intense">
+                  Cons
+                </Text>
+                <ul style="margin:0; padding-left:18px; display:flex; flex-direction:column; gap:6px;">
+                  {#each opt.cons as con}
+                    <li style="font-size:13px; line-height:1.5; color:#1f2328;">{con}</li>
+                  {/each}
+                </ul>
+              </div>
+            </div>
+
+            <!-- Consuming-app call site for this option -->
+            {#if APP_SNIPPETS[opt.id]}
+              <div style="display:flex; flex-direction:column; gap:6px;">
+                <Text size="xsmall" weight="semibold" color="surface.text.gray.subtle">
+                  In a consuming app (checkout)
+                </Text>
+                {@render codeBlock(`Option ${opt.id} — call site`, APP_SNIPPETS[opt.id])}
+              </div>
+            {/if}
+          </div>
+        </div>
+      {/each}
+    </div>
+
+    <!-- §5 comparison matrix -->
+    <div style="display:flex; flex-direction:column; gap:10px;">
+      <Heading size="small">Comparison matrix (proposal §5)</Heading>
+      <Text size="small" color="surface.text.gray.muted">
+        <span style="color:#1a7f37; font-weight:600;">✓✓</span> strong&nbsp;·
+        <span style="color:#2da44e; font-weight:600;">✓</span> yes&nbsp;·
+        <span style="color:#9a6700; font-weight:600;">~</span> partial&nbsp;·
+        <span style="color:#cf222e; font-weight:600;">✗</span> no.
+        Read "implementation cost" per-component — Button is cheap, composites need seam work (§4.5).
+      </Text>
+
+      <div style="border:1px solid #d0d7de; border-radius:8px; overflow-x:auto;">
+        <table style="border-collapse:collapse; width:100%; font-size:13px; min-width:720px;">
+          <thead>
+            <tr style="background:#f6f8fa;">
+              <th
+                style="text-align:left; padding:10px 12px; border-bottom:1px solid #d0d7de; color:#1f2328; font-weight:600; position:sticky; left:0; background:#f6f8fa;"
+              >
+                Criterion
+              </th>
+              {#each OPTIONS as opt}
+                <th
+                  style="text-align:center; padding:10px 12px; border-bottom:1px solid #d0d7de; border-left:1px solid #eaeef2; color:#1f2328; font-weight:600; white-space:nowrap;"
+                >
+                  {opt.id}{opt.verdict === 'core' ? ' ★' : ''}
+                </th>
+              {/each}
+            </tr>
+          </thead>
+          <tbody>
+            {#each MATRIX as row, i}
+              <tr style={i % 2 === 1 ? 'background:#fbfcfd;' : ''}>
+                <td
+                  style="padding:9px 12px; border-bottom:1px solid #eaeef2; color:#1f2328; position:sticky; left:0; background:{i % 2 === 1 ? '#fbfcfd' : '#ffffff'};"
+                >
+                  {row.criterion}
+                </td>
+                {#each OPTIONS as opt}
+                  {@const cell = cellView(row[opt.id])}
+                  <td
+                    style="text-align:center; padding:9px 12px; border-bottom:1px solid #eaeef2; border-left:1px solid #eaeef2; color:{cell.color}; font-weight:600; white-space:nowrap;"
+                  >
+                    {cell.text}
+                  </td>
+                {/each}
+              </tr>
+            {/each}
+          </tbody>
+        </table>
+      </div>
+      <Text size="xsmall" color="surface.text.gray.muted">★ = recommended core (Option B).</Text>
+    </div>
+  </div>
+</Story>
diff --git a/packages/blade-svelte/src/components/Card/Card.svelte b/packages/blade-svelte/src/components/Card/Card.svelte
index d8aba32cf28..e88d35129ab 100644
--- a/packages/blade-svelte/src/components/Card/Card.svelte
+++ b/packages/blade-svelte/src/components/Card/Card.svelte
@@ -34,6 +34,7 @@
     overflowX,
     overflowY,
     validationState = 'none',
+    styleOverrides,
     testID,
     ...rest
   }: CardProps = $props();
@@ -86,6 +87,7 @@
       {overflow}
       {overflowX}
       {overflowY}
+      {styleOverrides}
     >
       {#snippet children()}
         {#if href}
diff --git a/packages/blade-svelte/src/components/Card/CardSurface.svelte b/packages/blade-svelte/src/components/Card/CardSurface.svelte
index c69c0ac3566..6e05d19c8d2 100644
--- a/packages/blade-svelte/src/components/Card/CardSurface.svelte
+++ b/packages/blade-svelte/src/components/Card/CardSurface.svelte
@@ -1,7 +1,11 @@
 <script lang="ts">
   import type { Snippet } from 'svelte';
-  import { cardSurfaceStyles } from '@razorpay/blade-core/styles';
-  import type { CardSurfaceVariants } from '@razorpay/blade-core/styles';
+  import {
+    cardSurfaceStyles,
+    resolveCardOverrides,
+    styleObjectToString,
+  } from '@razorpay/blade-core/styles';
+  import type { CardSurfaceVariants, CardStyleOverrides } from '@razorpay/blade-core/styles';
 
   type OverflowValue = 'visible' | 'hidden' | 'scroll' | 'auto' | 'clip';
 
@@ -15,6 +19,7 @@
     overflow,
     overflowX,
     overflowY,
+    styleOverrides,
   }: {
     children: Snippet;
     backgroundColor?: CardSurfaceVariants['backgroundColor'];
@@ -25,6 +30,7 @@
     overflow?: OverflowValue;
     overflowX?: OverflowValue;
     overflowY?: OverflowValue;
+    styleOverrides?: CardStyleOverrides;
   } = $props();
 
   const surfaceClasses = $derived(
@@ -34,10 +40,16 @@
       borderRadius,
     })
   );
+
+  // Option B (composite parts): resolve the `surface` part overrides into the
+  // element-scoped CSS vars the .cardSurface seams consume (--card-surface-bg /
+  // --card-surface-border-color). Emitted as an inline style on the surface element.
+  const overrideStyle = $derived(styleObjectToString(resolveCardOverrides(styleOverrides)));
 </script>
 
 <div
   class={surfaceClasses}
+  style={overrideStyle}
   style:height={height}
   style:min-height={minHeight}
   style:overflow={overflow}
diff --git a/packages/blade-svelte/src/components/Card/types.ts b/packages/blade-svelte/src/components/Card/types.ts
index 267e644a613..0c2241eaa80 100644
--- a/packages/blade-svelte/src/components/Card/types.ts
+++ b/packages/blade-svelte/src/components/Card/types.ts
@@ -1,5 +1,6 @@
 import type { Snippet, Component } from 'svelte';
 import type { StyledPropsBlade } from '@razorpay/blade-core/utils';
+import type { CardStyleOverrides } from '@razorpay/blade-core/styles';
 import type { IconProps } from '../Icons/types';
 
 // Icon component type - Svelte component that accepts IconProps
@@ -133,6 +134,16 @@ export type CardProps = {
    * @default 'none'
    */
   validationState?: 'none' | 'error' | 'success';
+  /**
+   * **Instance-level styling — Option B, composite "parts".**
+   * Bounded, typed per-instance overrides addressed by *named part*. The `surface`
+   * part targets the `.cardSurface` child (background gradient + box-shadow border
+   * seams). Unset parts render pixel-identical. See instance-level-styling-proposal §4.5.
+   *
+   * @example
+   * <Card styleOverrides={{ surface: { backgroundColor: '#fff', borderColor: '#1a59ff' } }} />
+   */
+  styleOverrides?: CardStyleOverrides;
   /**
    * Test ID for testing
    */