Brand odrl

PHASE 0 – Foundations

0.1 Define your core data models

Before you touch Disney/Target PDFs, lock in:

Token schema (Brand OS / Brando):
toneToken
visualToken
audioToken
cultureToken
seasonToken
channelToken
audienceToken
policyToken (safety / legal / integrity / brand rules)
Common fields:
- id, label, description
- mustDo[], mustNotDo[]
- version, status
- tags[]
- source (docId, section, pageRange)
Brand ODRL Profile (your subset of ODRL):
Use odrl:Policy, odrl:Permission, odrl:Duty, odrl:Constraint
Define profile URI, e.g. https://brandoschema.com/odrl/brand-profile/v1
Extend with your own:
- Actions: brand:applyTokens
- Left operands: brand:brand, brand:region, brand:channelToken, brand:audienceToken, brand:seasonToken, brand:productCategory, brand:riskProfile, brand:overrideMode
- Duty props: brand:appliesToneTokens, brand:appliesVisualTokens, brand:appliesPolicyTokens, etc.
Storage & IDs
Decide where tokens + policies live (DB/Git).
Define ID patterns, e.g.:
- policy.brand.disney_travel.characters_usage_uk_ie
- tone.brand.cat_jack.kids_playful_imaginative

PHASE 1 – Ingest brand guidelines

1.1 Collect documents

Brand books (PDF), tone of voice docs, safety decks, legal guidelines, channel playbooks.
Track:
docId, version, date, brand, region.

1.2 Extract structured text

Use a PDF extractor that preserves:
headings
section titles
bullet points
page numbers
Store as something like:

{
  "docId": "disney_travel_brandbook_2025",
  "sections": [
    {
      "id": "sec.characters.cannot_be_sales_people",
      "title": "CHARACTERS CANNOT BE SALES PEOPLE",
      "page": 6,
      "rawText": "Characters are our most valuable asset..."
    },
    ...
  ]
}

PHASE 2 – Orchestrator: classify and normalise text

This is your AgentODRL-style brain.

2.1 Orchestrator classifies each section

For every section / chunk, ask:

Is it a simple rule?
Does it contain multiple parallel rules?
E.g. logo, characters, photography all in one page.
Does it reference other clauses (recursive):
“See section 4.1”
“Except as stated above…”

This is what AgentODRL calls simple / parallel / recursive.

2.2 Rewriter agent (for recursive / cross refs)

For complex references:

Inline cross-references so each unit is self-contained.

Example:

“As outlined in the General Character Guidelines (see section 3.1), characters must not be used as salespeople in partner marketing.”

Rewriter turns that into:

“Characters must not be used as salespeople in partner marketing. This includes all Disney, Pixar, MARVEL and Star Wars characters…”

Now you can process it independently.

2.3 Splitter agent (for parallel structures)

Where a block covers multiple topics or scopes, Splitter:

Splits into atomic policy units, each with:
exactly one topic (logo, characters, tone, claims, kids, etc.)
clear scope (global vs UK, partner vs owned, web vs OOH)
one coherent rule set

Output looks like:

{
  "unitId": "disney.characters_usage.uk_ie",
  "brand": "disney_travel",
  "region": "uk_ie",
  "topic": "characters_usage",
  "channelHints": ["partners", "all_marketing"],
  "text": "Disney, Pixar, MARVEL and Star Wars characters must only be shown as entertainers..."
}

PHASE 3 – Turn units into Brand OS tokens

Now each policy unit becomes one structured policyToken (or a set of tokens if you split by topic).

3.1 Token type classification

Use an LLM (or rules) to classify:

Is this:
policyToken (behavioural/safety/usage rules)?
toneToken (voice/wording)?
visualToken (layout, colours, logo, imagery)?
wordingToken (specific phrases required/prohibited)?
or something else?

For our Disney example: policyToken (imagery/characters).

3.2 Extract MustDo / MustNotDo

From the unit’s text:

Extract explicit must / should / “always” → mustDo[].
Extract never / “must not” / “do not” → mustNotDo[].
De-duplicate and normalise into short, imperative statements.

You end up with:

{
  "mustDo": [
    "Present characters only as entertainers, not as sales people.",
    "Show characters in environments relevant to them, such as parks or ships."
  ],
  "mustNotDo": [
    "Do not use characters as sales people.",
    "Do not use characters to endorse offers, prices, products or services."
  ]
}

3.3 Build the token

Use the extracted info + metadata to generate the policyToken:

{
  "id": "policy.brand.disney_travel.characters_usage_uk_ie",
  "type": "policyToken",
  "brand": "disney_travel",
  "region": "uk_ie",
  "category": "safety",
  "severity": "hard",
  "label": "Disney Travel – Character Usage (UK & Ireland)",
  "description": "...",
  "mustDo": [...],
  "mustNotDo": [...],
  "source": {
    "docId": "disney_travel_brandbook_2025",
    "section": "CHARACTERS CANNOT BE SALES PEOPLE",
    "pageRange": "6"
  }
}

These tokens live in your DB / registry, not in ODRL yet.

PHASE 4 – Generate Brand ODRL binding policies

Now we say where and when each token applies.

4.1 Decide the binding pattern

For each token, define:

Scope:
brand(s)
region(s)
channel(s)
audience(s)
season/campaign if relevant
Override mode:
inherit | add | replace

E.g. for characters:

Applies to:
brand = disney_travel
region in [uk, ie]
assetCategory = characters_imagery
channels = all partner marketing

4.2 Use a Generator agent to write the ODRL

Using your Brand ODRL Profile, Generator takes:

The unit metadata (brand, region, topic, etc.)
The token ID
The binding pattern

…and writes an ODRL Policy with:

Policy (type Set)
Permission with:
target = the brand/channel asset node
action = brand:applyTokens
constraints = brand, region, channel, assetCategory
duty:
- action: brand:applyTokens
- appliesPolicyTokens: [ "policy.brand.disney_travel.characters_usage_uk_ie" ]
- overrideMode: "add"

You get the binding we sketched earlier.

PHASE 5 – Validation & QA

5.1 Syntax validation

Two layers:

Token validation (Brand OS)
JSON Schema for tokens:
- required fields
- mustDo / mustNotDo arrays non-empty
- brand/region values valid.
ODRL validation (Brand profile)
SHACL or JSON Schema that checks:
- valid ODRL classes/props
- your profile-specific fields exist
- applies*Tokens arrays contain valid IDs.

If a doc fails, feed the error back to the Generator and regenerate (AgentODRL’s generate–validate–correct loop).

5.2 Semantic validation

LLM-based:

For each original unit:
Extract a semantic checkpoint list (parties, scope, must/must-not points).
Check that each semantic point:
appears in the policyToken.mustDo/mustNotDo, or
is encoded in constraints (e.g. region = UK & IE).
If something’s missing:
mark as “needs review” OR send a correction prompt to the Generator.

5.3 Human review

For high-risk stuff (kids, safety, legal):

UI shows side-by-side:
Original text (from PDF)
Generated policyToken
Generated ODRL binding
Brand/legal can:
edit mustDo/mustNotDo
tweak scopes
approve or reject

Once approved, tokens/policies are marked status: "active".

PHASE 6 – Deploy into the Brand OS

6.1 Index & store

Store all tokens + policies in:
a primary store (DB)
a search/vector index if you want semantic lookup for tools / UI
Maintain:
version history
status (draft, active, deprecated)

6.2 Build a `resolve_constraints` service

You expose a service like:

resolve_constraints(brand, region, channel, productId, audience, season, campaignId) → returns the merged constraints object for the LLM.

Internally it:

Figures out the relevant brand/entity node in your taxonomy.
Finds all applicable ODRL policies (global → region → brand → channel → campaign).
Applies override rules (inherit/add/replace).
Collects all active tokens.
Merges their mustDo / mustNotDo into one flattened object.

Output shape:

{
  "constraints": {
    "toneTokens": [...],
    "visualTokens": [...],
    "policyTokens": [...],
    "seasonTokens": [...],
    "channelTokens": [...],
    "audienceTokens": [...],
    "mustDo": [...],
    "mustNotDo": [...]
  }
}

PHASE 7 – Runtime: connecting to the LLM

7.1 System prompt

You use the pattern we already drafted:

Explain:
what constraints is,
that mustDo are obligations,
mustNotDo are hard fences,
token IDs are labels, not instructions.

7.2 Per-request flow

When a creative user types:

“Write a playful Cat & Jack PDP description for this kids’ snack in the UK, back-to-school.”

Your system:

Parses that → context:
brand = cat_jack
region = uk
channel = web_pdp
season = back_to_school
audience = parents_kids_6_10
Calls resolve_constraints(...).
Sends the LLM:
context object
constraints object
task (“write PDP copy…”)
LLM generates content inside those rules.

PHASE 8 – Feedback & evolution

8.1 Monitoring

Log:
which tokens & policies were active per generation,
what the model produced,
any human edits / overrides.

8.2 Learning loop

If brand/legal changes guidelines:
update tokens / ODRL policies (v2),
mark old ones deprecated.
Optionally:
use the logs to improve:
- Splitter / Rewriter prompts,
- Generator prompts (or fine-tuning),
- your Brand ODRL Profile.

TL;DR – End-to-end in one line

Beginning → end:

Ingest PDFs → structured sections
Orchestrator: classify → Rewriter → Splitter
Turn each unit into clean policyToken (mustDo/mustNotDo + metadata)
Generate Brand ODRL policies that bind tokens to brand/region/channel/etc.
Validate syntax (SHACL/JSON) + semantics (LLM checkpoints) + human review
Store tokens/policies, expose resolve_constraints(...)
At runtime, build a constraints object per request and feed it to the LLM

…so brand PDFs become live, executable guardrails that every model has to obey.