Extensions

1. Experimental files: the x- prefix

A third party MAY publish a file at the root of their website that follows the AI Discovery Files conventions (root-level path, UTF-8 encoding, a documented format) but is not part of the core specification. Such files MUST use an x- prefix in the filename.

Examples:

• x-products-ai.txt — an experimental file listing product information for AI consumers
• x-pricing-ai.json — an experimental machine-parseable pricing file
• x-team-ai.txt — an experimental team-listing file

The x- prefix is a signal to validators and consumers: this file exists, it follows the AI Discovery Files conventions in spirit, but it is not part of conformance. The reference validator MUST NOT report the absence of an x--prefixed file as a finding. The reference validator MAY note the presence of x--prefixed files in an informational section of its output, distinct from conformance findings.

2. Requirements for x--prefixed files

An x--prefixed file MUST meet the following requirements to be a conformant extension:

1. Documented format. The publisher or extension author MUST publish a format definition at a stable URL. The definition need not be RFC-style; a plain README in a public repository is sufficient. Without a public format definition, the file is not a conformant extension.
2. Root-level path. The file MUST live at the root of the host: https://example.com/x-foo-ai.txt. Subdirectories are not permitted because consumers fetch from the root.
3. Conventions compliance. UTF-8 encoding, HTTPS preferred, content-type appropriate to the file format. The same conventions that apply to core AI Discovery Files apply to extensions.
4. No conflict with core files. An x--prefixed file MUST NOT claim authority over fields owned by a core file. For example, an x-pricing-ai.json MAY add pricing fields, but MUST NOT redeclare the publisher's identity (which is owned by identity.json).
5. Unique purpose. An extension MUST NOT duplicate fields a core file already covers. Adding alternate names for the publisher belongs in brand.txt, not in an extension.

Extensions that fail any of these MAY still exist on the publisher's server, but they are not conformant extensions and validators MAY ignore them entirely.

3. Extension fields inside core files

Some core files (notably JSON files like ai.json and identity.json) accept extension fields without requiring a new file. The rule is:

• JSON files: extension fields MUST be prefixed with x- at the property name level (e.g. "x-loyalty-program": {...}). The reference validator MUST NOT report unknown x--prefixed properties as errors. Validators MAY surface them as informational findings.
• Text files with header syntax (such as ai.txt, brand.txt): extension headers MUST use X--prefixed header names (e.g. X-Sustainability-Pledge: gold). Same validator rules apply.
• Markdown files (llms.txt): an extension MUST NOT introduce new H2 sections under a reserved name. New section names SHOULD be prefixed with x- (e.g. ## x-Awards) so they don't collide with future core sections.

Extension fields inside core files have an advantage over standalone x- files: the publisher does not have to introduce a new root-level URL or a new format definition. The cost is that consumers may not recognise the extension fields. Both routes are valid; choose based on whether the extension is conceptually a new file or a new field on an existing file.

4. Path from experimental to core

An extension MAY be proposed for promotion to a core AI Discovery File. Promotion is the path from x-foo-ai.txt to a stable ADF-NNN identifier in the registry. The criteria are:

1. Demonstrated need. The proposer MUST show why the use case is not adequately served by an existing core file or by an extension field in one. A "would be nice" extension does not warrant a core file; a recurring real-world need does.
2. At least one live deployment. The proposer MUST point to at least one publisher already publishing the file under its x- prefix. A purely-theoretical file does not warrant promotion.
3. At least one independent implementation. An independent consumer or validator MUST already read the file. Implementations are the strongest evidence a specification is real and useful.
4. Privacy review. The proposer MUST address what personal data the file might carry and what the publisher's responsibilities are. See security and privacy considerations for the framework.
5. Test cases. The proposer SHOULD provide test cases (valid file, common errors, edge cases) suitable for inclusion in the canonical test suite.
6. Editorial review. The maintainer reviews the proposal under the governance process. If accepted, the proposal moves through the five-status lifecycle (Proposed, Accepted, Published, Stable, Deprecated) and is eventually assigned a new ADF-NNN identifier.

Promotion is not automatic and not guaranteed. The maintainer may decline a promotion on grounds of scope creep (an extension that pulls the specification away from its core mission), overlap with an existing file, or insufficient evidence of demand. A declined promotion does not invalidate the extension; the file continues to exist under its x- prefix.

5. Deprecation of extensions

If an extension is no longer used by its author, the author SHOULD publish a notice at the format-definition URL stating that the extension is deprecated. Consumers SHOULD respect the deprecation notice when discovered.

If an extension's functionality is absorbed into a core file (whether via promotion or via an existing core file growing a field), the extension MUST be marked deprecated at its format-definition URL. Publishers SHOULD migrate to the core file or core-file field within a reasonable transition period.

6. Naming guidance

To reduce collision risk between extensions, the following naming guidance applies:

• Hyphenated category names. Use x-category-purpose-ai.ext rather than abbreviations. x-products-ai.txt is clearer than x-pa.txt.
• Match the core file suffix where possible. An experimental file targeting AI consumers SHOULD end with -ai.txt, -ai.json, or -ai.html as appropriate. This is the suffix convention the core files already use.
• Avoid trademarked names. An x-prefixedwithatrademark-ai.txt file may invite legal pushback; use a generic name unless the extension is explicitly tied to a particular product.
• Reserve common names. A maintainer or community-known extension SHOULD register its name informally via a GitHub issue on the project repository, so other parties don't accidentally collide. There is no formal extension registry yet; an informal record on the project repository is sufficient for now.

7. Non-conformant extensions

A publisher MAY publish files at their root that do not follow these rules (for example, files without the x- prefix that aren't core files, or core-file shaped files that don't match the spec). Such files are not extensions, conformant or otherwise. They are simply files at the publisher's root. The reference validator MUST NOT treat them as AI Discovery Files.

The reference validator MUST report the publication of a file at a root-level path that matches the name of a core AI Discovery File but fails the core spec as a conformance finding for that core file, not as an extension finding. For example, an llms.txt missing its H1 heading is a conformance finding for ADF-001, not an "extension" finding.

References

• Conformance specification: how core files are categorised; extensions are explicitly outside conformance classes.
• Specification registry: machine-readable list of core ADF-NNN identifiers; extension promotion adds to this list.
• Governance and Editorial Process: how a promotion proposal is reviewed.
• Security and Privacy Considerations: the framework an extension's privacy review applies.
• Test Vectors: where promoted extensions add their test cases.
• Roadmap entry: extension mechanism: the planning context for this page.