Open Brand Definition
OBDS / 3.0.4 stable
English only
← Back
Authoring and Curation Companion to OBDS 3.0.4

Brand truth
has an
author

If a curator approves a wrong value, OBDS ships it faithfully and every hash stays valid. OBDS governs whether a value applies — not whether it is true.

CuratesA named human role. Never a tool, never a model.
BoundaryStarts at an approved manifest. Ends at a decision record.
GuaranteeOBDS cannot detect a wrong approval or an under-declared target.
01 / Curator

A person is accountable. Not a tool.

OBDS does not mandate a job title. It mandates that one person is named, and that the name is recorded on the manifest they approved.

approvedBy: person-or-role-id

Every approved manifest carries who approved it. Section 7.2 draws the line precisely: an approved or official source does not automatically approve its OBDS mapping; an importer or test team may verify technical validity and coverage; only an authorised brand role may approve the resulting Brand Manifest as brand truth. In practice that is a brand lead, a brand governance function, or — for claims that carry legal exposure — legal counsel. Whichever role an organisation designates, OBDS records who it was, not what it was called.

02 / Evidence

One path, from a source to a Brand Element.

Brandbooks, PIM, DAM, legal opinions, approved decisions, test reports, certifications. Section 7.2 defines a source coverage declaration so a manifest can say, honestly, how much of that material has actually been reconciled.

01Sourcebrand-guidelines-v3.pdf, page 22, “Primary Palette”.
02ExtractA candidate is drafted. Nothing here is brand truth yet.
03ApproveA named curator signs the element, not the source.
04Truthdesign.primary-colour, state: defined, with its sourceRefs.
id: design.primary-colour
subject: design.primary-colour
family: design
kind: colour
nature: fact
state: defined
scope: {}
validity:
  from: null
  to: null
annotations: []
valueContractRef: urn:obds:brand:example#value-contract:design:colour:v1
value:
  name: Primary
  hex: "#0F1E3D"
  pantone: "289 C"
sourceRefs:
  - "brand-guidelines-v3 p.22 Primary Palette sha256:9f2c..."

sourceRefs[] records where the value came from (section 8.5). Each entry is a single string: the manifest contract carries provenance as free text, and the structured source unit, its locator and its snapshot hash live in the curation report that reportRef points at. It is provenance, not payload — it does not itself make the value true, and it is not an internal element reference. value.name is required by the published colour value schema; a colour without a name is not a governed colour.

complete
Claimable only once the curation report reconciles every declared source unit and every relevant modality.
partial
Known material remains unresolved, excluded or outside the manifest — the honest default for most real manifests.
unknown
Coverage has not been assessed. Absence of the declaration makes no completeness claim at all.

A multi-modal source must not claim complete while one relevant modality — text, figures, tables, metadata — sits at partial or not_assessed. The report does not force all source content into OBDS. It makes every disposition visible.

03 / Approval

Approval is the default. Not the exception.

Section 7.1: teams usually approve a guideline or brand release, not hundreds of tiny values separately. So OBDS Foundation assumes one responsible person approves a complete Brand Manifest release.

approvedBythe named person or role
approvedAtwhen the approval was made
contentHashcanonical hash of the exact approved manifest

A manifest with status: draft can be validated, reviewed, argued over. It cannot be built from.

Section 22.3 is one of the five things validation checks: manifest approval, and any activated record-level profile. Approval confirms a pre-existing snapshot; it must not rewrite any element.

04 / Extraction

Extraction may locate evidence. It may not manufacture brand truth.

Section 24, verbatim. An AI system may draft a candidate Brand Element from a source document. A human approves it. The approval — not the draft — is what makes it truth.

subjectextraction
actorAI or importer
may
  • propose a candidate element
  • locate and cite evidence
  • report an unknown mapping
  • flag image-only meaning for review
may not
  • approve a candidate as truth
  • invent an unknown mapping
  • turn an observed pattern into a binding rule
  • let technical portal metadata pass as brand truth
Section 26.1: semantic curation judgement is not represented as fully parser-proven. A conformance suite can prove the mechanism was exercised. It cannot prove the judgement inside it was right.
05 / Edges

Where OBDS starts. Where it ends.

Everything upstream of an approved manifest — finding source material, drafting candidates, reconciling coverage, deciding what a statement should say — is curation. OBDS records it. It does not perform it.

Does not source

It does not go looking in a brandbook, a PIM or a DAM on its own behalf.

Does not extract

It does not read meaning out of a page. A curator or an importer tool does.

Does not verify against the world

Pantone 289 C is trusted because a named person approved it, not because OBDS checked a swatch library.

Does not judge correctness

Whether an approved statement is factually right was already decided, upstream, by the curator.

The README says the same thing from the other direction: not a vector database, not a RAG framework, not an agent framework, not a prompt library, not a DAM, PIM or CMS, not a renderer. OBDS is specifically about brand truth once someone has already stood behind it.

06 / Limits

What OBDS cannot guarantee.

Two limits, stated without softening, because they are the honest edge of everything above.

A wrong approval ships faithfully

If a curator approves a wrong value, OBDS ships it faithfully, and every hash will be valid. Canonical hashing, shape hashing, schema validation, manifest approval — none of that checks whether a value is actually correct. It checks that the value a named person approved is the value that reaches the build, byte for byte, unaltered and attributable. OBDS governs whether a value applies. It does not, and cannot, govern whether it is true. A wrong approval is a governance failure, not a technical one.

An under-declared target builds anyway

If a build target under-declares what it requires, the build succeeds, and nothing blocks the claim. Section 13.1: a target name or description must not imply a capability that its declared requirements and selected context cannot support — but this is a rule about how a target is written, enforced by whoever writes and reviews the Build Plan. It is not something the compiler can check by itself, because the compiler has no independent way to know what a name or description implies. Section 13.1 forbids that target. It provides no mechanism to detect one.

OBDS proves that approved truth reached the build unaltered. It cannot prove the truth was right, or that a target asked for everything it should have.

Review, test, challenge
lets@killthedragon.com

This page is published in English only. The rest of openbranddefinition.org carries parallel English and German copy; this companion page does not yet. That is a deliberate choice for OBDS 1.1.3 rather than an oversight, and German copy is planned.