Brand Reasoning

Abstract

This document specifies Brand Reasoning as a distinct discipline of brand management responsible for the machine-readable representation of a brand. It defines the subject of the discipline, its strategic significance in the current marketing context, its demarcation from related disciplines, its operational components, its metrics, and the role of the Brand Reasoning Manager as the organizational owner.

The specification is open and versionable. It references established technical building blocks (Schema.org, JSON Canonicalization Scheme RFC 8785, Ed25519 RFC 8032) and evolving proposals such as the Agentic Reasoning Protocol and the llms.txt convention.

This English version is normative. A German translation is available at brandreasoning.org/de/; where the two diverge, this text prevails.

1. Subject Matter

1.1 Definition

Brand Reasoning refers to the management of a brand's machine-readable representation for autonomous AI systems, including language models, Retrieval-Augmented Generation pipelines, and agent frameworks. The discipline encompasses the structuring, semantic enrichment, cryptographic verification, and continuous monitoring of brand-related statements in the data layers processed by such systems.

1.2 Scope Delimitation

Brand Reasoning pertains exclusively to the machine-readable layer. Content optimized for human recipients (copy, images, layouts, campaigns) falls outside the discipline's scope. This separation is categorical, not practical — both layers exist on the same infrastructure and are typically managed by the same organizations, albeit in different roles.

1.3 Assumptions

The specification assumes:

• (a) that a growing share of consumer research is being replaced by AI-mediated answers in which link lists play no role;
• (b) that language models possess no structural mechanism for verifying the provenance of brand-related statements;
• (c) that the accuracy of these statements cannot be guaranteed without active management by the brand.

2. Strategic Significance

2.1 The Investment Asymmetry

Brands worldwide invest hundreds of billions annually in brand communication: traditional advertising, sponsorship, influencer partnerships, content production, PR. The objective of these investments has been the same for decades — attention and perception management for the human recipient. The systems of brand management developed for this purpose (Brand Identity, Brand Voice, Brand Architecture, Corporate Design) are mature and widely established in practice.

In the layer where language models generate millions of brand-related statements daily, no comparable systematic responsibility exists. A brand that invests eight-figure sums in sponsorship to be correctly represented in a stadium typically has no mechanism to ensure that a language model accurately reproduces its brand name, products, or leadership.

2.2 What Existing Disciplines Deliver — and What They Don't

The practice of Generative Engine Optimization (GEO) that has emerged in recent years has developed essential tools for measuring and improving AI visibility: probe-query tracking, sentiment analysis, prompt analysis, recommendations for text design and page structure. These tools are operationally valuable and prerequisite for any serious work in the machine-readable layer.

However, they do not replace systematic ownership of this layer. Brand Reasoning designates this strategic responsibility. The discipline demands an internal role that defines what the brand says, signs, and takes responsibility for vis-à-vis machines — not merely how it is measured.

2.3 Positioning in Brand Theory

Brand management as a systematic discipline has emerged over the last six decades as a response to new contact layers between brand and recipient. The machine-readable layer represents an analogous shift. It is not an extension of existing layers but an independent representation layer with its own recipients, its own latency logic, and its own trust mechanism.

2.4 Consequence for Practice

A brand that designates no internal owner for the machine-readable layer surrenders the narrative about itself to a consensus of publicly available data points of varying provenance and currency. It loses control over statements that are taken as definitive in immediately downstream consumer interactions.

3. The Two Layers

3.1 Human Web

The layer of the web optimized for human perception. Optimization target: attention, conversion, brand recognition. Carrier media: HTML, CSS, imagery, layouts.

3.2 Agent Web

The layer of the web optimized for machine processing. Optimization target: accurate semantic representation, citability, provenance. Carrier media: JSON-LD per Schema.org, llms.txt, signed reasoning.json, ai-manifest.json, semantic extensions such as VibeTags and AgenticContext.

3.3 Comparison

3.4 Consequence

The two layers exist independently. A brand maintained in only one of the two layers is incompletely or inaccurately represented in the other.

4. Components of the Discipline

Brand Reasoning comprises seven technical components. Some are based on established standards, others on evolving conventions or proposals. Each component is optionally implementable; the effectiveness of the discipline correlates with the completeness of the implementation.

4.1 Structured JSON-LD per Schema.org

The ontological foundation. Schema.org is an established, broadly supported vocabulary for describing entities, properties, and relationships. Required fields, completeness targets, and consistency requirements are defined in a brand-specific schema target profile.

4.2 llms.txt

An evolving convention for a file in the root directory of a domain that signals to autonomous agents the machine-readable content available and its structure. llms.txt is not a ratified standard; the convention is already applied in practice but has not been formalized through a standards body.

As of August 2026, measured adoption remains in the single-digit percentage range across top domains, and major AI platforms do not uniformly consume the file. llms.txt should therefore be treated as low-cost groundwork for agent discovery, not as a guaranteed retrieval signal.

4.3 VibeTags

Semantic extension of the Schema.org vocabulary via the additionalProperty attribute. Encodes emotional brand positioning in machine-readable form.

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

4.4 AgenticContext

Semantic extension that describes, in the third person, the contexts in which a brand considers itself a fit or not a fit.

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

4.5 ai-manifest.json

Discovery file in the /.well-known/ directory. Contains meta-information about the resources provided by a domain for autonomous agents. Like llms.txt, an evolving convention, not a ratified standard.

Since mid-2026 the agent discovery layer has fragmented: alongside ai-manifest.json (IETF draft draft-han-ai-manifest), competing formats include ai-agent.json and Google's Agentic Resource Discovery (ai-catalog.json). None has yet established itself as the de-facto default; this component should be implemented with that volatility in mind.

4.6 reasoning.json

Cryptographically signed self-description. The signature shows who published the file and that it has not been altered since; it does not show that the statements are true. The procedure and format are described by the Agentic Reasoning Protocol (see Section 5).

4.7 Edge-Native Middleware

Infrastructure layer for dynamic injection of components 4.1 through 4.6 into the outgoing data stream of a domain. Implementations exist for Cloudflare Workers, AWS Lambda@Edge, Vercel Edge Functions, Nginx, and Shopify.

5. Cryptographic Verification

5.1 Reference

Brand Reasoning references the Agentic Reasoning Protocol (ARP). The current version is ARP v1.3 “Reader Profile” (specification dated 5 October 2026). Files following v1.2 remain valid and readable as v1.2. Version 1.3 adds, among other things, readable signature fields (statement, verify), key revocation, a Markdown representation (reasoning.md), and a normative wording profile that excludes instructions to AI systems.

ARP is a single-author draft proposal by the author of this specification. It is not a standard and has not been adopted by any standards body or working group. The related Internet-Drafts — draft-deforth-arp-00 (signature layer of v1.2) and draft-deforth-arp-reasoning-protocol-00 (a v2.0 design that adds, among other things, update push via Server-Sent Events and multi-party attestation) — are individual submissions by the author without IETF standing. draft-deforth-arp-00 prescribes a canonicalization that removes only the signature key (Section 6 of the draft); ARP v1.3 replaces it with the procedure of SPEC §13.4 and rejects it (see 5.2). The v2.0 text dates from April 2026 and has not been revised for v1.3. The description in this section follows ARP v1.3 and should be understood as a recommendation, not a requirement; where it differs from the ARP specification, the specification governs.

5.2 Principle

ARP transfers the DKIM model (RFC 6376) to an entity's self-description in JSON. The operator of a domain signs /.well-known/reasoning.json with a private Ed25519 key and publishes the public key as a DNS TXT record at <selector>._arp.<domain>, in the form v=ARP1; k=ed25519; p=<public key, Base64>; p= holds the raw 32-byte Ed25519 public key in standard Base64 (RFC 4648 §4, 44 characters), not in Base64url and not as a DER structure (SPEC §13.5). The signature establishes origin, not accuracy: it shows that the operator of the domain published exactly this file and that the file has not been altered since; it does not show that the statements are true.

Enveloped pattern

ARP v1.3 signs the complete object, including the _arp_signature block (SPEC §13.4). The signer first fills in all metadata of the block — algorithm, dns_selector, dns_record, canonicalization, signed_at, expires_at, statement, verify — and sets signature to the empty string "". The entire object, _arp_signature included, is then canonicalized per RFC 8785 (JCS) and signed with Ed25519; the signature is written into the signature field as unpadded Base64url (86 characters). Verifiers proceed inversely: they keep the signature value, set signature to "", canonicalize the entire object, and check the canonical bytes against the public key from DNS. Because the metadata is signed as well, expires_at, dns_selector, or algorithm cannot be changed without breaking the signature.

The earlier payload-only pattern, in which the _arp_signature block was removed before canonicalization (ARP CLI 1.2 and earlier), is rejected, as is the variant that removes only the signature key. Verifiers report such signatures as INVALID and do not fall back to either pattern.

The mandatory domain field binds the signature to the domain from which the file was retrieved; a signed file without domain, or with a different domain, is INVALID. Any change to a member name or value, including the signature metadata, breaks the signature; whitespace and member order do not, because the object is canonicalized. expires_at is required; the ARP specification recommends a validity of 90 days, so a signed deployment needs re-signing before expiry. An expired but otherwise valid signature counts as UNSIGNED, not as INVALID.

Readable fields

Since v1.3, the signature block carries two readable fields. statement is a fixed sentence stating what the signature shows and what it does not show. verify names the DNS name of the key record (dns_name), a DNS-over-HTTPS URL that returns the record (doh_url), and the procedure (spec). Both fields are covered by the signature and are informational: verifiers always construct the DNS name from the retrieval domain and dns_selector, never from dns_record or verify (SPEC §13.3).

Selectors, rotation, and revocation

Keys are rotated through selectors, as in DKIM; the recommended naming is arpYYMM, for example arp2610. A key is revoked by publishing its TXT record with an empty p= value. Verifiers then report every file signed with that key, including cached and archived copies, as INVALID with the reason key_revoked, regardless of expires_at. Publishers revoke a key at once when the private key is known or suspected to be compromised (SPEC §13.6).

Markdown representation

Alongside the manifest, a domain can publish /.well-known/reasoning.md, a deterministic Markdown rendering of the same content. The manifest lists it in representations with its SHA-256 digest; because representations is covered by the signature, the signature also covers this digest. reasoning.md contains the signature metadata but not the signature value, so it is rendered before signing (SPEC §13.12).

5.3 Verification Algorithm

Verifiers apply checks 1 to 9 in this order and report the first failure (SPEC §13.7); step 10 is recommended and reported separately (SPEC §13.12.3):

The result CRYPTOGRAPHIC means that the operator of the domain published exactly this file and that it has not been altered since. It establishes origin, not accuracy; the content is not checked (SPEC §13.7, §13.11). Revocation takes precedence over expiry: a file signed with a revoked key is INVALID even if its expires_at has passed. The reference implementation arp_cli.py verify (v1.4.0) reports CRYPTOGRAPHIC as “authorship verified via Ed25519 signature; content not verified”.

5.4 Example 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>"
  }
}

Minimal example; values in angle brackets are placeholders. Both statement fields follow the fixed English templates of SPEC §4.1 and §13.3. For signing and verification, signature is set to "" and the entire object shown, _arp_signature included, is canonicalized. Further optional blocks, such as authority and content_policy, are defined in the ARP specification, which governs. The manifest of this site is published at https://brandreasoning.org/.well-known/reasoning.json, its Markdown representation at https://brandreasoning.org/.well-known/reasoning.md.

5.5 Adoption Status

ARP is not a standard. Live implementations: arp-protocol.org, truesource.studio, and brandreasoning.org, all operated by the author of this specification. No independent use is known. These deployments show that signing and verification work end to end; they are not evidence of adoption by third parties.

The reference implementation is the Python command-line tool arp_cli.py (v1.4.0: signing, wording check, rendering of reasoning.md, verification). The author also provides a LangChain document loader (not part of the official LangChain distribution); the version in the ARP repository checks signatures with arp_cli.py when it is available, the package langchain-arp 0.1.0 on PyPI does not. Whether and how AI systems retrieve and use ARP files is not established; as of 5 October 2026, no major AI provider documents that its crawlers or fetchers follow describedby or reasoning links (in HTTP headers or HTML) or references in llms.txt. ARP should therefore be understood as an investment in an emerging trust infrastructure, not as an immediately effective filter.

6. Metrics

Brand Reasoning is measured against six operational metrics.

7. The Role: Brand Reasoning Manager

7.1 Definition

The Brand Reasoning Manager is the person in an organization responsible for the maintenance, strategy, and measurement of the machine-readable brand representation.

7.2 Scope of Responsibility

Six domains fall within the role's purview:

• (a) Reasoning Layer Ownership — Maintenance of reasoning.json, key rotation, expiration management
• (b) Schema Governance — Strategy and completeness of JSON-LD stacks
• (c) VibeTag & AgenticContext Strategy — Translation of brand positioning into machine-readable emotional markers
• (d) LLM Mention Monitoring — Continuous tracking of brand representation in evaluated language models
• (e) Edge Layer Control — Configuration and monitoring of middleware in collaboration with platform engineering
• (f) Compliance & Privacy — Ensuring conformity of deployed reasoning layers with applicable data protection regimes

7.3 Profile

The role is hybrid. Required competencies:

• Brand positioning and voice strategy at a conceptual level
• Schema.org and JSON-LD at an operational level (reading, writing, validating)
• Functional understanding of LLMs, RAG systems, and embedding spaces
• Fundamentals of DNS, public-key cryptography, and edge computing
• Editorial judgment for machine-readable statements
• Data protection and compliance competency

7.4 Reporting Line

Organizational placement depends on company size and structure:

7.5 Decision Mandate

Autonomous decisions:

• Which claims are signed in the reasoning.json and which are not
• Wording of verified_fact entries against hallucinations
• Selection and deployment of VibeTags and AgenticContext markers
• Frequency and scope of probe-query audits
• Key rotation cycles and cryptographic hygiene
• Escalation of a detected hallucination as bug or crisis

Recommend, with co-decision:

• Changes to the schema target profile — jointly with brand function
• Definition of recommended_when and not_recommended_when boundaries — jointly with Sales and Product
• Crisis response language — jointly with Legal and PR
• Budget allocation for external GEO audits or implementation partners

Execute, without own decision:

• Technical implementation of edge-layer middleware (Engineering)
• DNS infrastructure management (IT Operations)
• Legal assessment of crisis response wording (Legal)
• GDPR compliance review of deployed layers (Data Protection Officer)

7.6 Veto & Escalation Rights

The role requires three non-negotiable veto rights:

• Veto 1 — against non-signable claims. If marketing statements cannot be defended in the reasoning.json, the Brand Reasoning Manager may block their machine-readable reflection. The campaign may still run — it simply won't be amplified in the machine layer.
• Veto 2 — against key disclosure. Access to the private Ed25519 key may only be granted by the Brand Reasoning Manager or an explicitly designated deputy.
• Veto 3 — against layer inconsistency. When statements across website, schema, press channels, and reasoning.json are contradictory, the Brand Reasoning Manager may enforce consistency.

Escalation Paths

7.7 Activity Delimitation

What the role expressly does not do:

• Does not write website copy — That is Content Marketing.
• Does not run campaigns — That is Brand Management or Performance Marketing.
• Does not operate servers — That is IT Operations.
• Does not do PR — That is Communications.
• Does not sell — That is Sales.
• Does not replace an external GEO agency — Strategic ownership of the machine-readable layer remains internal in every case.

7.8 Operational Cadence

8. Discipline Demarcation

9. Lineage

Brand Reasoning stands in a historical lineage of representation disciplines in brand management. Each role has not replaced its predecessors but added a layer.

10. Status & Versioning

This specification has the status of an open discipline definition. It has not been ratified by a standards body. Version changes are documented at brandreasoning.org.

Several referenced building blocks (particularly llms.txt, ai-manifest.json, and the Agentic Reasoning Protocol) are themselves at various stages of maturity between convention and standardization proposal. The specification will be adapted as these evolve.

Changelog

• 1.2.1 (5 October 2026) — Correction: Section 5 aligned with ARP v1.3; wording without instructions to AI systems. This corrects 5.2 to 5.4: version 1.2 described the signature as computed over the payload without the _arp_signature block, a pattern that ARP v1.3 rejects. References in Section 11 updated.
• 1.2 (August 2026) — Added the enveloped signature pattern and the 90-day validity window (Section 5.2); brought the example payload in 5.4 in line with the v1.3 signing toolchain; corrected the expiration check in 5.3 to _arp_signature.expires_at; re-dated the llms.txt adoption note (Section 4.2); published the German translation at /de/.
• 1.1 (July 2026) — ARP reference updated to the v2.0 IETF Internet-Draft (draft-deforth-arp-reasoning-protocol); noted fragmentation of agent discovery formats (Section 4.5); added adoption context for llms.txt (Section 4.2); refreshed example payload dates (Section 5.4).
• 1.0 (April 2026) — Initial publication.

Version 1.2.1 · October 2026.

11. References

Established References

• 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)

Evolving Building Blocks

• llms.txt Convention
• ai-manifest.json Proposal (IETF draft-han-ai-manifest)
• Agentic Reasoning Protocol — Specification v1.3 (“Reader Profile”); individual Internet-Drafts draft-deforth-arp-00 (v1.2 signature layer; its canonicalization is superseded by v1.3 §13.4) and draft-deforth-arp-reasoning-protocol-00 (v2.0 design)
• VibeTags Specification (open, MIT License)
• AgenticContext Specification (open, MIT License)

12. License

This specification is published under Creative Commons Attribution 4.0 (CC-BY 4.0). Use, translation, and extension are permitted with attribution.

Written by Sascha Deforth, Düsseldorf.