Machine-readable brand guidelines make brand information accessible to software. OBDS additionally governs which declared truth is applicable to a specific task.
One name, three different problems.
"Machine-readable brand guidelines" is a category, not a single problem. Projects in it solve genuinely different things, and picking the wrong one is a real cost.
The three problems
- 1. Make brand information readable by software. Replace the PDF with a file an agent or a build step can parse: names, colours, typography, tone, do and do not.
- 2. Publish and discover brand context. Give the brand a well-known address so any tool can fetch the current version, with versioning, packaging and integrity.
- 3. Decide which governed truth applies to a concrete task, and whether it may run. Resolve scope and time validity, resolve conflicts between competing approved rules, detect that required truth is missing, and stop rather than guess.
The first two are about access. The third is about permission. A brand can have all of its guidelines perfectly machine-readable and perfectly discoverable and still have an agent publish a claim that was approved for another market, or that expired last quarter, or that rests on a fact nobody ever signed off.
Where OBDS sits
OBDS focuses specifically on the third problem: governed applicability and execution decisions. It assumes the brand truth already exists and has been approved by a named human role, and it decides what that truth means for one concrete task at one moment in one scope.
Machine-readable brand guidelines solve more than one problem. OBDS focuses specifically on governed applicability and execution decisions.
That focus is a limitation as much as a position. If your problem is the first one, OBDS is more machinery than you need, and a simpler format will serve you better and sooner.
What that looks like concretely
Four things OBDS decides that a readable brand file, on its own, does not:
| Question | OBDS mechanism |
|---|---|
| Does this truth apply here? | Scope, a closed nine-dimension vocabulary: locale, market, channel, output type and others. Declarations that do not match the target's scope do not enter its context. |
| Does it apply now? | validity.from / validity.to resolved against the build's asOf. |
| Which one wins? | Declared precedence over competing approved declarations, plus explicit conflict relevance for the target. |
| Is something required missing? | Brand States. A required element in state unknown or not_defined fails the build; nothing is generated and no model is called. |
The result is an immutable Compiled Brand Context for that one task, with a reproducible hash, and a Runtime Decision Record that says what was decided and why. See the worked examples.
Limits
OBDS is brand-specific. It is not a general enterprise policy engine, not a prompt format, not a retrieval system and not a renderer. It cannot tell whether an approved statement is true in the world; it can only carry it faithfully and decide where it applies. It begins at an approved manifest and ends at a decision record.