docs(creative): clarify brand and catalog sourcing

.changeset/clarify-brand-catalog-sourcing.md

@@ -0,0 +1,5 @@
+---
+"adcontextprotocol": patch
+---
+
+Clarify that `brand.json` supplies master brand identity while catalogs supply product and item payload, including item-level property or franchise logos that do not override the master brand kit.

docs/creative/catalogs.mdx

@@ -131,7 +131,7 @@ Each vertical type has a defined AdCP item schema, so formats can declare `catal
 
 ## Typed catalog assets
 
-Vertical catalog items support an `assets` array using the same `OfferingAssetGroup` structure as offering-type catalogs. This solves a concrete problem: standard catalog feeds have a single `image_url` field, but a hotel ad on Snap needs a 1080×1920 vertical image, a display banner needs a 1920×1080 landscape hero, and the advertiser's logo goes in a separate slot. Without typed pools, a creative agent has to guess which image to use for which slot.
+Vertical catalog items support an `assets` array using the same `OfferingAssetGroup` structure as offering-type catalogs. This solves a concrete problem: standard catalog feeds have a single `image_url` field, but a hotel ad on Snap needs a 1080×1920 vertical image, a display banner needs a 1920×1080 landscape hero, and a property's item-level logo goes in a separate slot. Without typed pools, a creative agent has to guess which image to use for which slot.
 
 By providing assets grouped by role, each catalog item self-describes the images it carries:
 
@@ -160,13 +160,15 @@ By providing assets grouped by role, each catalog item self-describes the images
       "asset_group_id": "logo",
       "asset_type": "image",
       "items": [
-        { "url": "https://images.acmehotels.com/logo.png", "width": 400, "height": 200 }
+        { "url": "https://images.acmehotels.com/grand-amsterdam/logo.png", "width": 400, "height": 200 }
       ]
     }
   ]
 }
 ```
 
+**Catalog assets do not override master brand identity.** The creative manifest's `brand` reference resolves the master logo, palette, fonts, voice, and visual guidelines from `brand.json`, then applies the supported per-call fields in `brand_kit_override`. A catalog `logo` asset group represents item-level identity — for example, a hotel, property, or franchise logo — that a format may select through `field_bindings`; it does not replace the master logo or other brand identity fields from `brand.json`.
+
 The `asset_group_id` vocabulary is not standardized at the protocol level — each format defines which group IDs it uses via `offering_asset_constraints` in the catalog asset's `requirements`. Common conventions: `images_landscape` (16:9), `images_vertical` (9:16), `images_square` (1:1), `logo`, `video`. Video pools are first-class catalog asset groups alongside image pools — beyond the generic `video` pool, orientation-specific `video_vertical` (9:16) and `video_horizontal` (16:9) pool IDs let a feed carry per-orientation video the same way the image pools do.
 
 Formats use `field_bindings` (see [Format catalog requirements](#format-catalog-requirements)) to explicitly declare which template slot maps to which asset group.

static/schemas/source/core/brand-ref.json

@@ -2,7 +2,7 @@
   "$schema": "http://json-schema.org/draft-07/schema#",
   "$id": "/schemas/core/brand-ref.json",
   "title": "Brand Reference",
-  "description": "Reference to a brand by domain and optional brand_id. The domain hosts /.well-known/brand.json or is registered in the brand registry. For single-brand domains, brand_id can be omitted. For house-of-brands domains, brand_id identifies the specific brand.",
+  "description": "Reference to a brand by domain and optional brand_id. The domain hosts /.well-known/brand.json or is registered in the brand registry. For single-brand domains, brand_id can be omitted. For house-of-brands domains, brand_id identifies the specific brand. For creative production, brand.json is the canonical source of master brand identity (logo, palette, fonts, voice, and visual guidelines), subject only to the supported per-call fields in brand_kit_override. Catalogs supply product or item payload; catalog item asset groups, including property- or franchise-level logos, are item identity and do not override these master brand fields.",
   "type": "object",
   "properties": {
     "domain": {

static/schemas/source/core/creative-manifest.json

@@ -37,7 +37,7 @@
     },
     "brand": {
       "$ref": "/schemas/core/brand-ref.json",
-      "description": "Brand identity reference (BrandRef — `domain` plus optional `brand_id` for house-of-brands; plus optional inline `brand_kit_override` for per-creative tweaks where brand.json is missing/stale). When present, the seller pulls brand context (logos, colors, voice, taglines) from the brand's brand.json automatically; any `brand_kit_override` fields on the BrandRef take precedence. v2 formats no longer redeclare brand_logo / brand_colors / brand_voice as explicit slots — brand identity is implicit context."
+      "description": "Brand identity reference (BrandRef — `domain` plus optional `brand_id` for house-of-brands; plus optional inline `brand_kit_override` for per-creative tweaks where brand.json is missing/stale). When present, the seller pulls master brand identity (logo, palette, fonts, voice, and visual guidelines) from the brand's brand.json automatically; supported fields present in `brand_kit_override` take precedence, and all other master identity fields continue to come from brand.json. Catalogs supply product or item payload. Catalog item asset groups — including an item-level `logo` for a property or franchise — are item identity selected through format field bindings; they do not override brand.json's master logo or other brand identity fields. v2 formats no longer redeclare brand_logo / brand_colors / brand_voice as explicit slots — brand identity is implicit context."
     },
     "rights": {
       "type": "array",