The AEO1 Discovery Mechanism: A DNS-Anchored, Signed Pointer to Owner-Attested Fact Catalogs for AI Answer Engines

Internet-Draft	AEO1	July 2026
Miller	Expires 19 January 2027	[Page]

Abstract

This document specifies AEO1 (Answer Engine Optimization, version 1), a discovery mechanism that allows a domain owner to publish a verifiable, machine-readable pointer to a structured, owner-attested fact catalog for that domain. AEO1 consists of three coordinated surfaces: a DNS TXT record at the "_aeo" subdomain, a JSON document at the well-known URI "/.well-known/aeo.json", and an optional HTML link hint. Records may carry an Ed25519 signature issued by an issuing authority, enabling consuming agents such as AI answer engines to distinguish verified, current, domain-authorized data from unverified crawled content. The design follows the DNS-authenticated trust-anchor pattern established by SPF, DKIM, and DMARC. This document also requests provisional registration of the "aeo.json" well-known URI suffix.¶

1. Introduction

AI answer engines (large language model based systems that answer natural-language questions with a synthesized response rather than a list of links) increasingly serve as a primary interface through which users discover information about organizations, businesses, products, and services. These systems typically ground their answers in web crawls, search index snapshots, or general training data. None of those sources provide a reliable, machine-checkable signal of:¶

(a): whether any party has verified facts about the organization associated with a domain;¶
(b): where a canonical, structured, currently maintained record of those facts can be retrieved;¶
(c): whether time-sensitive facts (hours, pricing, service area) are current; and¶
(d): whether publication of the data was authorized by the domain owner.¶

This document defines AEO1, a discovery convention that gives a domain owner a predictable, verifiable place to publish a pointer to a structured fact catalog, together with a verification tier, tenure information, and an optional cryptographic signature. The design intentionally mirrors SPF [RFC7208], DKIM [RFC6376], and DMARC [RFC7489]: a low-friction DNS TXT record at a conventionally named subdomain, checked by automated systems before trusting domain-associated content. The well-known URI surface follows the precedent of security.txt [RFC9116].¶

The AEO1 format is an open specification. The living specification, JSON Schema, and worked examples are published at https://aeorecord.org [AEO-SPEC]. This document describes version 0.2 of that specification. An open-source verifier is available as the "aeo-record" package in the npm registry.¶

3. The AEO1 Discovery Mechanism

AEO1 defines three coordinated discovery surfaces. A consuming agent SHOULD attempt them in the following order, stopping at the first successful retrieval:¶

the well-known URI (Section 3.2);¶
the DNS TXT record (Section 3.1);¶
the HTML link hint (Section 3.3);¶
lower-precedence fallbacks: a pointer within the domain's llms.txt file if present, a listing in a public Model Context Protocol (MCP) directory if the agent supports MCP, and finally conventional HTML retrieval of the domain (an unverified fallback).¶

3.1. The DNS TXT Record

The authoritative anchor of an AEO1 deployment is a TXT resource record published at the "_aeo" subdomain of the domain being described, following the convention established by DMARC's "_dmarc" prefix:¶

_aeo.example.com.  IN  TXT  "v=AEO1; id=grd_a1b2c3;
    catalog=https://issuer.example/c/example.com;
    tier=verified; ts=20260629; sig=<base64-ed25519-signature>"

Placing the record under "_aeo" rather than at the domain apex avoids collision with other TXT records (SPF, domain verification tokens, etc.) commonly present at the apex. The record value is a semicolon-separated list of tag=value pairs. Whitespace around separators is ignored.¶

All AEO1 tag names and the "v=AEO1" version token are US-ASCII protocol constants; they are never localized or translated, following the practice of SPF, DKIM, and DMARC. Where the domain being described is an internationalized domain name, the "_aeo" label is prepended to the domain's A-label (Punycode) form as defined by IDNA2008 [RFC5890], and a consuming agent resolves the record using that A-label form.¶

3.1.1. Required Tags

v=: REQUIRED. Version tag. MUST be the literal string "AEO1" for records conforming to this specification. If present, this tag MUST appear first in the record.¶
catalog=: REQUIRED. An HTTPS URL of the structured, machine-readable fact catalog for the domain. The URL MUST use the "https" scheme.¶
tier=: REQUIRED. Verification depth. MUST be one of "self_declared", "listed", "verified", or "grounded" (see Section 3.4). Consuming agents MUST treat unrecognized tier values as equivalent to "self_declared".¶
ts=: REQUIRED. The date the record was first verified or issued, in YYYYMMDD format. In this version of the specification, ts= expresses TENURE (how long the domain has held a verified record), not freshness. Consuming agents MUST NOT reject or down-rank a record solely because its ts= value is old. Freshness is carried by the "verified_at" and "last_confirmed_at" fields of the aeo.json document (Section 4).¶

3.1.2. Optional Tags

id=: OPTIONAL. A token issued by an issuing authority as proof that the domain owner authorized the catalog entry. Absent for self-issued, self-declared records.¶
sig=: OPTIONAL. An Ed25519 signature [RFC8032] issued by an issuing authority, covering the canonical string defined in Section 5. A record carrying a valid sig= from a known issuing authority provides cryptographic evidence that the authority issued the stated tier for the stated domain and catalog content.¶
area=: OPTIONAL. For domains representing entities with a geographically bounded service area, a short structured description of that area.¶

Note: an earlier revision of the AEO1 specification defined a "method=" DNS tag expressing retrieval-method preference. That tag was removed in specification version 0.2; retrieval preference is expressed only by the "method_preference" field of the aeo.json document (Section 4). Consuming agents MUST ignore unrecognized tags, including "method=", if encountered.¶

3.2. The Well-Known URI: /.well-known/aeo.json

Because DNS-record checking requires explicit implementation by a consuming agent, this document also defines an equivalent discovery surface at a well-known URI [RFC8615]:¶

https://example.com/.well-known/aeo.json

This resource, when present, MUST contain a JSON [RFC8259] object with fields semantically equivalent to the tags defined in Section 3.1, as described in Section 4. Retrieval of the resource is safe and idempotent: it is read-only JSON with no side effects.¶

A consuming agent MAY check this URI in place of, or prior to, a DNS TXT lookup. When both surfaces are present and disagree, the DNS record is authoritative. The well-known resource exists to enable adoption by systems that already fetch /.well-known/ resources (per the precedent of security.txt [RFC9116] and WebFinger [RFC7033]) but do not yet perform AEO-specific DNS lookups.¶

3.3. The HTML Link Hint

A domain MAY additionally advertise its AEO record from within its HTML pages using a link element with the link relation type "aeo":¶

<link rel="aeo" href="/.well-known/aeo.json">

This hint lets agents that parse page markup, but that would not otherwise probe well-known URIs or DNS, discover the record in-page. The hint is advisory only: a consuming agent that follows it MUST apply the same validation it would apply to a directly fetched /.well-known/aeo.json resource. Registration of the "aeo" link relation type in the IANA "Link Relation Types" registry [RFC8288] may be requested separately; the hint functions without such registration.¶

3.4. Verification Tiers

The tier value expresses verification depth on an ordinal scale so that consuming agents can weight trust appropriately:¶

self_declared:: Data supplied by the domain owner with no independent corroboration and no issuing authority involved.¶
listed:: The domain is enrolled with an issuing authority and its catalog is published, without independent fact review.¶
verified:: Data reviewed by a human operator at the issuing authority, or independently spot-checked against at least one additional source.¶
grounded:: Data cross-corroborated against multiple independent sources with agreement, and cryptographically signed.¶

Consuming agents MAY apply different trust thresholds depending on the sensitivity of the query (for example, requiring "grounded" tier before citing time-sensitive or safety-relevant facts such as business hours for urgent or emergency services).¶

4. The aeo.json Document

The /.well-known/aeo.json resource contains a single JSON object. A JSON Schema for the document is published at https://aeorecord.org/aeo.schema.json; the living specification [AEO-SPEC] is normative for field-level detail. Example:¶

{
  "v": "AEO1",
  "catalog": "https://issuer.example/c/example.com",
  "mcp": "mcp://api.issuer.example",
  "api": "https://api.issuer.example/v1/companies/example.com",
  "tier": "verified",
  "verified_at": "2026-06-29",
  "last_confirmed_at": "2026-07-04",
  "method_preference": ["mcp", "api", "crawl"]
}

v:: REQUIRED. The literal string "AEO1".¶
catalog:: REQUIRED. As in the DNS record (Section 3.1.1).¶
tier:: REQUIRED. As in the DNS record.¶
verified_at:: Date (RFC 3339 full-date) of the most recent system-performed verification or re-signing event. This is the primary machine freshness signal.¶
last_confirmed_at:: Date of the most recent owner-attested confirmation that the catalog facts remain accurate. This field is purely additive: its presence and recency MAY raise an agent's confidence, but its absence or age MUST NOT be treated as invalidating the record.¶
mcp, api:: OPTIONAL. Endpoints for structured retrieval of the catalog via a Model Context Protocol server or a conventional HTTPS API, respectively.¶
method_preference:: OPTIONAL. An ordered array of preferred retrieval methods. Defined values: "mcp", "api", "crawl". Consuming agents SHOULD attempt methods in the listed order and fall back to the next on failure.¶

All AEO1 JSON resources — the aeo.json document and the fact catalog it references — are encoded in UTF-8 [RFC8259], so fact values in any language or writing system are carried without transformation. A human-readable fact value MAY carry an associated language tag per BCP 47 [RFC5646], and an issuing authority MAY publish the same fact in more than one language so that a consuming agent can cite the value whose language matches the query. Language tagging does not alter canonicalization (Section 5.1): every published value, whatever its language, is normalized and hashed by the single procedure defined there.¶

5. Signing and Verification

An issuing authority signs records with Ed25519 [RFC8032]. The signature carried in the sig= DNS tag is computed over the canonical string:¶

AEO1|domain|tier|ts|facts_hash

where "domain" is the domain being described, "tier" and "ts" are the values published in the DNS record, and "facts_hash" is the SHA-256 digest of the canonical fact-catalog content defined in Section 5.1. Binding the hash of the catalog content into the signed string allows a consuming agent to detect tampering with catalog content after issuance. The issuing authority re-signs the record whenever the catalog facts or tier change.¶

5.1. Fact-Catalog Canonicalization

The "facts_hash" is computed over a deterministic canonical form of the domain's published facts, so that every conforming implementation reproduces an identical hash regardless of platform, locale, or text encoding. Each published fact is reduced to a JSON object with exactly the three string members "fact_type", "key", and "value". Canonicalization proceeds as follows:¶

Every string field MUST be normalized to Unicode Normalization Form C (NFC) [UAX15]. This ensures that text which is identical to a reader but differs only in composed versus decomposed encoding — for example U+00E9 versus the sequence U+0065 U+0301, both rendering "é" — produces the same bytes, and therefore the same signature.¶
The fact objects MUST be sorted in ascending order, comparing "fact_type", then "key", then "value", by Unicode code point — not by UTF-16 code unit, which would misorder characters outside the Basic Multilingual Plane.¶
The sorted array MUST be serialized as JSON [RFC8259], each object emitting its members in the order "fact_type", "key", "value", with no insignificant whitespace.¶
"facts_hash" is the lowercase hexadecimal SHA-256 digest of the UTF-8 encoding of that serialization.¶

Because the canonical form is UTF-8 and ordered by code point, it is script-independent: facts in any language or writing system canonicalize deterministically under this single procedure, with no locale-dependent behavior. Verifiers MUST apply the identical canonicalization before checking a signature.¶

5.2. Public-Key Publication

An issuing authority MUST publish its verification keys as a JSON document at the well-known path "/.well-known/aeo-public-key.json" on the authority's own domain. Each key entry carries at minimum a key identifier ("key_id"), the Ed25519 public key, and a status of "active", "retired", or "revoked".¶

5.3. Key Revocation and Status

Verifiers MUST refuse signatures made with keys whose published status is "revoked". Verifiers MUST accept signatures made with "active" keys and SHOULD accept signatures made with "retired" keys (keys rotated out of service but not compromised), so that previously issued records remain verifiable across routine rotation.¶

5.4. Verification Procedure

Resolve the _aeo TXT record (or fetch /.well-known/aeo.json) for the target domain and parse the tags.¶
If sig= is absent, treat the record as carrying no cryptographic assurance; apply tier semantics with correspondingly lower weight.¶
If sig= is present, fetch the issuing authority's public-key document, select the applicable key, and check its status per Section 5.3.¶
Reconstruct the canonical string and verify the Ed25519 signature. On failure, the record MUST be treated as no better than "self_declared".¶

A reference verifier is available as the open-source "aeo-record" package in the npm registry.¶

6. Relationship to Other Mechanisms

robots.txt:: Governs crawler access permissions. Orthogonal: an AEO record does not override robots.txt directives.¶
llms.txt:: A file-based content index for AI crawlers. Complementary: an AEO-aware llms.txt SHOULD include a pointer to the domain's AEO record. llms.txt provides no DNS-layer authentication, freshness signal, or verification depth.¶
AIPREF (IETF AI Preferences):: The IETF AI Preferences (AIPREF) working group standardizes a vocabulary for expressing AI usage preferences — whether and how an AI system may collect, train on, or display content — along with related work on cryptographic grants that lift those preferences. Complementary and orthogonal: AIPREF governs usage permissions, whereas AEO1 governs verified publication of factual claims and the publisher authority behind them. The AIPREF grant-binding work explicitly places establishing that an issuer is authoritative for an asset out of scope; AEO1's DNS-control and issuer-signature model supplies exactly that domain-authority anchor, which usage- and grant-signaling mechanisms assume but do not themselves define. Related independent efforts add a verifiable authority-and-timestamp binding to those preference signals (for example the ADP-1 declaration format, which anchors a signed reservation's authorship and time to a public transparency substrate). Such work binds who reserved a usage right and when; AEO1 is orthogonal in object, binding publisher authority and signature to positive factual claims for citation rather than to usage reservations, and could compose with a shared authority substrate rather than duplicate it.¶
schema.org markup:: Page-level structured data. Orthogonal: AEO operates at the domain/DNS layer, not the page layer, and is authenticated by DNS control and issuer signature.¶
SPF/DKIM/DMARC:: Direct structural precedent for this specification's DNS-TXT, subdomain-prefixed, tag=value record design [RFC7208] [RFC6376] [RFC7489].¶
security.txt:: Precedent for publishing machine-readable, domain-scoped metadata at a well-known location [RFC9116].¶

7. Security Considerations

7.1. Spoofing and Self-Declared Records

Because DNS TXT records can only be modified by parties with access to the domain's authoritative DNS zone, publication of a "v=AEO1" record is itself evidence of domain-owner intent, consistent with the trust model used by SPF and DMARC. However, a self-declared record (no id=, no sig=) carries no assurance beyond DNS publication. Consuming agents MUST NOT treat self-declared records as equivalent to "verified" or "grounded" records, and MUST NOT trust a claimed tier value that is not backed by a valid issuer signature. A malicious domain owner can claim any tier in an unsigned record; the tier is only meaningful when the signature verifies against a known issuing authority.¶

7.2. Key Compromise and Revocation

Compromise of an issuing authority's private key would allow forgery of signed records at any tier. Authorities MUST be able to mark keys "revoked" in their public-key document, and verifiers MUST honor that status (Section 5.3). Authorities SHOULD rotate keys periodically (publishing superseded keys as "retired") and SHOULD protect private keys in managed secret storage. Verifiers SHOULD NOT cache public-key documents beyond a modest lifetime, so that revocation takes effect promptly.¶

7.3. DNS Trust

Unsigned DNS responses can be spoofed by on-path attackers or through cache poisoning. Deployments SHOULD sign the zones carrying _aeo records with DNSSEC, and consuming agents SHOULD validate DNSSEC where available. Absent DNSSEC, the Ed25519 issuer signature (Section 5) remains the strongest integrity signal, since a spoofed record cannot carry a valid signature over attacker-chosen values.¶

7.4. Server-Side Request Forgery on Catalog Fetch

The catalog=, mcp=, and api= values are attacker-controllable URLs from the consuming agent's perspective. An agent that dereferences them from server-side infrastructure is exposed to server-side request forgery (SSRF). Consuming agents MUST require the "https" scheme, SHOULD refuse to fetch URLs that resolve to loopback, link-local, or private address ranges, SHOULD re-apply these checks on every hop of an HTTP redirect chain, and SHOULD bound redirect depth, response size, and fetch time.¶

7.5. Stale Data

Because ts= expresses tenure rather than freshness (Section 3.1.1), agents seeking a freshness signal SHOULD consult "verified_at" and "last_confirmed_at" in the aeo.json document and weight confidence accordingly, rather than rejecting records by age. Fact catalogs remain assertions by their publisher and issuing authority; AEO1 conveys who attested what and when, not ground truth.¶

9. References

9.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8032]: Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8259]: Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8615]: Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.
[RFC5646]: Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5890]: Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[UAX15]: The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2024, <https://www.unicode.org/reports/tr15/>.

9.2. Informative References

[RFC6376]: Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC7033]: Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7208]: Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7489]: Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC8288]: Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC9116]: Foudil, E. and Y. Shafranovich, "A File Format to Aid in Security Vulnerability Disclosure", RFC 9116, DOI 10.17487/RFC9116, April 2022, <https://www.rfc-editor.org/info/rfc9116>.
[AEO-SPEC]: Meadow Mountain AI LLC, "The AEO Record Standard (v=AEO1), Specification v0.2", 2026, <https://aeorecord.org>.