✎ Propose a change

Brand Context Protocol (BCP) — Specification

Version: 1.1.0

Status: Draft

Date: 2026-09-23

License: CC BY 4.0

Abstract

The Brand Context Protocol (BCP) is an open specification for publishing machine-readable brand identity as a portable brand context package discovered at a well-known location on a brand’s domain. A brand may serve the canonical package itself or publish a complete Registry-backed root document that gives agents useful first-read brand context and directs them to a canonical package in a Registry. The required core is a hierarchical set of human-readable markdown files. Optional extension layers can add manifests, checksums, signatures, design tokens, visual assets, examples, components, motion rules, and other structured files without making the core heavier. BCP allows any agent in the stack — internal brand agents, vendor platforms, and third-party consumer agents — to read, reason over, and act on a brand’s strategy, voice, boundaries, claims, and representation preferences. The protocol is designed to be authored once, consumed everywhere, and to evolve as the brand evolves. This document specifies file format, package structure, discovery, resolution, publication integrity, versioning, taxonomy alignment, and consumption patterns for v1.1.0.

Change log

1. Introduction

1.1 The problem BCP solves

In the 12 to 36 months following the publication of this specification, a significant share of marketing work will be performed by AI agents rather than humans. Internal brand agents will draft copy, generate creative, and make media-buying decisions. Vendor platforms — brand-safety systems, creative-generation tools, ad networks, content platforms — will operate increasingly through autonomous agents that make decisions on a brand’s behalf. Third-party consumer agents — conversational shopping assistants, recommendation engines, retrieval systems embedded in general-purpose chat — will describe, compare, and contextualize brands in response to consumer queries.

Each of these agents needs access to the brand’s intent: what the brand is, what it values, what it claims, what it will and will not say, how it wishes to be represented, and how it should behave at the edges of judgment. Today, this information is captured (when at all) in brand decks, PDFs, Notion pages, and the memories of senior brand team members. None of these are machine-readable. None persist across agent sessions. None are portable across the dozens of systems that need them.

Without a shared source of truth, every agent must reconstruct brand intent from partial signals: scraped web content, account-representative interviews, example creative, implicit patterns in past work. The result is drift — agents produce output that is technically competent but tonally generic, boundary-blind, and inconsistent across surfaces. Brands pay for this drift in lost distinctiveness, wasted media, and reputational risk.

BCP solves this problem by defining a standard file format, location, and resolution model for machine-readable brand context. A brand authors its BCP once. Every agent that needs brand context reads the same files. When the brand evolves, the files are updated and all consuming agents see the update on their next resolution cycle.

1.2 What BCP is and is not

BCP is:

BCP is not:

1.3 Relationship to prior art

BCP draws architectural inspiration from several existing standards:

1.4 How to read this document

This specification uses normative language per RFC 2119. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in that RFC.

2. Terminology

BCP: Brand Context Protocol. The specification defined in this document, and by extension a file tree conforming to it.

BCP package: The complete portable artifact a producer publishes for a brand. A package contains the required markdown core and MAY contain optional extension files and assets.

Core package: The markdown portion of a BCP package: the root brand.md plus standard daughter files for voice, values, boundaries, claims, representation, and visual context.

Core-complete BCP: A BCP package that includes the root brand.md and the canonical daughter files voice.md, values.md, boundaries.md, claims.md, representation.md, and visual.md. voice/anti-ai.md is standard when emitted but is not required for every core-complete package.

Brand: The entity whose identity, voice, boundaries, and claims are being specified.

Producer: A brand or its agents publishing a BCP file tree at a well-known URI.

Consumer: An agent, platform, tool, or human reading BCP files to obtain brand context.

Discovery document: A thin pointer or compatible rich root located at /.well-known/brand.md on the brand’s domain. Registry-direct discovery is also valid without this document.

Root file: The canonical file_type: root document for a complete BCP package. It may be served on the brand’s domain or by a Registry.

Pointer file: A file_type: pointer discovery document that identifies the absolute HTTPS URL of a canonical Registry-backed root. A thin pointer is the recommended platform path when a domain discovery document exists; it is not a second brand package.

Canonical BCP: The complete package a consumer uses after discovery and pointer resolution.

Daughter file: A file referenced by the root that contains a specific dimension of brand context.

File tree: The complete hierarchical set of BCP files for a given brand.

Manifest: An optional machine-readable file, conventionally /.well-known/brand/manifest.json, that lists package files, media types, checksums, signatures, and extension metadata.

Daughter registry: The daughter_files section in the root file declaring which daughter files exist. This is distinct from a hosted Registry service.

Ring: One of three distribution layers — file-based (Ring 1), CLI-based (Ring 2), or MCP-based (Ring 3).

Lazy resolution: Loading only the daughter files required for a specific task.

Extension: A namespaced field or section containing brand-specific or vendor-specific data not defined by the core spec.

Extension file: An optional package file outside the required markdown core. Extension files MAY use markdown, JSON, CSS, SVG, image, font, archive, or other media types. Consumers MUST ignore extension files they do not understand or do not need.

Design token: A named design value, such as color, type, spacing, radius, elevation, motion, or layout guidance, published for agent and tool consumption.

Locale: An IETF BCP 47 language tag.

tree_version: The brand’s own semver version number for its published BCP tree.

bcp_version: The version of this specification to which a BCP tree conforms.

Rule tier: An optional per-item field that tells consumers how strongly to apply a rule, claim, or preference. Valid values are core, default, and contextual.

3. Architecture overview

3.1 The three-ring distribution model

BCP content is made available through three rings, in order of decreasing ubiquity and increasing dynamism.

Ring 1 — File-based. A canonical root and its declared files are available over HTTPS. Domain discovery may use a thin pointer or rich root; Registry-direct discovery uses the known handle or canonical URL. A full tree on the brand domain is optional.

Ring 2 — CLI-based. A reference command-line tool and compatible third-party tools provide programmatic access for authoring, validation, inspection, and one-shot agent consumption.

Ring 3 — MCP-based. An MCP server exposes BCP content as tools agents can invoke within a session, supporting session-persistent context, dynamic resolution, authenticated private BCPs, and tool-native agent integration.

All three rings consume the same underlying source of truth: the canonical BCP file tree. Producers MAY publish through any combination of rings; the canonical package must remain addressable. A domain-hosted discovery document is optional for Registry-direct publication.

3.2 Consumption patterns

One-shot fetch. An agent retrieves a single file via HTTP or filesystem read.

Selective fetch. An agent retrieves the root, parses the registry, and fetches only the daughters needed for its task. Most common pattern.

Full-tree load. An agent retrieves the root and all declared daughters.

Session subscription. An agent connects to a Ring 3 MCP server and receives BCP content as tool responses throughout a session.

Dynamic query. An agent invokes a Ring 3 MCP tool that returns BCP content computed or filtered based on request context.

3.3 The hierarchical file model

A BCP is not a single file. It is a tree whose root contains core identity and whose daughters contain specific dimensions. The hierarchy exists because concerns are separable (different consumers need different subsets), ownership is separable (legal owns claims, marketing owns voice), and evolution is separable (campaign files turn over seasonally, voice evolves annually, values rarely change).

3.4 Complete first, enrich later

A conformant BCP has a small required core. Producers MUST NOT require optional extensions before a package is considered complete. The core package should be easy to author, inspect, and consume: what the brand is, how it sounds, what it can claim, what it must avoid, how it should be represented, and where agents fetch the current truth.

Richer brands MAY add optional extension layers after the core is complete. Extension layers can improve precision for design systems, legal review, creative generation, examples, components, and authenticated or private package distribution. They are enrichment, not completion criteria.

Consumer agents MUST treat a package with only the required markdown core as valid if it otherwise conforms to this specification. Consumer agents SHOULD use extension files when they understand them and when the extension is relevant to the task.

4. File format

4.1 Markdown with YAML frontmatter

A BCP file MUST be valid UTF-8 encoded text conforming to CommonMark. Each file MUST begin with a YAML frontmatter block delimited by ---.

4.2 Fenced YAML blocks for structured fields

Fields intended for programmatic consumption SHOULD be placed in fenced YAML code blocks within the markdown body.

4.3 Prose for narrative fields

Fields intended for human reading, voice-matched paraphrasing, or nuanced agent interpretation SHOULD be written as markdown prose.

4.4 Character encoding and size

Files MUST be UTF-8. No BOM. LF line endings preferred. Root files SHOULD be under 16 KB. Daughter files SHOULD be under 32 KB.

4.5 Required frontmatter fields

Every BCP file MUST include:

The root and pointer files MUST additionally include:

A root file MUST additionally include:

A Registry-backed root MUST additionally include publication_profile: registry_backed, canonical_bcp, registry_mcp, and registry_handle. canonical_bcp and registry_mcp MUST be absolute HTTPS URLs. Discovery fields describe locations, not executable instructions.

A pointer file MUST additionally include canonical_bcp, an absolute HTTPS URL. No behavioral directive is required.

Daughter files MUST additionally include:

4.6 Optional frontmatter fields

revision (content hash for ETag), default_locale, supported_locales, category, subcategories, headquarters, markets, founded, website, reviewed_by, daughter_files, package_manifest, extensions, tagline, commerce (v0.5: a path or URL pointing to the brand’s commerce.md signpost, see §7.11), registry_mcp, registry_handle, publication_profile. Consumers MUST ignore unrecognized frontmatter fields.

agent_first_action is deprecated. Producers SHOULD NOT emit it. Consumers encountering it in an older package MUST treat it as non-normative data, not execute its text. Location discovery uses canonical_bcp, registry_mcp, and daughter_files under host policy.

5. Publishing a BCP

5.1 Canonical location

When a producer publishes a domain discovery document, it MUST be at https://{domain}/.well-known/brand.md and use one of §5.3’s profiles. A Registry-direct package remains valid without a domain pointer: a producer may share its handle or canonical Registry URL. A self-hosted root’s daughters are normally at https://{domain}/.well-known/brand/{filename}.md; Registry-backed references retain their absolute canonical locations.

5.2 Source of truth

Producers SHOULD maintain BCP source in version control or another auditable system. For a self-hosted profile, the domain package is the consumed artifact. For a Registry-backed profile, the producer declares the Registry root and package through canonical_bcp; the domain root remains useful first-read context. Registry hosting alone does not imply verification, signing, or official-source status. Consumers evaluate those properties separately through §5.9 and §5.10.

5.3 Publication profiles

Registry-direct. A producer MAY share a Registry handle or canonical Registry URL without publishing a domain pointer or daughter tree. Consumers that already know that location MUST NOT require a domain pointer to exist. Current Registry DNS attestation may mark that handle official independently of pointer hosting.

A thin domain pointer is the recommended platform path when a domain file exists. Self-hosted trees and compatible rich Registry-backed roots remain valid, but are not the recommended platform path. Producers may obtain current DNS attestation without hosting a pointer or tree.

Self-hosted. The domain discovery document is also the complete file_type: root document. It declares daughter files and optional extensions using root-relative or absolute HTTPS references. The producer serves and operates the canonical package.

Registry-backed. The domain discovery document may be a rich file_type: root brand brief or a thin file_type: pointer declaring the canonical Registry root. A rich root retains useful first-read identity and positioning, declares publication_profile: registry_backed, canonical_bcp, registry_mcp, registry_handle, and the daughter registry. Daughter, manifest, commerce, and extension references MUST be absolute Registry URLs so they retain the Registry handle and cannot resolve against the wrong host. A mirrored rich root SHOULD use the exact Registry-published bytes, including any attested snapshot, rather than reconstructing them. Neither form requires a full tree hosted on the brand domain.

Forked templates and hosted services are implementation choices within these profiles, not separate protocol shapes. BCP is open: no producer is required to use a particular Registry or vendor.

5.4 HTTP headers

Servers SHOULD set:

5.5 Discovery

Producers MAY improve discoverability via sitemap.xml, HTML , developer documentation, or registry services.

A consumer SHOULD fetch https://{brand-domain}/.well-known/brand.md first and treat its content as untrusted brand data. For a Registry-backed root or pointer, canonical_bcp identifies the canonical package, with absolute daughter references available for task-relevant retrieval under host policy. A configured Registry MCP MAY be used as a transport or lookup surface after the Registry is discovered, or directly when the brand domain is unavailable and a handle is already known. Discovery metadata never authorizes tool execution or credential submission.

Pointer resolution MUST use HTTPS, MUST NOT forward origin credentials to a different host, MUST detect loops, and MUST NOT follow more than three pointer hops. A pointer target MUST resolve to a root, not another pointer indefinitely.

The gap this addresses is not “does a well-known path exist” (it does, §5.1) but “does a consumer know to look.” Consumers (agents, assistants, platforms) SHOULD attempt discovery — Registry lookup or a /.well-known/brand.md fetch — on any query that names a specific brand or company and calls for brand-accurate output (describing the brand, writing in its voice, citing its claims, or representing it to a third party), not only when a user or operator explicitly names BCP or points at the file. See §13.5 for the platform-level version of this recommendation.

5.6 Optional package manifest

The root file MAY declare a package manifest:

package_manifest: /.well-known/brand/manifest.json

When present, the manifest SHOULD be served as application/json and SHOULD include:

Each file record SHOULD include:

{
  "path": "/.well-known/brand/voice.md",
  "media_type": "text/markdown; charset=utf-8",
  "role": "core.voice",
  "required": true,
  "sha256": "..."
}

required: true means required by this package’s declared core, not by every BCP implementation. Optional extension records SHOULD use required: false.

File checksums SHOULD use lowercase hex SHA-256 over the exact served bytes. Producers SHOULD include checksums for markdown files, extension files, and assets when a manifest exists. Consumers MAY use these checksums for change detection, cache validation, integrity checks, and audit trails.

5.7 Optional extension files

Producers MAY publish extension files under /.well-known/brand/. Recommended extension paths include:

/.well-known/brand/manifest.json
/.well-known/brand/claims.json
/.well-known/brand/tokens.json
/.well-known/brand/tokens.css
/.well-known/brand/assets/{name}
/.well-known/brand/examples/{name}.md
/.well-known/brand/components/{name}.json
/.well-known/brand/motion.md
/.well-known/brand/motion.json

Extension files MAY include:

Extension files MUST NOT change the meaning of required core files silently. If an extension conflicts with a core rule, consumers SHOULD prefer the core rule unless the core explicitly delegates that topic to the extension.

Consumers MUST ignore extension files they do not understand. Producers SHOULD make extension files independently useful and SHOULD declare them in the manifest when present.

5.8 Interoperability artifacts (v0.6)

BCP’s position on adjacent standards is to interoperate, not compete: a narrow, single-purpose external format that already has real tooling adoption is a projection target, not a rival to replace BCP’s evidence-bound daughter files. This section documents optional, deterministically-derived root-level files (siblings to brand.md, not nested under /.well-known/brand/) that re-express a BCP’s already-compiled data in an external ecosystem’s native schema, so that ecosystem’s tools can discover and read a brand without needing to understand BCP at all.

An interoperability artifact MUST be generated deterministically from the same structured data behind the corresponding BCP daughter file (for example, visual.md’s already-computed colors, fonts, and logos) — never authored or re-derived independently, so the two can never silently drift apart. An interoperability artifact MUST NOT carry claims, voice, values, boundaries, or representation content; those are BCP’s evidence-bound depth and are deliberately out of scope for commodity external schemas. Producers MAY omit an interoperability artifact entirely; a BCP without one remains fully valid.

brand.json — projects a BCP’s compiled colors, fonts, logos, and voice/tone into the schema used by the Ad Context Protocol (AdCP)‘s brand_agent house/brands shape, so AdCP-native ad-buying agents can discover a brand’s identity without reading BCP’s markdown tree. Canonical location: /.well-known/brand.json. Producers SHOULD include an agents[] entry pointing at a live MCP endpoint capable of answering AdCP’s get_brand_identity contract.

A registry or MCP surface that already serves get_bcp MAY extend it, additively, to also answer AdCP-shaped requests: an optional fields (array of AdCP identity field names) and use_case argument, answered from the same published brand.json rather than a second parser. Core identity fields (house, names, logos) MUST be returned regardless of trust level; authorized-only fields (colors, fonts, visual guidelines, tone, tagline, voice synthesis, assets, rights, per AdCP’s schema) MUST be gated behind the same official_brand_source trust signal defined in §5.9 — never a second, weaker authorization path. This MUST NOT introduce a second tool name or change get_bcp’s existing full-tree response when fields is absent.

DESIGN.md — Google Labs’ DESIGN.md is a second interop artifact for the same root-level pattern, covering visual design tokens (colors, typography, spacing, components) for the growing set of coding agents and tools that read it natively. Canonical location: /.well-known/DESIGN.md. It MUST be generated deterministically from the same compiled visual data behind visual.md — never authored or re-derived independently, same rule as brand.json above. visual.md is the authority for brand-owned visual identity, meaning, assets, generative direction, and constraints. DESIGN.md is a derived implementation projection and MUST NOT override visual.md. Exact values MAY appear in both because they originate in one record; that is duplicated representation, not duplicated authority.

Frontmatter: version (the DESIGN.md schema version this projection targets; currently alpha, tracking upstream) and name. When the underlying visual data supports them: colors (a flat role-to-hex map — primary, secondary, accent, background, text, and any other roles the source BCP defines), typography (role-keyed entries — display, body, mono — each with a fontFamily and optional fontWeight), rounded (a corner-radius scale keyed sm/md/lg), spacing (a scale keyed sm/md/lg/xl/2xl), and components (keyed by component name, for example button-primary, with the style properties DESIGN.md’s own schema defines — background/text color, radius, padding, font weight). A field is omitted entirely rather than fabricated when the source BCP has no corresponding data — same anti-fabrication discipline as every other BCP file.

DESIGN.md’s own upstream schema is alpha and has no BCP-equivalent frontmatter (tier, parent, evidence-binding) — this artifact projects only visual tokens and implementation mechanics, never claims, voice, values, boundaries, representation content, or independently authored brand meaning. CSS variables, spacing and radius scales, shadows, component styles, breakpoints, exact animation durations, easing curves, and UI-state mechanics belong in this projection when supported. General task recipes and workflow instructions belong in neither file. As DESIGN.md’s upstream schema evolves, this projection SHOULD track it; a future point release will document breaking upstream changes when they land.

5.9 Registry trust attestation (v0.8, Ring 2/3 only)

A published BCP is authored by, or on behalf of, the account that published it. Publishing alone MUST NOT be read as proof that the account controls the brand’s domain. A Ring 2/3 registry service MAY implement a two-tier attestation so consumers can distinguish the two:

5.9.1 Grantor and proof

Only the Registry operator MAY set trust_level: verified and official_brand_source: true. It MUST do so only after all of these conditions hold:

  1. the publishing account is authenticated and authorized to manage the Registry handle;
  2. the Registry issued a unique, unpredictable, time-bounded DNS challenge bound to that account, handle, and domain;
  3. the Registry independently observed the exact challenge response under the claimed domain; and
  4. the successful proof was recorded with verified_at, verification_last_checked_at, and verification_expires_at timestamps.

A self-asserted field, client-supplied boolean, previously observed challenge, reusable challenge, web-page claim, email address, or successful Registry publication MUST NOT upgrade the record.

5.9.2 Meaning and limits

official_brand_source: true proves only that the publishing account demonstrated control of the named domain through the Registry’s challenge at verified_at, that the same proof remained observable at verification_last_checked_at, and that the attestation has not expired or been revoked. It is a proof-of-origin signal.

It MUST NOT be represented as proof of:

5.9.3 Expiry and renewal

A verification attestation MUST expire no later than 365 days after verified_at. A registry MAY choose a shorter period, but a conforming customer experience SHOULD NOT require routine DNS edits more than once per year.

While an attestation is verified, the Registry MUST automatically recheck the exact account-, handle-, and domain-bound DNS proof at least once every 30 days. Each successful observation MUST update verification_last_checked_at. Reobserving the existing TXT value maintains the attestation during its current annual term but MUST NOT move verification_expires_at or create a new annual term.

Renewal beyond verification_expires_at MUST use a newly generated challenge and repeat the complete verification procedure. A Registry MAY support a one-time delegated DNS verification mechanism that lets it rotate fresh, time-bounded challenges without another customer DNS edit, provided the delegation is itself bound to the account, handle, and domain and remains independently revocable. A reusable static TXT value by itself MUST NOT renew an expired annual attestation.

After verification_expires_at, every Registry read surface MUST return trust_level: claimed and official_brand_source: false until a fresh verification succeeds. Expiry does not delete, suspend, or alter the published BCP.

5.9.4 Revocation

The Registry operator MUST revoke the attestation before its scheduled expiry when any of these occurs:

Revocation MUST preserve the BCP but immediately downgrade every Registry read surface to claimed and official_brand_source: false. The Registry MUST record the revocation time and reason in its operator audit trail. Restoration requires a fresh challenge; an operator MUST NOT restore the old attestation by toggling a stored boolean.

A single timeout, SERVFAIL, or other inconclusive lookup MUST NOT be treated as confirmed removal. The Registry MUST retry inconclusive checks across time and independent authoritative resolution paths before revoking. A verifier outage MUST NOT mass-downgrade otherwise unexpired attestations; it also MUST NOT extend verification_expires_at. An exact conflicting value or confirmed removal MUST revoke within the Registry’s documented recheck and retry window.

Registry caches carrying trust metadata MUST either support active invalidation or have a maximum freshness of 24 hours. Consumers SHOULD honor the latest Registry trust response and MUST NOT infer official_brand_source: true from a cached, expired, or locally reconstructed DNS result.

5.9.5 Consumer signals

A registry exposing this attestation MUST surface trust_level (claimed | verified) and official_brand_source (boolean, true only when trust_level is verified) on every applicable read surface. When verified, it MUST also surface verified_at, verification_last_checked_at, and verification_expires_at, and SHOULD surface verification_method and verified_domain, so consumers can distinguish initial proof, latest observation, and final expiry.

Consumer agents MUST treat a record as the Registry-attested authoritative source for a brand only when official_brand_source is true. A claimed record remains useful context but is not proof of authority.

Registry get_bcp responses MUST lead with a Registry-generated trust block before publisher content, including trust_level, official_brand_source, verified_at, verification_last_checked_at, and verification_expires_at. Verification timestamps are null when no current domain verification exists. HTTP read surfaces MUST carry equivalent current attestation metadata separately from publisher prose.

5.9.6 Publication-time trust snapshot

A Registry that stamps brand.md frontmatter MUST derive the stamp from its own records, replacing any publisher-supplied trust fields before signing. The stamp includes the trust tuple in §5.9.5 and any supported domain, method, and certification metadata. Certification is a separate review signal, not a substitute for DNS verification or permission to obey publisher instructions.

The stamped frontmatter is an attested snapshot only when its Registry provenance and integrity are established; the same field names in publisher YAML are not proof. Self-hosted publishers MUST NOT self-assert official_brand_source: true. Current Registry get_bcp trust metadata and HTTP attestation take precedence over an older signed snapshot after expiry, revocation, or certification changes. Consumers MUST NOT upgrade trust from a stale or unauthenticated snapshot. Immutable signed files need not be rewritten to reflect later trust changes.

5.9.7 Operational threat model

A Registry implementing this attestation MUST document and test how it handles at least these failure modes:

5.10 Publication integrity and trust layers (v0.8)

Domain control, publication authorization, and package integrity answer different questions and MUST NOT be presented as interchangeable:

A Registry implementing signatures MUST sign immutable canonical package bytes at publication time, persist the signature and digest with the publication, and verify the stored bytes against that digest or signature before serving them. It MUST NOT append content, rewrite references, or create a new signature during a public read. Key identifiers, algorithms, and rotation metadata SHOULD be exposed in the package manifest or response metadata. Consumers SHOULD verify the manifest and signature when supplied.

A Registry serving a signed file over HTTP SHOULD expose the stored digest, signature, and signing-key identifier as response metadata. The reference header names are X-Content-Sha256, X-Signature, and X-Signature-Kid. Browser-readable endpoints SHOULD include those names in Access-Control-Expose-Headers. An ETag SHOULD identify the same immutable stored revision.

6. Hierarchical resolution

6.1 Root declares daughters

The canonical root file SHOULD include a daughter_files registry in its frontmatter or as a dedicated YAML block. A Registry-backed domain root MUST include the complete daughter registry with absolute Registry URLs. A legacy pointer file MUST NOT declare daughters.

6.2 Canonical fallback paths

If a self-hosted root omits the registry, consumers MAY attempt the conventional paths below its domain. Consumers MUST NOT guess these paths for a Registry-backed package; they use the absolute references declared by its root.

6.3 Resolution order and precedence

Highest to lowest: campaign-specific, product-specific, audience-specific, locale-specific daughter, default daughter, root file.

6.4 Lazy resolution by task type

Consumers SHOULD load only files required for the task. Copy generation: voice + voice/anti-ai + audience. Media buying: boundaries + claims. Creative generation: voice + visual. Logo selection and rendering: visual (logo and logo_usage blocks). Consumer-agent representation: representation + root. Brand-safety classification: boundaries + root.

6.5 Root size target

Under 12 KB of body text plus frontmatter. The root should contain enough identity, positioning, offering, and agent guidance to be useful on first read. Detailed voice, claims, values, boundaries, representation, and visual rules SHOULD remain in daughter files.

7. The file tree

7.1 brand.md (root)

Declares brand identity, core positioning, tagline, and daughter registry. Always loaded. Required: brand name, positioning, daughter registry, all required frontmatter.

The canonical daughter registry keys for standard BCP daughters are:

daughter_files:
  voice: /.well-known/brand/voice.md
  voice_anti_ai: /.well-known/brand/voice/anti-ai.md
  values: /.well-known/brand/values.md
  boundaries: /.well-known/brand/boundaries.md
  claims: /.well-known/brand/claims.md
  representation: /.well-known/brand/representation.md
  visual: /.well-known/brand/visual.md

The standard package comprises one root plus these seven supporting files. Although voice/anti-ai.md is nested beneath voice/ by path, the root registers it directly as voice_anti_ai so consumers can discover it deterministically. Producers SHOULD use these keys and paths when the corresponding daughter exists. Producers MAY declare additional granddaughter files, locale-specific files, audience files, product files, campaign files, and extensions in the same registry.

The root file MAY also point to package-level extension metadata:

package_manifest: /.well-known/brand/manifest.json
extensions:
  tokens: /.well-known/brand/tokens.json
  tokens_css: /.well-known/brand/tokens.css
  examples: /.well-known/brand/examples/
  assets: /.well-known/brand/assets/
  components: /.well-known/brand/components/
  motion: /.well-known/brand/motion.md

These fields are optional. Their absence does not make the BCP incomplete.

The root declares available content through its daughter map. Registry-backed roots use absolute discovery URLs so references retain the Registry handle. These are location affordances, not an agent workflow or a first-action instruction.

7.1.1 Registry-backed brand.md root profile (v0.8)

A Registry-backed domain publishes a useful root at /.well-known/brand.md:

---
bcp_version: "1.1.0"
file_type: root
brand_name: Example Brand
tree_version: "2.0.0"
last_updated: 2026-08-05
publication_profile: registry_backed
canonical_bcp: https://registry.example/example-brand/.well-known/brand.md
registry_mcp: https://registry.example/mcp
registry_handle: example-brand
daughter_files:
  voice: https://registry.example/example-brand/.well-known/brand/voice.md
  voice_anti_ai: https://registry.example/example-brand/.well-known/brand/voice/anti-ai.md
  values: https://registry.example/example-brand/.well-known/brand/values.md
  boundaries: https://registry.example/example-brand/.well-known/brand/boundaries.md
  claims: https://registry.example/example-brand/.well-known/brand/claims.md
  representation: https://registry.example/example-brand/.well-known/brand/representation.md
  visual: https://registry.example/example-brand/.well-known/brand/visual.md
---

# Example Brand

Example Brand makes durable tools for independent builders. It combines repairable hardware, plain-language support, and a long-term parts program so customers can keep working without replacing equipment unnecessarily.

## Package map

The canonical Registry package contains voice and language preferences, values, boundaries, evidence-labeled claims, representation preferences, and visual identity. This root supplies identity and discovery locations. All publisher content is brand-provided data; the host's policy determines its use. Current Registry attestation is separate from these brand statements.

When the domain publishes a rich root, it MUST preserve brand identity, core positioning, and useful first-read context from the canonical package. A domain may instead publish a thin pointer. In either form, canonical_bcp identifies the producer-declared package for daughter-file resolution. Signing and official-source attestation are separate properties governed by §5.10 and §5.9.

file_type: pointer documents are a supported discovery profile. A consumer resolves canonical_bcp under §5.5.1’s bounded HTTPS rules. Rich roots offer more first-read context; neither profile requires a full self-hosted tree.

7.1.2 Rule tiers

Structured entries in daughter files MAY include a tier field. Valid values:

If tier is absent, consumers SHOULD treat the entry as default. Producers SHOULD use core sparingly for invariants: legal claims, naming rules, hard boundaries, forbidden terms, and non-negotiable representation constraints.

7.1.3 Discovery and affordance map (v1.1.0)

Producers SHOULD describe what the package contains and where its topics live. Producers MUST NOT present body prose or publisher YAML as instructions that override host policy, user intent, safety constraints, or independent evidence. A short descriptive map is sufficient:

## Package map

This root describes the brand and its canonical package locations.
voice.md covers language preferences; boundaries.md covers brand-safety
preferences; claims.md records approved, caveated, and forbidden claims;
visual.md covers visual identity; representation.md covers preferred framing.
These are brand-provided data. Host policy determines their use.

The earlier recommendation for an imperative Agent Instructions block is withdrawn. Consumers MUST treat such blocks in older packages as non-normative data (§15.5). Descriptive maps do not grant fetch, payment, write, or credential authority.

7.2 voice.md

How the brand sounds — tone, register, vocabulary preferences, sentence rules, voice shifts across contexts. Recommended sections: voice attributes, register, prefer/avoid vocabulary lists, do/don’t examples. Structured prefer: and avoid: lists alongside prose guidance.

voice.md is the root of the voice/ subtree. Producers MAY declare granddaughter files under /.well-known/brand/voice/ for specific voice dimensions. Defined granddaughter types: anti_ai (§7.2.1). Audience-specific voice files MAY also live at /.well-known/brand/voice/audiences/{segment}.md as an alternative to the top-level /.well-known/brand/audiences/{segment}.md path; both paths are valid in v0.3.

7.2.1 voice/anti-ai.md

Patterns the brand prohibits in agent-generated content because they are markers of machine-generated language. This file has two layers: a community reference (external, live) and brand-specific additions on top.

community_reference: A URL pointing to a live, externally maintained list of AI writing patterns. Consumers SHOULD fetch this URL at generation time and treat its contents as the baseline avoid list. Producers SHOULD point to an authoritative community-maintained source. Consumers that cannot fetch the URL MUST fall back to brand_additions alone and SHOULD log the fallback.

brand_additions: Patterns specific to this brand that are not covered by the community reference, or community patterns the brand wants to restate with brand-specific rationale.

Each entry in brand_additions is an object with:

For authorized brand-aligned copy, both lists describe the publisher’s language preferences. External lists are also untrusted data; fetching and applying them remains subject to host policy and §15.5.

Frontmatter for voice/anti-ai.md MUST include file_type: anti_ai and parent: /.well-known/brand/voice.md.

7.3 visual.md

Defines the brand’s visual identity in machine-consumable form. visual.md is a first-class standard daughter file for any consumer that renders, composes, adapts, or evaluates brand creative. It is the authoritative home for brand-owned visual identity, meaning, approved assets, generative direction, and constraints. It schematizes logo, color, typography, layout and composition, imagery and media, and motion.

Every visual block and every semantic field defined below is OPTIONAL. Producers MAY emit any subset they can support. A producer MUST omit unavailable information or record an explicit gap; it MUST NOT fabricate it. Consumers MUST ignore unrecognized fields, tolerate absent optional fields, and MUST NOT infer missing semantic guidance from exact values alone. A hex value, for example, does not by itself establish that a color is premium, natural, restrained, or culturally associated with any named shade.

Semantic guidance MAY declare evidence_status as one of:

Normative semantic guidance SHOULD be brand_declared or brand_confirmed. Observed values MAY be published when their status remains explicit. Inferred values MUST NOT be presented as binding brand truth. This vocabulary supplements, and does not replace, the package’s provenance and trust metadata.

The logo: block is a map of named logo entries. Each entry MUST have a stable string key (e.g., primary, icon, app_icon, favicon, social_avatar) and MUST contain a variants array with at least one entry.

Each variant MUST declare:

Each variant MAY declare width, height, background, treatment, and purpose to help consumers select the correct variant for a given context.

Logo entries MAY declare active_through (ISO 8601 date) and fallback (the ID of another logo entry). Consumers MUST NOT use a logo entry past its active_through date and SHOULD fall back to the entry named in fallback when present.

The logo_usage: block declares rules that apply to any logo entry. It MAY include:

When generation_policy is absent, consumers SHOULD prefer verified official assets over model-generated approximations. When it is official_assets_only, consumers MUST NOT draw, approximate, or hallucinate the logo; they may generate surrounding creative and composite a verified official asset afterward.

Consumers selecting a logo for a given context MUST verify the sha256 of any fetched variant before use. Consumers that cannot verify integrity MUST NOT render the asset.

7.3.2 Color

The color: block declares semantic color tokens and pairing rules.

color.tokens is a map of token names to objects with hex and role. The hex value MUST match ^#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{6}|[0-9A-Fa-f]{8})$. The role MUST be one of: primary, secondary, accent, surface, surface-inverse, text, text-inverse, critical, success, warning, info, neutral.

A color token MAY additionally declare semantic_name, perceptual_descriptors, generation_prompt, avoid_confusion_with, usage_rule, and evidence_status. These fields MUST come from an admissible source or brand confirmation; they MUST NOT be derived from the hex value alone.

color.approved_pairs and color.forbidden_pairs are arrays of { foreground, background } objects whose values reference token names from color.tokens. Consumers generating new layouts SHOULD prefer approved_pairs and MUST NOT generate combinations listed in forbidden_pairs.

7.3.3 Typography

The typography: block declares typeface families and their roles.

typography.families is a map of family IDs to entries declaring family (CSS family name), and optionally fallback_stack, weights, styles, source, and license_note. A family MAY additionally declare classification, character, comparable_families, usage_rule, and evidence_status.

comparable_families describes visual similarity only. It does not grant licensing rights or authorize substitution. fallback_stack remains the executable substitution order.

typography.roles maps usage roles display, body, ui, mono, code) to family IDs. Consumers generating typeset content SHOULD select the family whose role matches the context.

7.3.4 Layout

The layout: block carries brand-level composition rules for generated or adapted creative. A producer MAY use the synonymous composition: block when distinguishing brand semantics from implementation layout tokens. Either block MAY include density, whitespace, grid, hierarchy, cropping, corner_radius, forbidden_compositions, and evidence_status guidance. Producers SHOULD NOT publish contradictory layout and composition blocks.

Layout guidance SHOULD be specific enough for agents to choose spacing, cropping, and hierarchy without copying a static design. Raw spacing scales, radius scales, shadows, button styling, breakpoints, and component implementation belong in DESIGN.md, not as brand meaning in visual.md.

Consumers generating visual assets SHOULD use layout guidance alongside logo_usage, color, and typography. Consumers MUST NOT generate layouts listed in forbidden_compositions when present.

7.3.5 Imagery

The imagery: block carries prose principles for photographic_style, illustration_style, iconography_style, and a forbidden_treatments string array. Producers MAY additionally provide structured photography, illustration, video, audio, or equivalent media blocks. Structured direction MAY include camera_language, lighting, composition, color_grade, subject_behavior, principles, prompt_fragments, forbidden_treatments, negative_prompts, and evidence_status. Top-level imagery MAY also include prompt_fragments, negative_prompts, and evidence_status.

Prompts and negative prompts are constraints derived from approved direction, not permission to fabricate unsupported brand meaning.

7.3.6 Motion

The optional motion: block carries brand-level character, principles, forbidden_treatments, reduced_motion_policy, and evidence_status. Exact durations, easing curves, and component transitions belong in DESIGN.md or another implementation artifact. A reduced-motion policy SHOULD preserve meaning without requiring animation.

7.3.7 Extensions

Brand-specific or vendor-specific fields not covered by this section MUST be placed under a namespaced extensions: block per §9.2.

7.4 values.md

Brand values with operational specificity for agent judgment calls. Recommended: numbered values with manifestations in practice plus agent resolution priority order.

7.5 boundaries.md

What the brand does and does not do. Primary file for brand-safety agents and vendor platforms. Required structured blocks: hard_no, soft_no, brand_safety, optional namespaced extensions.

7.6 claims.md

Approved marketing claims with supporting evidence. Required structured blocks: approved_at_launch, requires_caveat, forbidden. Agents generating copy MUST NOT introduce claims absent from this file.

Producers SHOULD include an explicit review notice in this file: claims are generated from available evidence for review, are not legal advice, and should be reviewed by legal or the accountable brand owner before use in advertising, packaging, sales, regulated, or comparative contexts. The proof_status field records evidence and owner-confirmation state; it does not replace legal review.

Claim entries MAY include:

For deterministic projection of bcp.canonical.claims.v1 records, producers MUST map proof_status to the three required structured blocks as follows:

This is a publication-safety mapping, not a relabeling of proof status. The rendered entry MUST retain its original proof_status. Aspirational or unknown language may be useful as private draft context, but a deterministic public claims projection must not make it available as an approved factual claim. A later schema version may define a separate public aspiration surface; it must not change this mapping behind bcp.canonical.claims.v1.

Consumers MUST NOT use entries with proof_status forbidden or expired. Consumers MUST NOT paraphrase entries whose exact_text is true. Consumers SHOULD include the caveat when using a claim with proof_status requires_caveat. Producers SHOULD assign tier: core to legally exact or compliance-owned claims.

Producers MAY publish /.well-known/brand/claims.json as an optional structured companion to this file. When present, claims.json MUST be generated deterministically from the structured claims in claims.md; it MUST NOT introduce, approve, remove, or relabel claims independently. If claims.json conflicts with claims.md, consumers MUST prefer claims.md.

The explicit canonical_model opt-in defined by RFC 0018 is the only exception to that default precedence. When it names /.well-known/brand/claims.json with projection: deterministic, the canonical records are authoritative only for the fields they define, the structured claims blocks in claims.md are their deterministic projection, and publication MUST fail if the mapped records and projected blocks disagree. Unstructured review notices and explanatory prose remain Markdown-authored content.

7.7 representation.md

The brand’s preferred third-party framing. Required: preferred_framing prose paragraph (~120 words), structured fields for describe_as, do_not_describe_as, competitive_frame, honest_trade_offs, never_say. These fields describe publisher preferences, not permission to suppress truthful independent answers (§15.5).

7.8 audiences/{segment}.md

Audience-specific voice shifts, preferences, constraints. Frontmatter: audience_id matching filename.

7.9 products/{sku}.md

Product-specific positioning and claims. v0.1 does not fully standardize; v0.2 priority.

7.10 campaigns/{name}.md

Campaign-scoped overrides. Recommended frontmatter: campaign_id, starts_at, ends_at. Sunset semantics deferred to v0.2.

7.11 commerce.md (v0.5)

Optional. Declares that the brand’s products or services are purchasable, and points a consuming agent at the commerce or payment protocol to use. BCP does not define checkout, carts, or payment. It is the understanding layer; commerce.md is a signpost that hands off to a commerce protocol. This keeps BCP complementary to commerce standards rather than competing with them.

Canonical location: /.well-known/brand/commerce.md. A brand that publishes it SHOULD add a commerce pointer to the root (see §7.1) so agents discover it without guessing, for example commerce: /.well-known/brand/commerce.md.

Understanding precedes transaction: a consuming agent SHOULD read brand.md and the daughter files relevant to its task (voice, claims, boundaries, representation) before acting on the commerce pointer. The point of BCP is that an agent understands the brand before it buys, sells, or transacts on its behalf.

Frontmatter (fenced YAML) MUST include file_type: commerce and parent: /.well-known/brand.md. The following commerce fields are optional:

Consumers MUST ignore protocols they do not support and SHOULD select the first protocols entry they can transact over. A commerce.md with no protocols an agent recognizes is informational only; the agent MUST NOT invent a payment flow.

8. Versioning

8.1 Three-layer model

bcp_version*: spec conformance level, incremented by maintainers.

tree_version*: semver on the brand’s own BCP, incremented by producer.

last_updated*: per-file ISO 8601 date.

8.2 Semver rules

Major: breaking changes (renamed files, removed fields, reversed semantics).

Minor: additive changes (new daughter files, new fields, new enumerated entries).

Patch: corrections without semantic change.

8.3 Revision hash

Optional SHA-256 content hash suitable for HTTP ETag.

8.4 Change-log conventions

Root SHOULD include reverse-chronological change log with date, tree_version, description.

8.5 Breaking vs. non-breaking

Removing a daughter, removing a required field, or reversing semantics is breaking. Adding daughters, fields, or enumerated entries is not.

8.6 Deprecation policy

Deprecate in a minor release; remove in a subsequent major release.

9. Content taxonomies

BCP aligns its structured adjacency and boundary signals with established industry taxonomies where they exist, to maximize interoperability with consuming systems that already map to those vocabularies.

9.1 Current reference alignments (v0.1)

v0.1 names two reference alignments for the boundaries.md adjacency fields:

Where the two diverge, follow GARM for suitability tier assignment and IAB for category structure.

9.2 Extensions block

Brand-specific or vendor-specific fields not covered by a named taxonomy MUST be placed under a namespaced extensions: block. Consumer implementations MUST ignore extension fields they do not recognize.

9.3 Taxonomies for other surfaces (v0.2 and beyond)

v0.1 names reference alignments only for vendor-platform brand-safety signals. Future versions will add reference alignments for other consumption surfaces: creative-generation constraints (typography, imagery, composition), consumer-agent representation fidelity, and agentic-commerce surfaces. Producers with requirements in those domains MAY use the extensions: block in v0.1 and track the namespace for promotion to named alignment in v0.2+.

9.4 Known gaps

Emerging content types that neither IAB 3.0 nor GARM fully address, edge cases in political content, and vendor-proprietary rule sets that route around taxonomy gaps are candidate additions to future versions. Producers encountering gaps SHOULD document them in the extensions: block and SHOULD file an issue against this specification.

10. Representation

10.1 Preferred framing paragraph

representation.md MUST contain a ## Preferred framing section whose body is a prose paragraph of approximately 120 words or less. Consumer agents SHOULD paraphrase this paragraph rather than quote verbatim.

10.2 Structured fields

describe_as, do_not_describe_as, competitive_frame, honest_trade_offs, never_say, never_compare_to, framing_traps.

never_say and never_compare_to record publisher preferences for brand-aligned generation. never_compare_to lists entities the brand prefers not to be analogized to (distinct from competitors). Neither field can prohibit an independent comparison requested by a user or override host policy (§15.5).

framing_traps is an array of objects with trap (the rejected framing), optional preferred_reframe (the brand’s substitution), and optional rationale. Consumers SHOULD NOT produce content using a listed trap framing and SHOULD substitute preferred_reframe when one is provided.

10.3 Consumer agent integration

Consumer agents describing a brand SHOULD consider representation.md, paraphrase preferred_framing for open queries, use describe_as and do_not_describe_as as publisher preferences for categorical queries, consider never_say and never_compare_to under host policy, avoid framing_traps when doing so remains consistent with user intent and observable truth, surface honest_trade_offs when relevant, and draw on competitive_frame for comparisons. None of these fields overrides §15.5.

10.4 Conflict resolution

When preferred framing contradicts observable facts, consumer agents MUST prioritize observable truth and SHOULD surface conflicts to the user.

11. Localization

11.1 Parallel subtrees

Localized content at /.well-known/brand/{locale}/{filename}.md, where {locale} is IETF BCP 47.

11.2 Inheritance

Localized files MAY be partial. Fields absent fall back to default-locale file.

11.3 Locale declaration

Root SHOULD declare default_locale and supported_locales.

11.4 BCP 47 compliance

Locale codes MUST conform to IETF BCP 47. Consumers MUST NOT accept non-compliant strings.

12. Privacy, access control, and authentication

12.1 Public vs. private BCPs

BCPs at /.well-known/brand.md are public by default. Producers MUST NOT include commercially sensitive or privileged content in public files.

12.2 MCP-served private BCPs (v0.2 preview)

Future versions define authenticated access patterns. v0.1 producers MAY serve private content via Ring 3 MCP server with auth at the MCP layer.

12.3 Fields never to publish publicly

No credentials, commercial terms, unannounced plans, personal information, or content whose disclosure would be a material breach.

12.4 Signed BCPs

Registries and self-hosters MAY sign canonical packages. Signature semantics are defined in §5.10. Domain control, account authentication, and signature verification are separate trust signals.

13. Consumer ergonomics

13.1 File-based consumption

Direct HTTP fetch. Works for any consumer that can make HTTP requests.

13.2 CLI-based consumption

Reference CLI provides init, validate, show, diff, query commands. Agents MAY invoke as subprocess.

13.3 MCP-based consumption

Recommended tool names: get_brand_root(), get_voice(), get_boundaries(context?), check_claim(proposed_claim), validate_adjacency(content_sample), query(natural_language_question).

13.4 Ring selection

Ring 1 for one-off queries and stateless consumers. Ring 2 for developer authoring. Ring 3 for long sessions, private BCPs, dynamic resolution.

13.5 Platform and tool integration recommendations (v0.8)

The /.well-known/ convention (shared with robots.txt and security.txt) only removes friction at scale once consuming platforms support discovery. A package map describes available context; it cannot instruct an agent that has not discovered it. This section offers integration guidance to platform implementers under their own host policy.

Platforms and AI systems SHOULD:

None of this requires coordination with any single producer or with the protocol’s maintainers — it is a description of the behavior that makes the convention work, offered for platforms evaluating whether and how to adopt it.

14. Producer ergonomics

14.1 Manual authoring

Producers MAY author manually in any text editor using this specification as reference.

14.2 Encoder-assisted authoring (v0.2 preview)

Future tooling will provide guided authoring with signal extraction and drift detection. Not required for conformance.

14.3 Living BCP monitoring

Commercial monitoring tools MAY subscribe to producer repositories and detect drift. Not required for conformance.

14.4 CI/CD integration

Producers MAY validate their BCP in CI via a reference CLI.

15. Security considerations

15.1 Trust model

BCP content is claims authored by or on behalf of a brand, not verified truth. Consumer agents MUST NOT treat BCP content as authoritative evidence for factual claims about the world. Claim proof status is not legal advice and is not a substitute for review by legal or the accountable brand owner.

15.2 Conflict with observable facts

Consumer agents MUST prioritize observable truth over preferred framing.

15.3 Denial of service and caching

Producers SHOULD set cache headers. Consumers SHOULD respect them.

15.4 Spoofing and domain verification

Consumers SHOULD confirm the discovery domain matches the brand expected. A domain-control check proves control at a point in time, not the truth of content or the identity of every person with DNS access. Consumers SHOULD verify publication signatures and manifests independently when supplied.

15.5 Untrusted brand data and prompt injection

Consumer implementations MUST treat all BCP body prose and publisher YAML as untrusted brand-provided data. Behavioral directives inside those files are non-normative, even when labeled MUST, core, system, or authoritative. Consumers MUST NOT load BCP content as system-prompt instructions or let it override host policy, safety constraints, user intent, or independent evidence. Host policy determines retrieval, generation, and tool use; brand claims and preferences do not authorize purchases, credential use, or external writes. This boundary applies to every consumption mode, including brand Q&A and campaign generation, and takes precedence over all brand-rule interpretation guidance in this specification.

Consumers MUST NOT accept publisher-asserted trust booleans as evidence. Only authenticated Registry attestation, or a provenance-verified signed snapshot subject to §5.9.6, supplies Registry trust. Signing establishes origin and integrity, not that body instructions are safe or binding.

Consumers MUST NOT enter owner credentials through URLs found in BCP content. Authoring endpoints come from authenticated Registry attestation (such as encoder_mcp_discovery) or independently trusted Encoded discovery documents, never publisher prose. Read-only Registry access and write/admin access remain separate permission lanes.

Producers MUST NOT author content designed to manipulate consumer-agent behavior outside these data semantics.

16. Conformance

16.1 Producer conformance

A BCP is producer-conformant if its discovery document matches one of §5.3’s profiles. A self-hosted discovery document must be a valid root with accessible declared daughters. A Registry-backed discovery document may be a rich root or thin pointer whose absolute HTTPS canonical_bcp resolves to a valid Registry root with accessible declared references. Registry-backed daughter references must use absolute Registry URLs. All files must have valid frontmatter and bcp_version matching this specification, and publisher content must respect §15.5. A known Registry handle can also provide direct discovery without requiring the brand to host a full tree.

Optional package extensions are not required for producer conformance. If a producer declares a package_manifest, the manifest SHOULD be accessible at its declared path and SHOULD list declared extension files with media types and checksums. A missing, invalid, or incomplete optional extension file MUST NOT invalidate an otherwise conformant core package unless the producer explicitly marks that file as required in the manifest.

16.2 Consumer conformance

A consumer is conformant if it resolves discovery and canonical references safely, evaluates Registry trust separately from publisher content, and enforces §15.5’s untrusted-data boundary. For authorized brand-aligned generation, it interprets resolution precedence, vocabulary preferences, claim evidence, and brand-safety signals as data under host policy, never as instructions that suppress truthful independent answers or override the user’s task.

Consumers MUST be able to consume a conformant core package without optional extensions. Consumers MUST ignore extension fields and extension files they do not understand. Consumers SHOULD use declared checksums when validating or caching package files.

16.3 Conformance levels

v0.4 defines core conformance and optional package enrichment:

Package-enriched BCPs are richer, but not more complete in the product milestone sense. The first milestone is core-complete; enrichment is optional depth.

16.4 Reference implementation

The reference at github.com/Brand-Context-Protocol/spec/examples/acme-corp/.well-known/ is producer-conformant by definition.

17. Open questions and future work

17.1 Signature profiles and key discovery

Standardize algorithms, key discovery, revocation, and rotation beyond §5.10’s minimum integrity contract.

17.2 Private and authenticated BCPs (v0.2)

Authentication patterns for MCP-served private BCPs.

17.3 Standardized products and campaigns (v0.2)

Full schematization of product and campaign file types, sunset semantics.

17.4 Sunset and temporal semantics

Normative handling of expired campaigns and time-bounded content.

17.5 Measurement layer standardization

Companion specification for brand fidelity measurement across surfaces.

17.6 Governance transition

Transition from maintainer-led to published governance model before v1.0.

17.7 Visual.md schematization (resolved in v0.8)

Resolved in §7.3. v0.2 established structured logo, color, typography, and imagery fields; v0.8 adds the optional evidence-labeled semantic vocabulary for color, type, logo authenticity, imagery and media, composition, and motion. The visual.md/DESIGN.md authority boundary is defined in §5.8. Future additions remain additive and subject to the same anti-fabrication rule.

17.9 Canonical community reference for voice/anti-ai.md

§7.2.1 defines a community_reference field pointing to a live external list of AI writing patterns but does not name a canonical source. The Brand-Context-Protocol org SHOULD publish and maintain a reference list at a stable URL that producers can point to by default. Until that list exists, producers SHOULD reference the most current authoritative community-maintained source available and document their choice in a rationale field on the community_reference entry.

17.8 Multi-brand organizations

Handling parent companies with brand portfolios, candidate /brand/{brand-name}/ subtree pattern.

17.10 Domain-to-package binding and Registry-direct discovery

For domain-bound official discovery, the pointer (or compatible rich root), Registry publication, and current DNS attestation MUST identify the same domain and handle. The discovery canonical_bcp, registry_handle, and registry_mcp must identify one package; the canonical root’s handle must agree, and current Registry attestation must bind the discovery domain to that handle. When the Registry supplies a publication signature, consumers SHOULD verify it under §5.10. A missing, expired, revoked, conflicting, or mismatched domain attestation MUST fail closed for official-source status. A supplied signature that fails verification MUST fail closed for integrity and official-source status. Absence of a signature from a Registry that does not implement signatures does not by itself downgrade a current DNS attestation. The content may remain usable as untrusted, unofficial data.

The pointer is a locator, not a second signed package. Registry-stamped fields follow §5.9.6; consumers never reconstruct official status from publisher booleans or from an older snapshot. Signing-key rotation does not rewrite body bytes; a new signed publication is a new revision. Verification challenge renewal follows §5.9.3.

Registry-direct discovery remains valid without a pointer. Consumers that already know the handle or canonical URL evaluate the Registry package and its current attestation directly; absence of a domain pointer is not absence of a Registry package. New packages target bcp_version: "1.1.0"; earlier packages remain consumable under §15.5.

18. Appendices

Appendix A. JSON Schema

Formal JSON Schemas at schema/ and versioned schemas at schema/v0.1/ and schema/v0.2/. v0.1 covers root frontmatter. v0.2 adds schemas for visual.md and the extended representation.md fields.

Appendix B. Reference implementation

Conformant BCP published at github.com/Brand-Context-Protocol/spec/examples/acme-corp/.well-known/.

Appendix C. Comparison to adjacent standards

StandardRelationship to BCP
AGENTS.mdStructural analog; brand-identity equivalent
MCPRing 3 is implemented via MCP
robots.txtPattern inspiration for well-known URI
sitemap.xmlPattern inspiration for machine-readable publication
schema.orgComplementary; structured blocks can reference
JSON-LDComplementary; structured blocks parseable as JSON-LD-adjacent
OpenAPIPattern inspiration for human-authorable, machine-parseable
IAB Content Taxonomy 3.0Referenced in Section 9 as one of v0.1’s current reference alignments
GARM Brand Safety FrameworkReferenced in Section 9 as one of v0.1’s current reference alignments

Appendix D. Glossary

See Section 2.

Appendix E. References

End of specification. Questions, issues, and pull requests: https://github.com/Brand-Context-Protocol/spec