This specification is published and recommended for implementation. Backwards-compatible additions may occur in MINOR versions; breaking changes only in MAJOR versions, with deprecation notice. See specification conventions for status definitions.
Interoperability Guide
Conflict resolution and precedence rules for AI Discovery Files
When multiple AI Discovery Files contain conflicting information, this guide defines which file takes precedence. These rules ensure consistent interpretation and help implementers maintain file coherence.
§1 Core Principles
Three principles guide conflict resolution for AI Discovery Files:
- Structured data takes precedence over unstructured. JSON files are authoritative over their text equivalents because they can be parsed unambiguously.
- Specific files take precedence over general files. A file dedicated to a single purpose (e.g.,
brand.txtfor naming) is authoritative for that purpose. - Access control takes precedence over usage permissions. If a file cannot be accessed, any permissions declared for it are moot.
Conflicts SHOULD be rare. If you find yourself frequently resolving conflicts, your files likely contain redundant or contradictory information that SHOULD be reconciled at the source.
§2 File Hierarchy
The 10 AI Discovery Files are organised into functional tiers. Within each tier, files serve complementary rather than competing purposes.
Tier 1: Access Control
These files control whether AI systems can access content at all.
robots.txt
>
robots-ai.txt
Tier 2: Structured Identity
These files are authoritative for factual identity data.
identity.json
>
ai.json
Tier 3: Human-Readable Context
These files provide context in human-readable formats.
llms.txt
>
ai.txt
>
llm.txt
>
llms.html
Tier 4: Supporting Files
These files provide supplementary information.
brand.txt
>
faq-ai.txt
>
developer-ai.txt
§3 Precedence Matrix
When information conflicts between files, use this matrix to determine which source is authoritative:
| Information Type | 1st (Highest) | 2nd | 3rd | External |
|---|---|---|---|---|
| Business Name | identity.json |
llms.txt |
brand.txt |
Schema.org |
| Alternate Names | identity.json |
brand.txt |
llms.txt |
Schema.org |
| AI Permissions | ai.json |
ai.txt |
— | — |
| Crawler Access | robots.txt |
robots-ai.txt |
— | — |
| Service Descriptions | llms.txt |
faq-ai.txt |
identity.json |
Schema.org |
| Contact Information | identity.json |
llms.txt |
ai.json |
Schema.org |
| Naming Conventions | brand.txt |
identity.json |
— | — |
For "Business Name": if identity.json exists, its name property is authoritative. If not, fall back to the H1 heading in llms.txt, then to brand.txt official names.
§4 Common Conflict Scenarios
Scenario 1: Name Mismatch
When
llms.txt H1: # Acme Corp
brand.txt: official-names: Acme Corporation
Resolution: identity.json name is canonical. Update llms.txt H1 to match, OR add "Acme Corp" to identity.json alternateNames array if it's a valid trading name.
Scenario 2: Permission Conflict
When
ai.json: { "summarisation": "prohibited" }
Resolution: ai.json is authoritative for machine parsing. Update ai.txt to match. Both files SHOULD contain equivalent information.
Scenario 3: Access vs Usage Conflict
When
ai.txt: May summarise content from /insights/
Resolution: robots.txt controls access. If content is blocked, AI cannot reach it—the ai.txt permission is moot. Either update robots.txt to allow access, or remove the permission from ai.txt.
Scenario 4: llm.txt vs llms.txt
When
Resolution: llms.txt is canonical. The llm.txt file SHOULD be a 301 redirect to llms.txt, not a separate file with different content.
Scenario 5: FAQ Answer Contradicts Service Description
When
faq-ai.txt: Q: Do you build websites? A: No, we focus on consulting only.
Resolution: llms.txt is authoritative for service scope. Update the FAQ answer to align with the services section, or update llms.txt if the FAQ reflects the actual truth.
§5 External Standards
AI Discovery Files MUST align with external standards already on your website.
robots.txt
robots.txt is an external standard that always takes precedence for access control. AI Discovery Files cannot override it.
robots-ai.txtprovides supplementary AI-specific rules but cannot allow whatrobots.txtblocks- If
robots.txtblocks a crawler,robots-ai.txtrules for that crawler are ignored
Schema.org Structured Data
When your website already has Schema.org Organization markup, it SHOULD align with identity.json:
identity.jsonis the source of truth for AI Discovery Files- Schema.org markup SHOULD be generated from or match
identity.json - If conflicts exist, update Schema.org markup to match
identity.json
Generate your Schema.org Organization markup from the same source data as identity.json to ensure consistency.
HTTP Headers
Some sites use HTTP headers (e.g., X-Robots-Tag) for crawler control:
- HTTP headers take precedence over file-based rules
- If headers block access, file contents are moot
§6 Consistency Checklist
Before publishing AI Discovery Files, verify consistency:
- Business name is identical in
identity.json,llms.txtH1, andbrand.txt - All names in
brand.txtofficial-names appear inidentity.jsonalternateNames (or as the primary name) ai.txtandai.jsoncontain equivalent permissionsllm.txtredirects tollms.txt(not separate content)llms.htmlcontent matchesllms.txt- Contact information is consistent across all files
- Service descriptions in
faq-ai.txtalign withllms.txtservices section robots.txtdoes not block files thatai.txtreferences- Schema.org Organization markup matches
identity.json
Version History
Phase 6 standardisation release. Added /specifications/roadmap/ (theme-pegged forward plan with Active/Next/Future/On hold status flags), /specifications/extensions/ (rules for experimental x- prefixed files and the promotion path), and /specifications/i18n-a11y/ (multi-language publication, locale-tagged identity fields, RTL handling, accessibility of llms.html). Added the Discovery: directive to the robots-ai.txt specification (publishers MAY advertise AI Discovery Files on the same host). Added a formal media-type stance to the HTTP behaviour page (existing IANA types, no bespoke registrations). Expanded the file integrity and signing section on the security and privacy page with four candidate mechanisms, cross-cutting concerns, and interim publisher / consumer guidance. The Discovery: directive is the only normative addition to publisher behaviour; all other additions are forward-looking documentation.
Phase 5 standardisation release. Added /specifications/related-standards/ (positioning vs llmstxt.org, IETF AI Preferences, robots.txt, Schema.org, BCP 14, JSON Schema 2020-12, SemVer) and /specifications/implementations/ (public record of conformant implementations, IETF-style). Added an explicit llmstxt.org backward-compatibility statement to the llms.txt specification. Added a formal multi-domain and subdomain scoping rule to both the llms.txt and identity.json specifications (host-scoped files, cross-host identity asserted via sameAs). No normative requirements changed for existing publishers; the new scoping rules formalise behaviour the specification already implied.
Phase 4 standardisation release. Added /specifications/processing-model/ (seven-stage algorithm for conformant consumers), /specifications/consumer-guidance/ (what AI systems should do with AI Discovery Files), /specifications/test-vectors/ (canonical test suite framing), and reference-implementation framing on the AI Visibility Checker. No normative requirements changed.
Phase 3 standardisation release. Added /specifications/versioning/ (Semantic Versioning 2.0.0 commitments, deprecation timeline, lifecycle), /specifications/governance/ (proposal lifecycle, editorial process, working principles), /specifications/security-privacy/ (trust model, content-injection patterns, GDPR considerations, integrity primitives roadmap), and /specifications/http-behaviour/ (status codes, redirects, soft-404 detection, caching, rate limits). No normative requirements changed.
Phase 2 standardisation release. Added formal conformance specification (Essential / Recommended / Complete classes). Published machine-readable registry at /specifications/registry.json, spec meta-schema, and validator-output schema. Introduced versioned JSON Schema URLs (/v1/) alongside unversioned 'latest' aliases. Added optional BCP 47 language declaration field across all applicable AI Discovery Files. No normative requirements changed.
Phase 1 standardisation release. Added 'Status of This Document' block (Stable). Normalised normative requirement keywords to uppercase per RFC 2119 and RFC 8174. Added References section linking to /specifications/conventions/ and /licensing/. No normative requirements changed.
Added AI Visibility Directory registration guidance. Minor documentation update.
Initial publication. Establishes precedence hierarchy and conflict resolution rules for all 10 AI Discovery Files.
References
- Specification Conventions — RFC 2119 + RFC 8174 requirement keywords, document statuses, anchor naming, versioning, and language conventions used across every AI Discovery File specification.
- Licensing & Trademark — CC BY 4.0 for specification text and examples, MIT for JSON Schemas, and the free-use policy on the name "AI Discovery Files".
Generate AI Discovery Files from your dashboard
Using WordPress? Install the plugin and create all 10 files in minutes — no coding, no configuration files to edit manually.
Get the PluginRegister in the AI Visibility Directory
Once your AI Discovery Files are published, register your website in the AI Visibility Directory — the verified registry of websites implementing AI Discovery Files. Registration validates your implementation and lists your site for AI systems and industry peers to discover.
Card entry in the directory with automated file validation. Open to any site with a valid llms.txt file. No cost.
Dedicated profile page on the directory with dofollow backlinks to your website — a genuine SEO authority signal from a topically relevant, verified source. Includes an attribution badge and enhanced visibility.