Klassische Brand Guidelines erklären Menschen, wie eine Marke auftritt. Für automatisierte Content-Prozesse reicht das häufig nicht aus. Statische PDF-Dateien, Präsentationen und verstreute Vorlagen enthalten zwar relevantes Wissen, ihre Regeln sind jedoch selten eindeutig strukturiert, validierbar oder direkt durch KI-Systeme abrufbar.
Maschinenlesbare Markensysteme übersetzen dieses Wissen in Dateien, Schemata oder Datenmodelle. Dadurch können Content-Generatoren, Design-Agenten, Prüfmechanismen und externe Tools dieselbe Markendefinition verwenden. Brand Context Protocol, design.md, brand.md, Brando Schema und das Markensystem von nxttool verfolgen dieses Ziel mit unterschiedlichen Schwerpunkten.
Markenwissen als Grundlage
Eine maschinenlesbare Markendefinition beschreibt Markenidentität in einer Form, die digitale Systeme direkt lesen und anwenden können. Dazu gehören strukturierte Felder, definierte Beziehungen, verbindliche Regeln und bei Bedarf referenzierte Assets.
Der Unterschied zu einem klassischen Markenhandbuch liegt nicht nur im Dateiformat. Entscheidend ist die operative Nutzbarkeit. Ein Content-System muss beispielsweise erkennen können, welche Tonalität für eine Zielgruppe gilt, welche Aussagen belegt sind, welche Farben eingesetzt werden dürfen und welche Bildwelt zu einem bestimmten Format passt.
Damit wird Markenwissen von einer Dokumentation zur Steuerungsgrundlage. Es kann für Generierung und Prüfung, für Designsysteme, Automatisierungen, Schnittstellen und Freigabeprozesse eingesetzt werden.
Generierung und Prüfung
Bei der KI-gestützten Content-Erstellung entstehen Inkonsistenzen häufig nicht durch ungeeignete Modelle, sondern durch unvollständigen Kontext. Ein allgemeiner Hinweis wie „Schreibe in unserer Markensprache“ ist nicht ausführbar, wenn Tonregeln, bevorzugte Begriffe, Zielgruppenwissen und freigegebene Botschaften fehlen.
Für eine belastbare On-Brand-Prüfung müssen Regeln außerdem prüfbar formuliert sein. Ein System kann einen verbotenen Begriff zuverlässig erkennen. Eine Aussage wie „Texte sollen modern wirken“ bleibt dagegen interpretationsabhängig. Gute maschinenlesbare Systeme verbinden deshalb exakte Werte und Regeln mit erklärendem Kontext.
Folgende Aspekte sollte ein maschinenlesbares Markensystem aus unserer Sicht abdecken:
- Inhaltliche Breite: Das Modell sollte die für den Anwendungsfall relevanten strategischen, sprachlichen und visuellen Markendimensionen erfassen.
- Klare Struktur: Felder, Beziehungen und Geltungsbereiche müssen für Maschinen eindeutig interpretierbar sein.
- Pflegbarkeit: Änderungen sollten versionierbar sein, ohne das gesamte System neu aufzubauen.
- Selektiver Kontext: Anwendungen sollten nur die Markendaten erhalten, die sie für ihre Aufgabe benötigen.
- Prüfbarkeit: Regeln benötigen eine Form, die automatische Validierung oder Bewertung ermöglicht.
- Portabilität: Daten sollten sich exportieren und unabhängig von einem einzelnen Tool weiterverwenden lassen.
- Integration: API, MCP, Dateien oder standardisierte Token-Formate erleichtern die Einbindung in bestehende Prozesse.
Die Kandidaten im Überblick
Brand Context Protocol
Das Brand Context Protocol, kurz BCP, ist ein offener, versionierter JSON-Standard für Markenidentität und automatisierte Markenkonformität. Sein Schwerpunkt liegt nicht allein auf der Beschreibung einer Marke. BCP soll Regeln auch durchsetzen, Inhalte bewerten und abhängig von der Risikokonfiguration markieren, überarbeiten oder blockieren.
Das Kernschema basiert auf JSON Schema Draft-07. Es strukturiert Identität, visuelle Vorgaben, verbale Regeln, Positionierung, Markeneinschränkungen und Governance. Ergänzende Kontexte können beispielsweise freigegebene Aussagen mit Nachweisen und Ablaufdaten erfassen. Kanalabhängige Regeln, Freigabestufen und temporäre Ausnahmen unterstützen operative Governance.
Besonders stark ist BCP bei kontrollierten Marketingprozessen. Tonalität, Wortschatz, Aussagen, Preisregeln und Marketingtaktiken lassen sich systematisch prüfen. Auch visuelle Kontrollen für Farben, Typografie und Logoverwendung sind vorgesehen. API und MCP ermöglichen die Einbindung in weitere Tools.
Die Stärke ist zugleich eine Abgrenzung: BCP ist stark auf Konformität, Risiken und Richtliniendurchsetzung ausgerichtet. Detaillierte Textformate, frei kombinierbare Zielgruppenprofile, visuelle Referenzen oder eine umfassende Generierungslogik stehen weniger im Zentrum als bei einem modularen Markenmodell.
design.md
design.md beschreibt die visuelle Identität und das Designsystem eines Projekts für Coding- und Design-Agenten. Eine Datei kombiniert maschinenlesbare Tokens im YAML-Frontmatter mit erklärenden Regeln im Markdown-Teil. Farben, Typografie, Abstände, Rundungen und Komponenten erhalten dadurch sowohl konkrete Werte als auch Anwendungskontext.
Der Ansatz eignet sich besonders für digitale Produkte und Benutzeroberflächen. Ein Linter prüft unter anderem Token-Referenzen, Struktur und WCAG-Kontraste. Änderungen zwischen zwei Versionen lassen sich vergleichen. Exporte für Tailwind CSS und das DTCG-Format erleichtern die Weiterverarbeitung in Entwicklungsprozessen.
design.md löst seinen abgegrenzten Anwendungsfall präzise. Die Datei kann in Git gepflegt, über Pull Requests geprüft und von Projektagenten gelesen werden. Sie ersetzt jedoch kein vollständiges Markenmodell. Positionierung, Zielgruppen, Markenversprechen, Botschaften, redaktionelle Formate und umfassende Governance gehören nicht zu ihrem Kern. Auch das Verhalten komplexer Anwendungen lässt sich aus visuellen Tokens allein nicht ableiten.
brand.md
brand.md ist ein standardisiertes Markdown-Format mit YAML-Frontmatter für langlebige Markenidentität. Die Spezifikation gliedert das Wissen in Strategie, Sprache, visuelle Grundelemente und optionale Governance. Sie umfasst unter anderem Zielgruppen, Positionierung, Persönlichkeit, Markenversprechen, Tonregeln, Botschaftssäulen, Farben, Schriftfamilien und Art Direction.
Die bewusste Trennung von brand.md und design.md ist konzeptionell wichtig. brand.md beschreibt Bedeutung, Identität und redesignbeständige Grundlagen. Konkrete Farbrampen, Zustände, Komponenten, Layoutregeln und Interaktionsdetails werden in design.md geführt. Bei Konflikten sollen Tools nicht stillschweigend entscheiden, sondern eine menschliche Prüfung anfordern.
Ein weiterer Vorteil liegt in der Markenarchitektur. Dateien für Produktmarken und Untermarken können Vorgaben der Hauptmarke erben oder gezielt überschreiben. Leitplanken werden additiv zusammengeführt, Barrierefreiheitsverpflichtungen dürfen nicht abgesenkt werden.
Als einzelne, portable Datei eignet sich brand.md gut für Projektkontexte, Copywriting und die Übergabe einer Markenidentität an KI-Tools. Grenzen entstehen dort, wo zahlreiche Zielgruppen, laufend aktualisierte Sachkontexte, Assets, Bildreferenzen oder wiederverwendbare Textformate separat gepflegt und pro Aufgabe kombiniert werden sollen.
Brando Schema
Brando Schema ist ein offenes Vokabular für Markenidentität, Governance, Inhaltsvorgaben und Assets. Es erweitert den Schema.org-Typ Brand und modelliert nicht nur Eigenschaften, sondern auch Beziehungen, Kontrollen und Referenzen. Markenwissen kann als portables BGML-Wissenspaket bereitgestellt werden.
Charakteristisch ist das Dokumenten-Tripel: Ein Markdown-Body enthält redaktionellen Inhalt, YAML-Frontmatter strukturiert Metadaten und ein JSON-Sidecar stellt die maschinenlesbare Repräsentation bereit. Diese drei Formen beschreiben dieselbe Entität. Das Modell deckt Strategie, Persona-Karten, Kampagnen, Aussagen, Offenlegungen, Evidenz, Auditaufzeichnungen und Assets ab.
Brando bietet eine breite semantische Grundlage und ist unabhängig von einer bestimmten Infrastruktur. Dateien lassen sich in Git versionieren und über RAG, MCP, APIs oder CMS bereitstellen. Die Offenheit erleichtert den systemübergreifenden Austausch.
Im Gegenzug erfordert die Einführung eigene Architekturentscheidungen. Brando ist ein Schema, keine betriebsfertige Anwendung. Erfassung, Oberfläche, Validierung, Bereitstellung und operative Nutzung müssen implementiert oder durch ergänzende Systeme abgedeckt werden. Für kleinere Anwendungsfälle kann diese Flexibilität mehr Aufwand erzeugen als eine einzelne Definitionsdatei.
nxttool
Unser Ansatz basiert auf einem modularen Datenmodell für Markenführung sowie Text- und Bildgenerierung. Die Marke wird nicht in einem einzelnen Dokument abgebildet. Sieben eigenständige Bausteine trennen Wissen nach Aufgabe und Verwendung:
- Marke und Markensprache: Markenbasis, Wettbewerb, Positionierung, USPs, Proofpoints, Werte, Versprechen, Kernbotschaften, Storylines, Tonalität und Wortwahlregeln.
- Zielgruppen: mehrere auswählbare Zielgruppen mit Persona, Kommunikationslogik und verdichteten Anweisungen.
- Visuelle Stile: Bildwelt, Stimmung, Fotografie, Grafikcharakter, Farben, Ausschlüsse und Referenzanmutung.
- Designsystem: Designhaltung, Logos, Assets, Farben, Typografie, Token-Skalen, Zustände, Schatten und Komponenten.
- Visuelle Referenzen: konkrete Personen, Produkte, Orte oder Objekte, die in generierten Bildern erkennbar sein sollen.
- Textformate: wiederverwendbare Vorgaben für Aufbau, Stil und Länge eines Texttyps.
- Kontexte: Produktwissen, Unternehmensfakten und Hintergrundmaterial, optional mit Synchronisierung aus Webquellen.
Diese Trennung prägt die Generierungslogik. Für einen Text kombiniert das System Markensprache, Zielgruppe, Textformat und ausgewählte Sachkontexte. Für ein Bild wirken visueller Stil, visuelle Referenzen und Designsystem zusammen. Ein Generator erhält damit nur jene Bausteine, die für seine Aufgabe erforderlich sind.
Der Ansatz ist umfassender als eine einzelne Marken- oder Designdatei, weil strategische, sprachliche, visuelle und operative Informationen im selben Modell verbunden bleiben. Gleichzeitig können selten geänderte Sprachregeln unabhängig von laufend aktualisierten Produktinformationen gepflegt werden.
Für Integrationen stehen die Bausteine über REST-API und MCP-Server bereit. Einzelne Inhalte lassen sich außerdem als Markdown-Dokumente exportieren. Das schafft eine Verbindung zwischen zentraler Pflege und portabler Nutzung.
Die größere funktionale Breite verlangt allerdings mehr Modellierungs- und Pflegeaufwand. Teams müssen entscheiden, welches Wissen in welchen Baustein gehört, Verantwortlichkeiten festlegen und Aktualisierungen organisieren. Für ein einzelnes UI-Projekt kann eine design.md deshalb zweckmäßiger sein. Der Vorteil des nxttool-Modells entsteht vor allem, wenn dieselbe Marke mehrere Teams, Formate, Zielgruppen und KI-Anwendungen steuern soll.
Systematischer Vergleich
- Brand Context Protocol: JSON-Protokoll mit Schwerpunkt auf Konformitätsprüfung, Risikoregeln, Claims und Governance. Geeignet für kontrollierte Marketingprozesse und automatisierte Prüfungen. Offen und über API sowie MCP integrierbar.
- design.md: einzelne Projektdatei für Design-Tokens und visuelle Anwendungsregeln. Geeignet für Coding-Agenten, UI-Erzeugung, Linting und Token-Export. Strategische und redaktionelle Markenbestandteile bleiben außerhalb des Formats.
- brand.md: einzelne Datei für Strategie, Sprache, visuelle Grundlagen und optionale Governance. Geeignet als kompakter Markenkontext für Menschen und KI-Tools. Operative Kontexte, Assets und mehrere kombinierbare Inhaltsbausteine sind nur begrenzt abgebildet.
- Brando Schema: offenes semantisches Vokabular mit Entitäten, Beziehungen, Kontrollen und Referenzen. Geeignet für portable Wissensarchitekturen und individuelle Implementierungen. Die betriebliche Infrastruktur muss separat aufgebaut werden.
- nxttool: modulares Markenmodell mit sieben Bausteinen, Generierungslogik, zentraler Pflege, API, MCP und statischen Exporten. Geeignet für markenübergreifende Content- und Bildprozesse sowie eine breitere Markensteuerung. Einrichtung und Pflege sind umfangreicher als bei fokussierten Einzeldateien.
Was bedeutet das in der Praxis?
Für ein Entwicklungsteam, das Benutzeroberflächen konsistent erzeugen möchte, bietet design.md einen direkten Einstieg. Die Datei liegt beim Projekt, lässt sich validieren und liefert ausführbare Designwerte.
Wenn vor allem Positionierung, Markenstimme und grundlegende visuelle Identität in einem Projektkontext benötigt werden, ist brand.md passender. Die Verbindung beider Dateien trennt strategische Identität präzise vom konkreten Designsystem.
BCP empfiehlt sich, wenn Richtlinien, freigegebene Aussagen, Kanalregeln und automatisierte Konformitätsentscheidungen im Vordergrund stehen. Brando ist eine Option für Organisationen, die ein offenes, semantisch reiches Markenwissensmodell in eine eigene technische Architektur integrieren wollen.
nxttool adressiert einen anderen Umfang. Das Modell verbindet zentrale Markenpflege mit konkreter Content- und Bildgenerierung. Mehrere Zielgruppen, Textformate, Kontexte, Bildstile und Referenzen können abhängig vom jeweiligen Auftrag zusammengestellt werden. Dadurch bleibt die Marke nicht nur beschrieben, sondern wird als laufend nutzbare Steuerungsgrundlage organisiert.
Portabilität und Export
Portabilität entscheidet darüber, ob Markenhoheit an ein bestimmtes System gebunden bleibt. design.md und brand.md sind bereits dateibasiert und lassen sich direkt kopieren, versionieren oder in Repositories speichern. Brando setzt Portabilität mit Markdown, YAML und JSON-LD konzeptionell besonders breit um. BCP ist als offener JSON-Standard ebenfalls auf systemübergreifende Verarbeitung ausgelegt.
Beim nxttool-Modell entsteht Portabilität durch mehrere Ausgabewege. Jeder Kernbaustein kann als strukturiertes Markdown-Dokument mit YAML-Frontmatter exportiert werden. Das Designsystem steht zusätzlich als CSS Custom Properties und DTCG-JSON zur Verfügung. Für laufende Integrationen liefern REST-API und MCP-Server die benötigten Markendaten.
Das nxttool Brand Bundle
Das nxttool Brand Bundle führt die exportierbaren Bestandteile des nxttool-Markensystems in einem statischen ZIP-Paket zusammen. Es enthält die Dokumente einer Marke einschließlich Zielgruppen, visueller Stile, Kontexte, Textformate, Design-Tokens, Assets und Referenzbilder.
Damit bleibt die Markendefinition nicht auf die Nutzung innerhalb von nxttool beschränkt. Das Paket kann als Kontext für externe KI-Systeme, als Grundlage einer RAG-Anwendung, für Entwicklungsprozesse oder für eigene Integrationen eingesetzt werden. Statische Exporte ermöglichen außerdem nachvollziehbare Schnappschüsse, etwa für ein bestimmtes Projekt oder einen definierten Freigabestand.
Der praktische Unterschied zu einer einzelnen Datei liegt in der Vollständigkeit und Trennung der Bestandteile. brand.md und design.md können Teil des Exports sein, bilden jedoch jeweils nur einen Ausschnitt ab. Das Bundle transportiert das zusammengehörige Markenwissen einschließlich Assets und anwendungsbezogener Bausteine.
Einordnung
Die fünf Ansätze stehen nicht ausschließlich in Konkurrenz. Sie lösen unterschiedliche Ebenen desselben Problems. design.md und brand.md schaffen kompakte, verständliche Kontextdateien. BCP verbindet Markendefinition mit Durchsetzung und Risikosteuerung. Brando stellt ein offenes Vokabular für semantisch verknüpftes Markenwissen bereit.
Das nxttool-Markensystem reicht funktional weiter, weil es Markensprache, Zielgruppen, Formate, Sachkontexte, visuelle Stile, Referenzen, Designsystem und Assets in einem modularen Betriebsmodell verbindet. Das Brand Bundle ergänzt die zentrale Pflege um einen vollständigen statischen Export. Dieser Umfang ist sinnvoll, wenn Markenwissen mehrere Generatoren, Teams und externe Systeme versorgen soll.
Für eng umrissene Aufgaben bleibt ein fokussierter Standard oft die wirtschaftlichere Wahl. Entscheidend ist deshalb nicht, welches Format abstrakt das umfangreichste ist. Entscheidend ist, welche Markenbestandteile ein Prozess tatsächlich benötigt, wie verbindlich sie geprüft werden müssen und ob die Daten auch außerhalb ihres Ursprungssystems nutzbar bleiben sollen.
