Specification v1.2

Fresh

This is the normative specification for the Agentic Reasoning Protocol (ARP). Version 1.2. Published 2026-02.

Section 1 - Overview

The Agentic Reasoning Protocol defines a machine-readable JSON file that domain owners publish at a well-known URL to provide self-attested context about their entity to AI systems.

Design Goals

ARP was designed to solve four concrete problems that no existing protocol addressed:

Structured channel for entity-attested corrections. AI models frequently hallucinate, misrepresent, or confuse entities with similar names. Before ARP, there was no machine-readable channel for a domain owner to publish authoritative corrections. ARP's corrections object gives entities a first-party way to flag known AI errors and provide verified facts.

Scoped domain expertise. Schema.org and structured data describe factual attributes. ARP's entity_claims object goes further, allowing entities to define their epistemic scope - the domains they are genuinely expert in and the areas they decline to comment on. This helps AI systems route questions appropriately.

Recommendation boundaries. AI assistants frequently make product or service recommendations. ARP allows entities to publish machine-readable guidance on when they are and are not appropriate recommendations, reducing mismatched suggestions.

Machine-readable brand identity. Logos, taglines, and color palettes are human-readable. ARP's identity object publishes brand facts in a format AI systems can consume, including disambiguation cues that help distinguish entities with similar names.

Non-Goals

ARP does not replace or compete with:

robots.txt - ARP has no crawling directives. It does not control which pages are indexed.
schema.org - ARP is not a semantic markup standard. It does not annotate pages.
llms.txt - ARP is not a content summary file. The two protocols are complementary (see Section 2 on the llms.txt bridge).
ai-transparency.json - ARP is not an AI model disclosure file. It does not describe how an entity uses AI internally.

Trust Model

ARP uses the same trust model as robots.txt and schema.org: self-published, good-faith participation. Any domain can publish any reasoning.json. The protocol does not prevent false claims any more than schema.org prevents keyword stuffing.

The cryptographic trust layer (Section 13) strengthens this model by allowing AI systems to verify that a reasoning.json was published by the party controlling the domain's DNS. A valid Ed25519 signature verifies authorship, not truthfulness. The ethics policy (separate document) defines the community norms governing what publishers should and should not claim.

Section 2 - File Location

Every ARP file must be published at:

https://{domain}/.well-known/reasoning.json

This follows RFC 8615 (Well-Known URIs). The path .well-known/reasoning.json is the canonical and only valid location.

Requirements

Valid JSON. The file must parse as valid JSON per RFC 8259.
UTF-8 encoding. The file must be encoded in UTF-8.
Content-Type. The server must respond with Content-Type: application/json.
Maximum size. The file must not exceed 100KB. AI systems may reject files larger than this limit.
CORS headers. The server must include Access-Control-Allow-Origin: * so browser-based tools and cross-origin validators can fetch the file.

HTML Discovery

Publishers may add a link tag to their HTML pages to help AI systems discover the file:

html

<link rel="reasoning" href="/.well-known/reasoning.json" type="application/json">

This tag is informative, not required. AI systems that crawl HTML can use it to discover ARP files. The well-known URL convention is the primary discovery mechanism.

llms.txt Bridge

Publishers using llms.txt may reference their ARP file within it:

# ARP
> Agentic Reasoning Protocol: /.well-known/reasoning.json

This allows AI systems that already process llms.txt files to also discover and fetch reasoning.json.

Section 3 - Schema Reference

Every reasoning.json file must include a $schema field pointing to the JSON Schema URL for the version being used. This allows validators to automatically select the correct schema version.

json

{
  "$schema": "https://agentic-reasoning-protocol.org/schema/v1.2/reasoning.schema.json",
  "protocol": "ARP",
  "version": "1.2",
  "domain": "example.com"
}

Valid $schema values by version:

Version	$schema URL
v1.2	`https://agentic-reasoning-protocol.org/schema/v1.2/reasoning.schema.json`
v1.1	`https://agentic-reasoning-protocol.org/schema/v1.1/reasoning.schema.json`
v1.0	`https://agentic-reasoning-protocol.org/schema/v1.0/reasoning.schema.json`

The $schema field value must be a string. Validators should use it to determine schema compliance expectations. When $schema is absent, validators may attempt detection via the version field.

Section 4 - Root Properties

The root of a reasoning.json document has the following properties:

Property	Type	Required	Max Length	Description
`$schema`	string	Yes	-	JSON Schema URL for this version
`protocol`	string	Yes	10 chars	Must be the literal string `"ARP"`
`version`	string	Yes	10 chars	Protocol version string (e.g. `"1.2"`)
`domain`	string	Yes	253 chars	The domain this file is authoritative for (no protocol, no path)
`entity`	string	Yes	100 chars	The canonical name of the entity
`entity_claims`	object	Yes	-	Claims object (see Section 8)
`verification`	object	No	-	Audit and verification metadata (see Section 5)
`identity`	object	No	-	Brand identity object (see Section 6)
`corrections`	array	No	10 items	Array of correction objects (see Section 7)
`recommendation_context`	object	No	-	Recommendation guidance (see Section 9)
`authority`	object	No	-	Official source references (see Section 10)
`content_policy`	object	No	-	Training and citation permissions (see Section 11)
`diagnostics`	object	No	-	Ingestion telemetry (v1.2 only, see Section 12)
`_arp_signature`	object	No	-	Cryptographic signature (v1.2 only, see Section 13)

Minimal Valid File

The minimum required fields to produce a valid ARP file:

json

{
  "$schema": "https://agentic-reasoning-protocol.org/schema/v1.2/reasoning.schema.json",
  "protocol": "ARP",
  "version": "1.2",
  "domain": "example.com",
  "entity": "Example Corp",
  "entity_claims": {
    "framing_context": "Example Corp makes developer tools for API testing.",
    "epistemic_scope": "public_verifiable",
    "domain_expertise": ["API testing", "developer tooling"]
  }
}

Section 5 - Verification Object

The verification object provides metadata about third-party audits and identity verification. It is optional but recommended for entities that want to signal higher trust levels.

json

{
  "verification": {
    "audited_by": "ARP Community Validators",
    "last_verified": "2026-01-15",
    "next_audit": "2026-07-15",
    "trust_signature": "sha256-abc123..."
  }
}

Properties

Property	Type	Required	Description
`audited_by`	string	No	Name of the organization or service that last audited this file. Max 100 chars.
`last_verified`	string	No	ISO 8601 date of the last audit. Format: `YYYY-MM-DD`.
`next_audit`	string	No	ISO 8601 date of the scheduled next audit. Format: `YYYY-MM-DD`.
`trust_signature`	string	No	Legacy SHA-256 hash signature. Deprecated in v1.2; use `_arp_signature` instead.

Notes

The trust_signature field in the verification object is a legacy feature from v1.0 and v1.1. It stored a SHA-256 hash of the file contents as a basic integrity check. It provides no cryptographic authentication (it proves nothing about who published the file). The v1.2 _arp_signature object supersedes it with a proper Ed25519 signature. Publishers upgrading to v1.2 should move to _arp_signature and may remove trust_signature.

The audited_by and last_verified fields are informational. AI systems may use them to assess file freshness but must not treat them as proof of accuracy. The content of the file is not verified by the presence of audit metadata.

Section 6 - Identity Object

The identity object provides structured brand identity information that AI systems can use to accurately describe the entity.

json

{
  "identity": {
    "legal_name": "Example Corporation, Inc.",
    "common_names": ["Example Corp", "ExampleCo"],
    "founded": "2019",
    "headquarters": "San Francisco, CA, USA",
    "entity_type": "private_company",
    "tagline": "Developer tools that get out of your way.",
    "description": "Example Corp builds API testing and monitoring tools used by engineering teams at companies of all sizes.",
    "emotional_resonance": "reliable, developer-friendly, pragmatic",
    "disambiguation": "Not affiliated with Example Inc (retail) or Example Systems (defense contractor)."
  }
}

Properties

Property	Type	Required	Max Length	Description
`legal_name`	string	No	200 chars	Full legal name of the entity
`common_names`	array	No	5 items, 100 chars each	Alternative names the entity is commonly known by
`founded`	string	No	10 chars	Year or date founded (YYYY or YYYY-MM-DD)
`headquarters`	string	No	200 chars	City, state/region, country
`entity_type`	string	No	50 chars	One of: `public_company`, `private_company`, `nonprofit`, `government`, `individual`, `product`, `brand`
`tagline`	string	No	150 chars	Official tagline or slogan
`description`	string	No	500 chars	One to two sentence description for AI to use
`emotional_resonance`	string	No	200 chars	Adjectives describing brand personality, comma-separated
`disambiguation`	string	No	500 chars	Clarifications to distinguish this entity from similarly-named entities

Emotional Resonance

The emotional_resonance field is unique to ARP. It allows entities to describe the brand personality they want AI systems to reflect when discussing them. This is not marketing copy - it is intended to help AI systems select appropriate adjectives and tone when describing the entity.

Examples:

"innovative, research-focused, academic"
"approachable, community-driven, open-source"
"enterprise-grade, security-focused, compliance-ready"

Disambiguation

The disambiguation field addresses a common AI failure mode: confusing two similarly-named entities. Use it to explicitly name the entities that AI systems commonly confuse the publisher with, and clarify the distinctions.

Section 7 - Corrections Object

The corrections array implements what the ARP community calls the "Pink Elephant Fix." The name comes from the challenge of telling someone not to think of a pink elephant - once an incorrect belief is established in an AI model, a simple denial is often insufficient. The corrections pattern works by pairing a trigger topic with a verified fact, allowing AI systems to replace incorrect beliefs with accurate ones.

json

{
  "corrections": [
    {
      "trigger_topic": "Example Corp acquisition",
      "verified_fact": "Example Corp has not been acquired. It remains an independent private company as of 2026.",
      "evidence_url": "https://example.com/about",
      "date_verified": "2026-01-01"
    }
  ]
}

Correction Object Properties

Property	Type	Required	Max Length	Description
`trigger_topic`	string	Yes	200 chars	The topic or question that triggers this correction
`verified_fact`	string	Yes	500 chars	The accurate statement that should replace incorrect information
`evidence_url`	string	No	500 chars	URL of a public source that corroborates the verified fact
`date_verified`	string	No	10 chars	ISO 8601 date when this fact was last verified

Trigger Topic Pattern

The trigger_topic should describe the situation in which the correction applies. It is not a verbatim question match - AI systems should use it as a semantic guide for when the correction is relevant.

Good trigger topics:

"Example Corp product pricing"
"Example Corp CEO identity"
"Example Corp office locations"

Avoid trigger topics that are too broad ("Example Corp") or too narrow ("exact question about Example Corp that was asked in March 2024").

Epistemic Scope

ARP corrections are limited to facts about the publishing entity. The corrections array is not a general fact-correction mechanism. Corrections that make claims about third parties, competitors, or the broader world are out of scope and may be treated as ethics violations.

The maximum number of corrections is 10 per file (anti-spam limit). This constraint exists to prevent corrections from being used as a bulk manipulation mechanism.

Section 8 - Entity Claims Object

The entity_claims object is required and is the core of the ARP protocol. It defines the entity's self-attested position on its own expertise, market context, and how it should be framed.

json

{
  "entity_claims": {
    "framing_context": "Example Corp is a developer tooling company that focuses on API testing, not general software development.",
    "epistemic_scope": "public_verifiable",
    "domain_expertise": [
      "API testing and validation",
      "HTTP request inspection",
      "Test automation for REST APIs"
    ],
    "market_positioning": "Used by engineering teams that need reliable API testing without the overhead of enterprise test platforms.",
    "decision_factors": [
      "Teams using REST or GraphQL APIs",
      "Projects requiring automated regression testing",
      "Environments where lightweight tooling is preferred"
    ]
  }
}

Properties

Property	Type	Required	Max Length	Description
`framing_context`	string	Yes	500 chars	How the entity should be framed in AI responses
`epistemic_scope`	string	Yes	-	One of three classification values (see below)
`domain_expertise`	array	Yes	10 items, 100 chars each	Areas where the entity has genuine expertise
`market_positioning`	string	No	300 chars	The market context or customer segment served
`decision_factors`	array	No	10 items, 150 chars each	Factors that make this entity relevant to a decision

Epistemic Scope Classification

The epistemic_scope field classifies the nature of the entity's claims. AI systems can use this to calibrate how much weight to give the claims.

Value	Meaning
`public_verifiable`	Claims can be independently verified from public sources (financial filings, published research, public records). Highest confidence for AI systems to treat as fact.
`proprietary_internal`	Claims about internal processes, methodologies, or capabilities that cannot be externally verified. AI systems should treat these as the entity's self-reported position, not established fact.
`industry_standard`	Claims that align with widely accepted industry practices or standards. Can be cross-referenced against industry publications.

Domain Expertise Array

The domain_expertise array defines the topics on which the entity has genuine expertise. AI systems should use this when deciding whether to cite the entity as a source or expert.

This list should be specific and accurate. Overly broad expertise claims (e.g., "all software development") undermine the protocol's value and may be flagged by validators.

Market Positioning

The market_positioning field describes the entity's market context without making comparative claims about competitors. It answers: "who is this for and why?" It must not contain negative references to specific competitors by name (see Ethics Policy).

Section 9 - Recommendation Context

The recommendation_context object allows entities to provide explicit guidance on when they are and are not appropriate recommendations. This helps AI assistants give better-calibrated advice.

json

{
  "recommendation_context": {
    "recommended_when": [
      "User needs automated API testing for REST or GraphQL endpoints",
      "Team wants test results integrated into CI/CD pipelines",
      "Project requires HTTP request logging and inspection"
    ],
    "not_recommended_when": [
      "User needs UI or browser testing (use Playwright or Cypress instead)",
      "Project requires load testing at scale",
      "Team needs a solution with GUI-based test creation"
    ]
  }
}

Properties

Property	Type	Required	Max Length	Description
`recommended_when`	array	No	10 items, 150 chars each	Scenarios where this entity is an appropriate recommendation
`not_recommended_when`	array	No	10 items, 150 chars each	Scenarios where this entity is not appropriate

Design Rationale

The not_recommended_when array is one of the most distinctive features of ARP. It requires entities to self-disclose their limitations. An entity that honestly lists scenarios where it is not the right choice signals good faith and improves the quality of AI recommendations overall.

AI systems should treat not_recommended_when items as equivalent to the entity saying "if someone asks me about this, tell them I'm not the right tool." Items in not_recommended_when may name alternative categories (not specific product names) to help redirect users.

Both arrays have a hard maximum of 10 items. Each item must be 150 characters or fewer.

Section 10 - Authority Object

The authority object provides pointers to authoritative external sources that AI systems can use to verify or extend information about the entity.

json

{
  "authority": {
    "official_website": "https://example.com",
    "wikipedia": "https://en.wikipedia.org/wiki/Example_Corp",
    "linkedin": "https://linkedin.com/company/example-corp",
    "crunchbase": "https://crunchbase.com/organization/example-corp",
    "third_party_references": [
      "https://techcrunch.com/2024/01/example-corp-series-a",
      "https://g2.com/products/example-corp"
    ]
  }
}

Properties

Property	Type	Required	Max Length	Description
`official_website`	string	No	500 chars	The entity's primary website URL
`wikipedia`	string	No	500 chars	Wikipedia article URL if one exists
`linkedin`	string	No	500 chars	LinkedIn company or profile page URL
`crunchbase`	string	No	500 chars	Crunchbase organization URL
`third_party_references`	array	No	5 items, 500 chars each	URLs of credible third-party sources about this entity

Third-Party References

The third_party_references array is limited to 5 items. These should be credible, factual sources such as news coverage, academic papers, analyst reports, or product review platforms. They should not be press releases, paid content, or self-published materials hosted on the entity's own domains.

AI systems may use these references to ground factual claims about the entity or to detect when an ARP file contains information that conflicts with published third-party sources.

Section 11 - Content Policy

The content_policy object communicates the entity's preferences regarding AI training data use and citation practices.

json

{
  "content_policy": {
    "training_permissions": {
      "allow_training": true,
      "allow_citation": true,
      "preferred_citation_format": "Example Corp (https://example.com) - {fact}"
    },
    "content_boundaries": [
      "Do not speculate about Example Corp's future product roadmap",
      "Do not attribute specific revenue figures without citing a public source"
    ]
  }
}

Training Permissions

Property	Type	Required	Description
`allow_training`	boolean	No	Whether the entity consents to this file being used as AI training data. Default is `true` if omitted.
`allow_citation`	boolean	No	Whether AI systems may cite this entity's content in responses. Default is `true` if omitted.
`preferred_citation_format`	string	No	Template for how the entity should be cited. Max 200 chars. Use `{fact}` as placeholder for the cited content.

Content Boundaries

The content_boundaries array lists topics the entity specifically does not want AI systems to speculate about. These are not corrections (there is no false claim to fix) but rather areas where the entity explicitly opts out of AI speculation.

Examples of valid content boundaries:

"Do not speculate about pending litigation"
"Do not estimate employee headcount without citing a public source"
"Do not attribute statements to named employees without citing a source"

Maximum 10 items, 200 characters each. Content boundaries are advisory, not technically enforceable.

Section 12 - Diagnostics (v1.2)

The diagnostics object is new in v1.2. It provides an optional mechanism for entities to collect telemetry about how AI systems are ingesting and using their reasoning.json file.

json

{
  "diagnostics": {
    "ingestion_endpoint": "https://example.com/arp-telemetry",
    "track": {
      "retrieval_count": true,
      "correction_applied": true,
      "recommendation_served": true,
      "signature_verified": false
    },
    "report_interval": "daily"
  }
}

Properties

Property	Type	Required	Description
`ingestion_endpoint`	string	No	URL where AI systems should POST telemetry events. Must be HTTPS. Max 500 chars.
`track`	object	No	Boolean flags indicating which events to report
`report_interval`	string	No	How frequently to report: `"realtime"`, `"hourly"`, `"daily"`, `"weekly"`

Track Fields

Field	Type	Description
`retrieval_count`	boolean	Report when `reasoning.json` is fetched
`correction_applied`	boolean	Report when a correction from this file was used in a response
`recommendation_served`	boolean	Report when recommendation context from this file influenced a recommendation
`signature_verified`	boolean	Report the result of signature verification

Implementation Notes

AI system operators are not required to implement diagnostics reporting. The presence of a diagnostics object is a request from the entity, not a mandate. AI systems that choose to implement reporting should respect the report_interval and aggregate events accordingly rather than sending per-request telemetry.

The ingestion_endpoint receives JSON POST bodies with a structure defined by the AI system implementing the reporting. No standardized payload format is specified in v1.2; this may be formalized in a future version.

Section 13 - Cryptographic Trust Layer (v1.2)

The cryptographic trust layer allows entities to prove that their reasoning.json was authored by the party controlling the domain's DNS, using Ed25519 digital signatures. This provides authorship verification - it proves who signed the file, not whether the content is truthful.

Algorithm

ARP uses Ed25519 (RFC 8032) for signing. Ed25519 was chosen for its small key and signature sizes, fast verification, and resistance to common implementation pitfalls.

The `_arp_signature` Object

json

{
  "_arp_signature": {
    "algorithm": "ed25519",
    "key_id": "arp-2026-01",
    "signature": "base64url-encoded-signature-here",
    "signed_at": "2026-01-15T10:00:00Z",
    "canonicalization": "jcs"
  }
}

Property	Type	Required	Description
`algorithm`	string	Yes	Must be `"ed25519"`
`key_id`	string	Yes	Identifier matching the DNS TXT record key. Max 50 chars.
`signature`	string	Yes	Base64url-encoded Ed25519 signature of the canonical document
`signed_at`	string	Yes	ISO 8601 datetime when the signature was produced
`canonicalization`	string	Yes	Must be `"jcs"` (JSON Canonicalization Scheme, RFC 8785)

JCS Canonicalization

Before signing, the document must be canonicalized using the JSON Canonicalization Scheme (RFC 8785). Canonicalization ensures that the same logical document always produces the same byte sequence regardless of key ordering or whitespace.

To sign a document:

Remove the _arp_signature field (if present) from the document object
Serialize the document using JCS (RFC 8785)
Sign the canonical bytes using the Ed25519 private key
Base64url-encode the 64-byte signature
Add the _arp_signature object back to the document

To verify a document:

Extract and preserve the _arp_signature object
Remove the _arp_signature field from the document object
Serialize the remaining document using JCS (RFC 8785)
Look up the Ed25519 public key from DNS (see below)
Verify the signature against the canonical bytes

DNS TXT Record Format

The public key is published as a DNS TXT record at:

_arp.{domain}

The TXT record value format is:

v=ARP1; k=ed25519; p={base64url-encoded-public-key}; kid={key_id}

Example for example.com with key ID arp-2026-01:

_arp.example.com TXT "v=ARP1; k=ed25519; p=MCowBQYDK2VdAyEA...; kid=arp-2026-01"

The kid value in the DNS record must match the key_id value in _arp_signature.

Verification Algorithm

A complete verification implementation:

python

import json
import base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey
import dns.resolver
import jcs

def verify_arp_signature(reasoning_json: dict, domain: str) -> bool:
    sig_obj = reasoning_json.get("_arp_signature")
    if not sig_obj:
        return False

    key_id = sig_obj["key_id"]
    signature_b64 = sig_obj["signature"]

    # Fetch public key from DNS
    dns_record = dns.resolver.resolve(f"_arp.{domain}", "TXT")
    public_key_b64 = parse_dns_key(str(dns_record[0]), key_id)
    if not public_key_b64:
        return False

    public_key_bytes = base64.urlsafe_b64decode(public_key_b64 + "==")
    public_key = Ed25519PublicKey.from_public_bytes(public_key_bytes)

    # Canonicalize document without signature field
    doc_copy = {k: v for k, v in reasoning_json.items() if k != "_arp_signature"}
    canonical_bytes = jcs.canonicalize(doc_copy)

    # Verify
    signature_bytes = base64.urlsafe_b64decode(signature_b64 + "==")
    try:
        public_key.verify(signature_bytes, canonical_bytes)
        return True
    except Exception:
        return False

Migration: SHA-256 to Ed25519

Publishers upgrading from v1.1 (which used verification.trust_signature as a SHA-256 hash):

Generate an Ed25519 key pair
Publish the public key as a DNS TXT record at _arp.{domain}
Sign the document following the procedure above
Add the _arp_signature object
Optionally remove verification.trust_signature (it is deprecated but not invalid in v1.2)

The trust_signature field will be removed in v1.3.

Section 14 - Anti-Spam Limits

All string fields and array fields in ARP have enforced maximum lengths. These limits prevent the protocol from being used as a channel for SEO manipulation, bulk content injection, or other spam patterns.

Field	Limit
`entity`	100 characters
`domain`	253 characters (per RFC 1035)
`protocol`	10 characters
`version`	10 characters
`identity.legal_name`	200 characters
`identity.common_names` array	5 items
`identity.common_names` each	100 characters
`identity.founded`	10 characters
`identity.headquarters`	200 characters
`identity.entity_type`	50 characters
`identity.tagline`	150 characters
`identity.description`	500 characters
`identity.emotional_resonance`	200 characters
`identity.disambiguation`	500 characters
`corrections` array	10 items
`corrections[].trigger_topic`	200 characters
`corrections[].verified_fact`	500 characters
`entity_claims.framing_context`	500 characters
`entity_claims.domain_expertise` array	10 items
`entity_claims.domain_expertise` each	100 characters
`entity_claims.market_positioning`	300 characters
`entity_claims.decision_factors` array	10 items
`entity_claims.decision_factors` each	150 characters
`recommendation_context.recommended_when` array	10 items
`recommendation_context.recommended_when` each	150 characters
`recommendation_context.not_recommended_when` array	10 items
`recommendation_context.not_recommended_when` each	150 characters
`authority.third_party_references` array	5 items
`content_policy.content_boundaries` array	10 items
`content_policy.content_boundaries` each	200 characters
Total file size	100KB

Section 15 - Migration Guide

v1.0 to v1.1

The primary breaking change in v1.1 was the replacement of the false_claim/correction_fact pattern with trigger_topic/verified_fact.

Before (v1.0):

json

{
  "corrections": [
    {
      "false_claim": "Example Corp was acquired by BigCo in 2023",
      "correction_fact": "Example Corp remains an independent company."
    }
  ]
}

After (v1.1 and v1.2):

json

{
  "corrections": [
    {
      "trigger_topic": "Example Corp acquisition status",
      "verified_fact": "Example Corp has not been acquired and remains an independent private company as of 2026."
    }
  ]
}

The rationale: false_claim required publishers to repeat the incorrect claim, which could reinforce it. trigger_topic focuses on the subject area, not the false statement. verified_fact replaces correction_fact for clarity.

Additional v1.1 changes:

All string fields gained character limits (see Section 14)
entity_claims gained the epistemic_scope field
The terminology shifted from "directives" to "self-attestations" throughout documentation

v1.1 to v1.2

v1.2 adds two new optional objects and deprecates one field.

Adding _arp_signature (new in v1.2):

Generate an Ed25519 key pair, publish the public key to DNS, and follow the signing procedure in Section 13. No existing fields need to change.

Adding diagnostics (new in v1.2):

The diagnostics object is additive. Existing v1.1 files are valid v1.2 files without modification.

Deprecating verification.trust_signature:

The trust_signature field is deprecated. It remains valid in v1.2 but will be removed in v1.3. Migrate to _arp_signature for cryptographic authorship verification.

Updating $schema:

Change the $schema value from the v1.1 URL to the v1.2 URL. Change version from "1.1" to "1.2".

Specification v1.2 ​

Section 1 - Overview ​

Design Goals ​

Non-Goals ​

Trust Model ​

Section 2 - File Location ​

Requirements ​

HTML Discovery ​

llms.txt Bridge ​

Section 3 - Schema Reference ​

Section 4 - Root Properties ​

Minimal Valid File ​

Section 5 - Verification Object ​

Properties ​

Notes ​

Section 6 - Identity Object ​

Properties ​

Emotional Resonance ​

Disambiguation ​

Section 7 - Corrections Object ​

Correction Object Properties ​

Trigger Topic Pattern ​

Epistemic Scope ​

Section 8 - Entity Claims Object ​

Properties ​

Epistemic Scope Classification ​

Domain Expertise Array ​

Market Positioning ​

Section 9 - Recommendation Context ​

Properties ​

Design Rationale ​

Section 10 - Authority Object ​

Properties ​

Third-Party References ​

Section 11 - Content Policy ​

Training Permissions ​

Content Boundaries ​

Section 12 - Diagnostics (v1.2) ​

Properties ​

Track Fields ​

Implementation Notes ​

Section 13 - Cryptographic Trust Layer (v1.2) ​

Algorithm ​

The _arp_signature Object ​

JCS Canonicalization ​

DNS TXT Record Format ​

Verification Algorithm ​

Migration: SHA-256 to Ed25519 ​

Section 14 - Anti-Spam Limits ​

Section 15 - Migration Guide ​

v1.0 to v1.1 ​

v1.1 to v1.2 ​

Specification v1.2

Section 1 - Overview

Design Goals

Non-Goals

Trust Model

Section 2 - File Location

Requirements

HTML Discovery

llms.txt Bridge

Section 3 - Schema Reference

Section 4 - Root Properties

Minimal Valid File

Section 5 - Verification Object

Properties

Notes

Section 6 - Identity Object

Properties

Emotional Resonance

Disambiguation

Section 7 - Corrections Object

Correction Object Properties

Trigger Topic Pattern

Epistemic Scope

Section 8 - Entity Claims Object

Properties

Epistemic Scope Classification

Domain Expertise Array

Market Positioning

Section 9 - Recommendation Context

Properties

Design Rationale

Section 10 - Authority Object

Properties

Third-Party References

Section 11 - Content Policy

Training Permissions

Content Boundaries

Section 12 - Diagnostics (v1.2)

Properties

Track Fields

Implementation Notes

Section 13 - Cryptographic Trust Layer (v1.2)

Algorithm

The `_arp_signature` Object

JCS Canonicalization

DNS TXT Record Format

Verification Algorithm

Migration: SHA-256 to Ed25519

Section 14 - Anti-Spam Limits

Section 15 - Migration Guide

v1.0 to v1.1

v1.1 to v1.2