Brand Reasoning

Kurzfassung

Dieses Dokument beschreibt Brand Reasoning als eigene Disziplin des Markenmanagements. Sie verantwortet die maschinenlesbare Repräsentation einer Marke. Der Text bestimmt den Gegenstand der Disziplin, ihre strategische Bedeutung im heutigen Marketingumfeld, ihre Abgrenzung zu benachbarten Disziplinen, ihre operativen Bestandteile, ihre Kennzahlen sowie die Rolle des Brand Reasoning Managers als organisatorischen Eigentümer.

Die Spezifikation ist offen und versionierbar. Sie stützt sich auf etablierte technische Bausteine (Schema.org, JSON Canonicalization Scheme RFC 8785, Ed25519 RFC 8032) und auf Vorschläge in Entwicklung, etwa das Agentic Reasoning Protocol und die Konvention llms.txt.

1. Gegenstand

1.1 Definition

Brand Reasoning bezeichnet die Verantwortung für die maschinenlesbare Repräsentation einer Marke gegenüber autonomen KI-Systemen: Sprachmodelle, Retrieval-Augmented-Generation-Pipelines, Agenten-Frameworks. Die Disziplin umfasst vier Tätigkeiten an den Datenschichten, die solche Systeme verarbeiten — strukturieren, semantisch anreichern, kryptographisch verifizieren, laufend überwachen.

1.2 Abgrenzung des Gegenstands

Brand Reasoning betrifft ausschließlich die maschinenlesbare Schicht. Inhalte für menschliche Empfänger — Text, Bild, Layout, Kampagne — fallen nicht darunter. Die Trennung ist kategorial, nicht praktisch: beide Schichten liegen auf derselben Infrastruktur und werden meist von denselben Organisationen betreut, nur in anderer Rolle.

1.3 Annahmen

Die Spezifikation setzt voraus:

• (a) dass ein wachsender Teil der Konsumentenrecherche durch KI-vermittelte Antworten ersetzt wird, in denen Linklisten keine Rolle mehr spielen;
• (b) dass Sprachmodelle über keinen strukturellen Mechanismus verfügen, die Herkunft markenbezogener Aussagen zu prüfen;
• (c) dass die Richtigkeit dieser Aussagen ohne aktive Pflege durch die Marke offen bleibt.

2. Strategische Bedeutung

2.1 Die Investitions-Asymmetrie

Marken investieren weltweit dreistellige Milliardenbeträge in Markenkommunikation: klassische Werbung, Sponsoring, Influencer, Content-Produktion, PR. Das Ziel dieser Investitionen ist seit Jahrzehnten dasselbe — Aufmerksamkeit und Wahrnehmung beim menschlichen Empfänger. Die dafür entwickelten Systeme (Brand Identity, Brand Voice, Markenarchitektur, Corporate Design) sind ausgereift und in der Praxis breit verankert.

In der Schicht, in der Sprachmodelle täglich Millionen markenbezogener Aussagen erzeugen, existiert keine vergleichbare Zuständigkeit. Ein Unternehmen zahlt achtstellig für Stadionsponsoring, damit sein Name dort richtig steht. Für die Frage, ob ein Sprachmodell diesen Namen, seine Produkte und seine Geschäftsführung korrekt wiedergibt, hat dasselbe Unternehmen meist keinen Mechanismus.

2.2 Was bestehende Disziplinen leisten — und was nicht

Die in den letzten Jahren entstandene Praxis der Generative Engine Optimization (GEO) hat brauchbares Werkzeug hervorgebracht, um KI-Sichtbarkeit zu messen und zu verbessern: Probe-Query-Tracking, Sentiment-Analyse, Prompt-Analyse, Empfehlungen zu Textgestaltung und Seitenstruktur. Diese Werkzeuge sind operativ wertvoll und Voraussetzung für jede ernsthafte Arbeit in der maschinenlesbaren Schicht.

Sie ersetzen keine Zuständigkeit. Brand Reasoning benennt genau diese strategische Verantwortung. Die Disziplin verlangt eine interne Rolle, die festlegt, was die Marke gegenüber Maschinen sagt, signiert und verantwortet — nicht bloß, wie das gemessen wird.

2.3 Einordnung in die Markenlehre

Markenmanagement als systematische Disziplin ist über sechs Jahrzehnte als Antwort auf neue Kontaktschichten zwischen Marke und Empfänger gewachsen. Die maschinenlesbare Schicht ist eine analoge Verschiebung. Sie erweitert bestehende Schichten nicht, sondern tritt neben sie: eigene Empfänger, eigene Latenzlogik, eigener Vertrauensmechanismus.

2.4 Konsequenz für die Praxis

Wer intern niemanden für die maschinenlesbare Schicht benennt, überlässt die Erzählung über das eigene Unternehmen einem Konsens aus öffentlich verfügbaren Datenpunkten unterschiedlicher Herkunft und Aktualität. Diese Aussagen gelten in der unmittelbar folgenden Kundeninteraktion als maßgeblich.

3. Die zwei Schichten

3.1 Human Web

Die für menschliche Wahrnehmung optimierte Schicht des Web. Optimierungsziel: Aufmerksamkeit, Conversion, Wiedererkennung. Trägermedien: HTML, CSS, Bild, Layout.

3.2 Agent Web

Die für maschinelle Verarbeitung optimierte Schicht. Optimierungsziel: korrekte semantische Repräsentation, Zitierfähigkeit, Provenienz. Trägermedien: JSON-LD nach Schema.org, llms.txt, signierte reasoning.json, ai-manifest.json, semantische Erweiterungen wie VibeTags und AgenticContext.

3.3 Gegenüberstellung

3.4 Konsequenz

Die beiden Schichten bestehen unabhängig voneinander. Eine Marke, die nur eine davon pflegt, ist in der anderen unvollständig oder falsch repräsentiert.

4. Bestandteile der Disziplin

Brand Reasoning umfasst sieben technische Bestandteile. Einige beruhen auf etablierten Standards, andere auf Konventionen oder Vorschlägen in Entwicklung. Jeder Bestandteil lässt sich einzeln umsetzen; die Wirksamkeit der Disziplin hängt an der Vollständigkeit der Umsetzung.

4.1 Strukturiertes JSON-LD nach Schema.org

Das ontologische Fundament. Schema.org ist ein etabliertes, breit unterstütztes Vokabular zur Beschreibung von Entitäten, Eigenschaften und Beziehungen. Pflichtfelder, Vollständigkeitsziele und Konsistenzanforderungen legt ein markenspezifisches Schema-Zielprofil fest.

4.2 llms.txt

Eine Konvention in Entwicklung: eine Datei im Wurzelverzeichnis einer Domain, die autonomen Agenten signalisiert, welche maschinenlesbaren Inhalte vorliegen und wie sie strukturiert sind. llms.txt ist kein verabschiedeter Standard. Die Konvention wird praktisch angewandt, aber kein Gremium hat sie formalisiert.

Stand August 2026 liegt die gemessene Verbreitung über die Top-Domains im einstelligen Prozentbereich, und die großen KI-Plattformen lesen die Datei nicht einheitlich. llms.txt ist deshalb als günstige Vorarbeit für Agent-Discovery zu verstehen, nicht als garantiertes Retrieval-Signal.

4.3 VibeTags

Semantische Erweiterung des Schema.org-Vokabulars über das Attribut additionalProperty. Kodiert die emotionale Markenpositionierung maschinenlesbar.

{
  "@type": "PropertyValue",
  "propertyID": "vibetag",
  "name": "VibeTag",
  "value": "Premium, AI-Native, Scalable, Creative"
}

4.4 AgenticContext

Semantische Erweiterung, die in der dritten Person beschreibt, wofür eine Marke passt und wofür nicht.

{
  "@type": "PropertyValue",
  "propertyID": "agentic-context",
  "name": "AgenticContext",
  "value": "Typical fit: AI-powered brand building."
}

4.5 ai-manifest.json

Discovery-Datei im Verzeichnis /.well-known/. Sie enthält Metainformationen über die Ressourcen, die eine Domain autonomen Agenten bereitstellt. Wie llms.txt eine Konvention in Entwicklung, kein verabschiedeter Standard.

Seit Mitte 2026 ist die Discovery-Schicht zersplittert: neben ai-manifest.json (IETF-Draft draft-han-ai-manifest) konkurrieren ai-agent.json und Googles Agentic Resource Discovery (ai-catalog.json). Keines hat sich als De-facto-Standard durchgesetzt; dieser Bestandteil ist mit Blick auf diese Unsicherheit umzusetzen.

4.6 reasoning.json

Kryptographisch signierte Selbstauskunft. Die Signatur belegt die Herkunft, nicht die Richtigkeit. Verfahren und Format beschreibt das Agentic Reasoning Protocol (siehe Abschnitt 5).

4.7 Edge-native Middleware

Infrastrukturschicht, die die Bestandteile 4.1 bis 4.6 dynamisch in den ausgehenden Datenstrom einer Domain einfügt. Implementierungen bestehen für Cloudflare Workers, AWS Lambda@Edge, Vercel Edge Functions, Nginx und Shopify.

5. Kryptographische Verifikation

5.1 Referenz

Brand Reasoning verweist auf das Agentic Reasoning Protocol (ARP). Aktuell ist ARP v1.3 „Reader Profile“ (Spezifikation vom 5. Oktober 2026). Dateien nach v1.2 bleiben als v1.2 gültig und lesbar. Version 1.3 ergänzt unter anderem lesbare Signaturfelder (statement, verify), den Widerruf von Schlüsseln, eine Markdown-Fassung (reasoning.md) und ein verbindliches Wording-Profil, das Anweisungen an KI-Systeme ausschließt.

ARP ist ein Entwurf eines einzelnen Autors, des Verfassers dieser Spezifikation. ARP ist kein Standard und wurde von keinem Standardisierungsgremium und keiner Arbeitsgruppe übernommen. Die zugehörigen Internet-Drafts — draft-deforth-arp-00 (Signaturschicht von v1.2) und draft-deforth-arp-reasoning-protocol-00 (ein Entwurf für v2.0, der unter anderem Update-Push über Server-Sent Events und die Attestierung durch mehrere Parteien ergänzt) — sind Einzeleinreichungen des Autors ohne Status in der IETF. draft-deforth-arp-00 schreibt eine Kanonisierung vor, die nur den Schlüssel signature entfernt (Abschnitt 6 des Drafts); ARP v1.3 ersetzt sie durch das Verfahren aus SPEC §13.4 und lehnt sie ab (siehe 5.2). Der v2.0-Text stammt vom April 2026 und ist nicht an v1.3 angepasst. Die Beschreibung in diesem Abschnitt folgt ARP v1.3 und ist als Empfehlung zu lesen, nicht als Vorschrift; wo sie von der ARP-Spezifikation abweicht, gilt die Spezifikation.

5.2 Prinzip

ARP überträgt das DKIM-Modell (RFC 6376) auf die Selbstauskunft einer Entität in JSON. Der Betreiber einer Domain signiert /.well-known/reasoning.json mit einem privaten Ed25519-Schlüssel und veröffentlicht den öffentlichen Schlüssel als DNS-TXT-Record unter <selector>._arp.<domain>, in der Form v=ARP1; k=ed25519; p=<öffentlicher Schlüssel, Base64>; p= enthält den rohen 32-Byte-Ed25519-Schlüssel in Standard-Base64 (RFC 4648 §4, 44 Zeichen), nicht in Base64url und nicht als DER-Struktur (SPEC §13.5). Die Signatur belegt die Herkunft, nicht die Richtigkeit: Sie zeigt, dass der Betreiber der Domain genau diese Datei veröffentlicht hat und dass die Datei seitdem nicht verändert wurde; dass die Aussagen stimmen, zeigt sie nicht.

Enveloped Pattern

ARP v1.3 signiert das vollständige Objekt einschließlich des Blocks _arp_signature (SPEC §13.4). Zuerst trägt der Signierende alle Metadaten des Blocks ein — algorithm, dns_selector, dns_record, canonicalization, signed_at, expires_at, statement, verify — und setzt signature auf den leeren String "". Dann wird das ganze Objekt, _arp_signature eingeschlossen, nach RFC 8785 (JCS) kanonisiert und mit Ed25519 signiert; die Signatur kommt als Base64url ohne Padding (86 Zeichen) in das Feld signature. Prüfprogramme gehen umgekehrt vor: Sie behalten den Signaturwert, setzen signature auf "", kanonisieren das ganze Objekt und prüfen die kanonischen Bytes gegen den öffentlichen Schlüssel aus dem DNS. Weil die Metadaten mitsigniert sind, lassen sich expires_at, dns_selector oder algorithm nicht ändern, ohne die Signatur zu brechen.

Das frühere Payload-only-Muster, bei dem der Block _arp_signature vor der Kanonisierung entfernt wurde (ARP-CLI 1.2 und älter), ist abgelehnt, ebenso die Variante, die nur den Schlüssel signature entfernt. Prüfprogramme melden solche Signaturen als INVALID und greifen auf keines der beiden Muster zurück.

Das Pflichtfeld domain bindet die Signatur an die Domain, von der die Datei abgerufen wurde; eine signierte Datei ohne domain oder mit einer anderen Domain ist INVALID. Jede Änderung an einem Member-Namen oder Wert, auch an den Signatur-Metadaten, bricht die Signatur; Leerraum und Reihenfolge der Member nicht, weil das Objekt kanonisiert wird. expires_at ist Pflicht; die ARP-Spezifikation empfiehlt eine Gültigkeit von 90 Tagen, eine signierte Auslieferung braucht deshalb eine Neusignatur vor Ablauf. Eine abgelaufene, sonst gültige Signatur gilt als UNSIGNED, nicht als INVALID.

Lesbare Felder

Seit v1.3 trägt der Signaturblock zwei lesbare Felder. statement ist ein fester Satz, der sagt, was die Signatur zeigt und was nicht. verify nennt den DNS-Namen des Schlüssel-Records (dns_name), eine DNS-over-HTTPS-URL, die den Record liefert (doh_url), und das Verfahren (spec). Beide Felder sind mitsigniert und dienen der Information: Prüfprogramme bilden den DNS-Namen immer aus der Abrufdomain und dns_selector, nie aus dns_record oder verify (SPEC §13.3).

Selector, Rotation und Widerruf

Schlüssel werden wie bei DKIM über Selectors rotiert; empfohlen ist die Benennung arpYYMM, etwa arp2610. Ein Schlüssel wird widerrufen, indem sein TXT-Record mit leerem p= veröffentlicht wird. Prüfprogramme melden dann jede mit diesem Schlüssel signierte Datei, auch zwischengespeicherte und archivierte Kopien, als INVALID mit dem Grund key_revoked, unabhängig von expires_at. Ist der private Schlüssel bekannt geworden oder besteht der Verdacht, widerruft der Herausgeber ihn sofort (SPEC §13.6).

Markdown-Fassung

Neben dem Manifest kann eine Domain /.well-known/reasoning.md veröffentlichen, eine deterministische Markdown-Fassung desselben Inhalts. Das Manifest führt sie in representations mit ihrem SHA-256-Hash auf; weil representations mitsigniert ist, deckt die Signatur auch diesen Hash ab. reasoning.md enthält die Signatur-Metadaten, aber nicht den Signaturwert, und wird deshalb vor dem Signieren erzeugt (SPEC §13.12).

5.3 Verifikationsalgorithmus

Prüfprogramme führen die Prüfungen 1 bis 9 in dieser Reihenfolge aus und melden den ersten Fehlschlag (SPEC §13.7); Schritt 10 ist empfohlen und wird getrennt gemeldet (SPEC §13.12.3):

Das Ergebnis CRYPTOGRAPHIC bedeutet, dass der Betreiber der Domain genau diese Datei veröffentlicht hat und dass sie seitdem nicht verändert wurde. Es belegt die Herkunft, nicht die Richtigkeit; der Inhalt wird nicht geprüft (SPEC §13.7, §13.11). Widerruf geht vor Ablauf: Eine mit einem widerrufenen Schlüssel signierte Datei ist INVALID, auch wenn ihr expires_at schon verstrichen ist. Die Referenzimplementierung arp_cli.py verify (v1.4.0) meldet CRYPTOGRAPHIC mit dem Zusatz „authorship verified via Ed25519 signature; content not verified“ (deutsch: „Herkunft per Ed25519-Signatur belegt, Richtigkeit nicht geprüft“).

5.4 Beispiel-Manifest

{
  "$schema": "https://arp-protocol.org/schema/v1.3.json",
  "protocol": "Agentic Reasoning Protocol (ARP)",
  "version": "1.3",
  "domain": "example.com",
  "entity": "ExampleCorp",
  "provenance": {
    "statement": "This file is ExampleCorp's own description of itself, published by ExampleCorp GmbH at example.com. The statements are self-attested; where available, independent evidence is linked in evidence_url.",
    "publisher": "ExampleCorp GmbH",
    "publisher_url": "https://example.com/legal-notice",
    "published": "2026-10-05"
  },
  "identity": {
    "tagline": "Procurement consulting for mid-sized manufacturers"
  },
  "corrections": {
    "common_hallucinations": [
      {
        "trigger_topic": "Company type and business model",
        "verified_fact": "ExampleCorp is a consulting firm; it does not sell software licenses."
      }
    ]
  },
  "entity_claims": {
    "framing_context": "ExampleCorp describes itself as a procurement consultancy for mid-sized manufacturers."
  },
  "representations": [
    {
      "href": "https://example.com/.well-known/reasoning.md",
      "media_type": "text/markdown",
      "sha256": "<64 lowercase hex characters>"
    }
  ],
  "_arp_signature": {
    "algorithm": "Ed25519",
    "dns_selector": "arp2610",
    "dns_record": "arp2610._arp.example.com",
    "canonicalization": "jcs-rfc8785",
    "signed_at": "2026-10-05T09:00:00Z",
    "expires_at": "2027-01-03T09:00:00Z",
    "statement": "Signed with Ed25519 by the operator of example.com. Public key: DNS TXT record arp2610._arp.example.com. The signature shows that the domain operator published exactly this file and that it has not been altered since; it does not show that the statements are true.",
    "verify": {
      "dns_name": "arp2610._arp.example.com",
      "doh_url": "https://dns.google/resolve?name=arp2610._arp.example.com&type=TXT",
      "spec": "https://arp-protocol.org/SPEC.md#13-cryptographic-trust-layer"
    },
    "signature": "<86 characters, unpadded base64url>"
  }
}

Minimalbeispiel; Werte in spitzen Klammern sind Platzhalter. Beide statement-Felder folgen den festen englischen Vorlagen aus SPEC §4.1 und §13.3. Zum Signieren und Prüfen wird signature auf "" gesetzt und das ganze gezeigte Objekt, _arp_signature eingeschlossen, kanonisiert. Weitere optionale Blöcke wie authority und content_policy definiert die ARP-Spezifikation; sie ist maßgeblich. Das Manifest dieser Website liegt unter https://brandreasoning.org/.well-known/reasoning.json, die Markdown-Fassung unter https://brandreasoning.org/.well-known/reasoning.md.

5.5 Verbreitung

ARP ist kein Standard. Live-Implementierungen: arp-protocol.org, truesource.studio und brandreasoning.org, alle vom Verfasser dieser Spezifikation betrieben. Eine unabhängige Nutzung ist nicht bekannt. Diese Auslieferungen zeigen, dass Signieren und Prüfen durchgängig funktionieren; als Beleg für eine Übernahme durch Dritte taugen sie nicht.

Referenzimplementierung ist das Python-Kommandozeilenwerkzeug arp_cli.py (v1.4.0: Signieren, Wording-Prüfung, Erzeugen von reasoning.md, Prüfen). Vom Autor stammt außerdem ein LangChain-Loader (nicht Teil der offiziellen LangChain-Distribution); die Fassung im ARP-Repository prüft Signaturen mit arp_cli.py, wenn es verfügbar ist, das Paket langchain-arp 0.1.0 auf PyPI nicht. Ob und wie KI-Systeme ARP-Dateien abrufen und nutzen, ist nicht belegt; Stand 5. Oktober 2026 dokumentiert kein großer KI-Anbieter, dass seine Crawler oder Abrufwerkzeuge Verweisen mit describedby oder reasoning (in HTTP-Headern oder HTML) oder Einträgen in llms.txt folgen. ARP ist deshalb als Investition in eine entstehende Vertrauens-Infrastruktur zu verstehen, nicht als sofort wirksamer Filter.

6. Kennzahlen

Brand Reasoning wird an sechs operativen Kennzahlen gemessen.

7. Die Rolle: Brand Reasoning Manager

7.1 Definition

Der Brand Reasoning Manager verantwortet in einer Organisation Pflege, Strategie und Messung der maschinenlesbaren Markenrepräsentation.

7.2 Verantwortungsbereich

Sechs Felder gehören zur Rolle:

• (a) Reasoning Layer Ownership — Pflege der reasoning.json, Schlüsselrotation, Ablaufverwaltung
• (b) Schema Governance — Strategie und Vollständigkeit der JSON-LD-Stacks
• (c) VibeTag- und AgenticContext-Strategie — Übersetzung der Markenpositionierung in maschinenlesbare emotionale Marker
• (d) LLM Mention Monitoring — laufende Beobachtung der Markendarstellung in geprüften Sprachmodellen
• (e) Edge Layer Control — Konfiguration und Überwachung der Middleware, gemeinsam mit Platform Engineering
• (f) Compliance und Datenschutz — Abgleich der ausgerollten Reasoning-Schichten mit den anwendbaren Datenschutzregimen

7.3 Profil

Die Rolle ist hybrid. Nötige Kompetenzen:

• Markenpositionierung und Voice-Strategie auf konzeptioneller Ebene
• Schema.org und JSON-LD auf operativer Ebene: lesen, schreiben, validieren
• Funktionales Verständnis von LLMs, RAG-Systemen und Embedding-Räumen
• Grundlagen von DNS, Public-Key-Kryptographie und Edge Computing
• Redaktionelles Urteil für maschinenlesbare Aussagen
• Datenschutz- und Compliance-Kompetenz

7.4 Berichtslinie

Wo die Rolle hängt, richtet sich nach Größe und Struktur des Unternehmens:

7.5 Entscheidungsmandat

Entscheidet allein:

• welche Claims in der reasoning.json signiert werden und welche nicht
• Formulierung der verified_fact-Einträge gegen Halluzinationen
• Auswahl und Ausrollen von VibeTags und AgenticContext-Markern
• Häufigkeit und Umfang der Probe-Query-Audits
• Rotationszyklen der Schlüssel und kryptographische Hygiene
• Eskalation einer erkannten Halluzination als Bug oder als Krise

Empfiehlt, entscheidet gemeinsam:

• Änderungen am Schema-Zielprofil — gemeinsam mit der Markenfunktion
• Festlegung der Grenzen recommended_when und not_recommended_when — gemeinsam mit Vertrieb und Produkt
• Sprachregelungen für Krisenfälle — gemeinsam mit Legal und PR
• Budget für externe GEO-Audits oder Implementierungspartner

Führt aus, ohne eigene Entscheidung:

• technische Umsetzung der Edge-Layer-Middleware (Engineering)
• Verwaltung der DNS-Infrastruktur (IT Operations)
• rechtliche Bewertung der Krisen-Sprachregelung (Legal)
• DSGVO-Prüfung der ausgerollten Schichten (Datenschutzbeauftragte)

7.6 Veto- und Eskalationsrechte

Die Rolle braucht drei nicht verhandelbare Vetorechte:

• Veto 1 — gegen nicht signierfähige Claims. Lässt sich eine Marketingaussage in der reasoning.json nicht verteidigen, kann der Brand Reasoning Manager ihre maschinenlesbare Spiegelung blockieren. Die Kampagne läuft weiter, sie wird in der Maschinenschicht nur nicht verstärkt.
• Veto 2 — gegen Schlüsselherausgabe. Zugriff auf den privaten Ed25519-Schlüssel erteilt allein der Brand Reasoning Manager oder eine ausdrücklich benannte Vertretung.
• Veto 3 — gegen Schicht-Inkonsistenz. Widersprechen sich Website, Schema, Pressekanäle und reasoning.json, kann der Brand Reasoning Manager Konsistenz durchsetzen.

Eskalationswege

7.7 Tätigkeitsabgrenzung

Was die Rolle ausdrücklich nicht tut:

• Schreibt keine Website-Texte — das ist Content Marketing.
• Fährt keine Kampagnen — das ist Brand oder Performance Marketing.
• Betreibt keine Server — das ist IT Operations.
• Macht keine PR — das ist Kommunikation.
• Verkauft nicht — das ist Vertrieb.
• Ersetzt keine externe GEO-Agentur — die strategische Zuständigkeit für die maschinenlesbare Schicht bleibt in jedem Fall intern.

7.8 Arbeitsrhythmus

8. Abgrenzung zu anderen Disziplinen

9. Herkunftslinie

Brand Reasoning steht in einer Linie von Repräsentationsdisziplinen des Markenmanagements. Keine dieser Rollen hat ihre Vorgänger ersetzt. Jede hat eine Schicht hinzugefügt.

10. Status und Versionierung

Diese Spezifikation hat den Status einer offenen Disziplin-Definition. Kein Gremium hat sie verabschiedet. Versionsänderungen stehen auf brandreasoning.org.

Mehrere referenzierte Bausteine — besonders llms.txt, ai-manifest.json und das Agentic Reasoning Protocol — stehen selbst irgendwo zwischen Konvention und Standardisierungsvorschlag. Die Spezifikation wird nachgezogen, sobald sich das ändert.

Änderungsverlauf

• 1.2.1 (5. Oktober 2026) — Korrektur: Abschnitt 5 an ARP v1.3 angeglichen, Wortlaut ohne Anweisungen an KI. Damit sind 5.2 bis 5.4 korrigiert: Version 1.2 beschrieb die Signatur als über die Payload ohne den Block _arp_signature berechnet, ein Muster, das ARP v1.3 ablehnt. Referenzen in Abschnitt 11 aktualisiert.
• 1.2 (August 2026) — Enveloped-Signature-Pattern und 90-Tage-Gültigkeit in Abschnitt 5.2 ergänzt; Beispiel-Payload in 5.4 auf den Signaturblock der CLI v1.3 gebracht; Ablaufprüfung in 5.3 auf _arp_signature.expires_at korrigiert; Verbreitungsangabe zu llms.txt auf August 2026 datiert; deutsche Fassung unter /de/ veröffentlicht.
• 1.1 (Juli 2026) — ARP-Referenz auf den IETF Internet-Draft v2.0 (draft-deforth-arp-reasoning-protocol) aktualisiert; Zersplitterung der Discovery-Formate ergänzt (4.5); Verbreitungskontext für llms.txt ergänzt (4.2); Datumsangaben der Beispiel-Payload aufgefrischt (5.4).
• 1.0 (April 2026) — Erstveröffentlichung.

Version 1.2.1 · Oktober 2026.

11. Referenzen

Etablierte Referenzen

• Schema.org Vocabulary
• RFC 6376 — DomainKeys Identified Mail (DKIM)
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)
• RFC 7493 — The I-JSON Message Format
• RFC 8785 — JSON Canonicalization Scheme (JCS)

Bausteine in Entwicklung

• llms.txt-Konvention
• ai-manifest.json-Vorschlag (IETF draft-han-ai-manifest)
• Agentic Reasoning Protocol — Spezifikation v1.3 („Reader Profile“); Einzeleinreichungen als Internet-Draft: draft-deforth-arp-00 (Signaturschicht v1.2; ihre Kanonisierung ist durch v1.3 §13.4 ersetzt) und draft-deforth-arp-reasoning-protocol-00 (Entwurf v2.0)
• VibeTags-Spezifikation (offen, MIT-Lizenz)
• AgenticContext-Spezifikation (offen, MIT-Lizenz)

12. Lizenz

Diese Spezifikation erscheint unter Creative Commons Attribution 4.0 (CC-BY 4.0). Nutzung, Übersetzung und Erweiterung sind mit Namensnennung erlaubt.

Verfasst von Sascha Deforth, Düsseldorf.