Open Brand Definition
OBDS / 4.0.3 stable
English only
← Back
Brand governance for AI Companion to OBDS 4.0.3

The right
source, the
wrong truth

Retrieval scores relevance. It does not decide whether a declaration is authoritative, whether it applies to this market today, or whether something required is simply missing.

DecidesScope, validity, conflicts, required truth, permission.
StopsMissing required truth ends the task. Zero model calls.
RecordsAn append-only Runtime Decision Record per attempt.
01 / The gap
In one sentence

Brand governance for AI is the decision layer between retrieval and generation: it determines which governed brand truth is authoritative and applicable to the task, compiles exactly that truth into an immutable context, and stops execution when required truth is missing.

Retrieval can find the right source and still use the wrong truth.

The failure is not that the system found nothing. It is that it found something relevant, and relevance was the only test it applied.

Where the decision belongs

01SourcesApproved brand material, with provenance and a named approver.
02RetrievalFinds what looks relevant. Scores similarity, not authority.
03DecisionAuthority and applicability. Scope, validity, conflicts, required truth. This is the missing layer.
04Compiled contextOne immutable artefact for one task, hashed and reproducible.
05ModelReceives only the compiled context. Nothing it was not given.
06ValidationChecks run before and after the call. Output can be withheld.
07EvidenceA Runtime Decision Record: what was decided, on which artefact, with which outcome.
08Or nothingIf required truth is missing, steps 04 to 06 never happen. Model calls: 0.

The five questions a governance layer has to answer

  • Scope. Does this declaration apply to this market, locale, channel and output type? OBDS uses a closed nine-dimension scope vocabulary, so applicability is decided, not inferred from wording.
  • Validity. Does it apply at this moment? Every element may carry validity.from and validity.to, resolved against the build's declared asOf.
  • Conflicts. Two approved declarations can both plausibly apply. Precedence decides which wins, and conflict relevance decides whether the clash matters for this target at all.
  • Required truth. A target declares what it cannot proceed without. Brand truth that is unknown or not_defined is a first-class state, not an empty string.
  • Permission. Given all of the above, may this task run? If required truth is missing, the answer is no, and nothing is generated.

Fail closed, concretely

A target requires an efficacy claim. The brand has not approved one; the element is in state unknown.

status             failed
error              OBDS-BUILD-REQUIRED-NOT-DEFINED
context files      none written
model calls        0
decision           build_failed

Real output of the published fail-closed example, exit code 2.

The unknown value is not guessed, not widened to a neighbouring scope, and not quietly dropped so the build can pass. There is no Compiled Brand Context, so there is nothing to assemble a model input from, so the model is never called. The absence of required truth stops the process before generation, rather than producing fluent output from an assumption nobody approved.

Evidence, not logs

Every attempt produces a Runtime Decision Record against a published schema: which target, which artefact hash, which checks ran, whether the model adapter was called, and the outcome. Provider failure is its own outcome, model_failed, distinct from a rule violation, and it withholds output rather than releasing it. Records are append-only and exportable in order.

What that gives you is narrow and useful: the same manifest and build plan reproduce the same compiled artefact hash, so a decision can be re-derived rather than remembered.

Limits

This is brand governance, not general AI governance. OBDS is not an enterprise policy engine, a safety classifier, a content moderation system or a compliance product. It does not evaluate whether a claim is legally sound; it carries the approval a named human role gave and decides where that approval applies. It cannot detect an approved value that is false, and it cannot detect a target that under-declares what it should have required. Both build successfully with valid hashes. The limits document is published for exactly this reason.