Domain where /.well-known/brand.json is hosted, or the brand's operating domain
Optionalbrand_OptionalcountriesCanonical set of ISO 3166-1 alpha-2 countries for this advertiser identity. Omit for a global/default identity. Array order is not meaningful; producers MUST sort codes lexicographically before computing keys or signatures. This qualifies account identity and is not delivery targeting.
OptionalindustriesInline override for the brand's industries. Useful when the caller cannot modify the brand's canonical brand.json but needs to declare industries for governance (e.g., Annex III vertical detection). brand.json remains the canonical source; when omitted here, governance agents SHOULD resolve from brand.json.
Optionaldata_Inline override for the brand's contestation contact point. Useful when the operator does not control brand.json but needs to discharge Art 22(3) for this plan. brand.json is canonical; when omitted, governance agents resolve brand → house → missing.
Optionalbrand_Inline override for brand-kit fields normally resolved from /.well-known/brand.json on domain (logo, colors, voice, tagline). Use when brand.json is missing, stale, or inappropriate for this specific call — e.g., a campaign-scoped tagline, a co-branded creative, a freshly-rebranded color palette the brand.json hasn't shipped yet. Same inline-override pattern as industries and data_subject_contestation above: brand.json is canonical, the override is per-call. Adopters needing to override fields outside this subset (voice_attributes, prohibited_terms, etc.) MUST publish a different brand.json and reference it via a different domain — the inline override is intentionally narrow to a small high-traffic subset.
Merge semantics (normative). The merge is field-level, not whole-object replacement. Each field within brand_kit_override (logo, colors, voice, tagline) is evaluated independently — when a field is present on the override the override value applies; when a field is absent the brand.json value applies (or is absent if brand.json doesn't carry one either). For composite fields (colors.primary, colors.secondary, colors.accent), the merge is one level deeper: each color slot is evaluated independently — a producer can override colors.primary while still inheriting colors.secondary from brand.json. SDKs MUST NOT treat a present brand_kit_override.colors as wiping the brand.json colors block entirely; only the per-slot fields present in the override take precedence. Without this rule, a partial-override semantics would diverge across SDKs and produce inconsistent rendering for the same payload.
Optionallogo?: ImageAssetOptionalcolors?: { primary?: string; secondary?: string; accent?: string }Override brand colors (hex strings).
Optionalprimary?: stringOptionalsecondary?: stringOptionalaccent?: stringOptionalvoice?: stringOverride brand-voice description for surface-composed text/audio output.
Optionaltagline?: stringOverride tagline.
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.