EcosystemOBDS / 4.1.3

Where OBDS fits.

A brand system needs structure, access, governance and execution. OBDS sits primarily at Resolve / Govern; the surrounding tools have their own jobs.

Informative guide · OBDS 4.1.3

01 / Four jobs

A map of responsibilities.

01Define /
StructureRepresent brand information.
02Publish /
DiscoverMake it available to consumers.
03Resolve /
GovernDetermine which truth applies.
04Execute /
ValidateApplications act and check.

This is an explanatory map, not a maturity ladder or four new normative OBDS layers. Integrations may revisit these jobs.

Define / Structure

Represent brand information and prepare it for review. Authoring turns sources into evidence-backed candidates; authorised people approve the resulting truth.

Publish / Discover

Make information available and discoverable through files, registries, APIs and access infrastructure. OBDS itself is not the discovery service or registry.

Resolve / Govern

Determine authority, scope, validity, conflicts and required truth. OBDS specifies governed applicability, fail-closed decisions and execution evidence contracts.

Execute / Validate

Consuming hosts and renderers act, check results and retain evidence under the relevant contracts. A specification alone is not an execution system.

02 / Derived views

One governed source. Several useful views.

ONE GOVERNED SOURCECanonical
OBDS truth

Task-specific contextHuman-readable viewsAPI / MCPMarkdown projections

Derived projections remain views of the canonical truth. They are not parallel sources of approval. This diagram explains an integration pattern; it does not claim a released adapter for every format.

Delivery integrity is an integration problem. Semantic visual context remains a research question, not a newly adopted OBDS feature.

03 / Adjacent systems

Different systems standardise different parts.

Open specifications / protocols

OBDS, BRAND.md, Brand Context Protocol, MRBS and Brando describe different contracts, formats and responsibilities. The detailed comparison uses source-backed coverage blocks.

Products / infrastructure

Sameness is considered separately as an adjacent product and infrastructure approach. Product descriptions are not specification conformance or independently demonstrated enforcement.

Access infrastructure

MCP connects hosts with resources and tools. It does not supply brand-specific authority or applicability semantics. OBDS is not an MCP replacement.

DAM, PIM and design systems remain useful category boundaries: asset management, product information and interface systems can provide inputs or consume outputs. Actual coverage depends on the implementation.

Not a ranking. Different systems standardise different parts of the machine-readable brand stack.

Compare documented responsibilities ↗

04 / Around the system

Research tests the boundaries.

SUPABRAND is a synthetic evaluation asset alongside the system, not a production layer. Round 4 found bounded semantic agreement but no complete end-to-end governed execution: 0/20 completed pipelines, not 20 wrong decisions.

AuthoringReview before approved truth enters OBDS.ResearchEvidence, negative findings and open questions.InsightsExplanations of the underlying problems.Try an exampleA successful build and a fail-closed build.