Roadmap
Theme-pegged forward plan for the AI Discovery Files specification.
This page is maintained: status values change as themes move from Future to Next to Active. Themes do not carry version pegs because dates and version assignments shift; status reflects current intent. See specification conventions for status definitions.
Last updated:
An open specification benefits from visible planning: external implementers, the directory, and downstream tools can align if they know where the specification is going. This roadmap documents the themes the maintainer is committed to working on, in priority order, with a status flag per theme.
1. How this roadmap works
The roadmap is theme-pegged, not version-pegged. Each theme has a clear scope and a status flag. When the maintainer starts work, status moves to Active. When the work ships, the theme is removed from this page and a link to the relevant changelog entry replaces it. Empty roadmaps damage trust; this page exists to be honest about what is and is not on the agenda.
Status meanings:
- Active
- Work is in progress. A coordinated release is expected within roughly the current quarter.
- Next
- Committed. Will be picked up after the Active themes ship.
- Future
- Identified as worth doing; not yet committed to a quarter. Themes here may move to Next as Active themes complete.
- On hold
- Identified as worth doing but blocked, deferred to a later major version, or waiting for external dependencies (e.g. an IETF standard to stabilise).
Themes do not promise specific dates. Themes do not promise specific version numbers. They promise scope and intent. The versioning policy remains the source of truth for how a release maps to a SemVer increment.
2. Active
No themes are currently flagged Active. The standardisation work documented in the changelog (Phases 1 through 5, releases 1.4.0 through 1.8.0) is complete. The next active block begins when a theme below moves up.
3. Next
Extension mechanism
Status: Next. Scope: A formal rule for how third parties propose new AI Discovery Files without polluting the core. Will be documented at /specifications/extensions/. Core idea: experimental files use an x- prefix (e.g. x-products-ai.txt) and are not part of any conformance class; promotion to a core file requires a proposal, an example deployment, and at least one independent implementation. The mechanism prevents the spec from accreting kitchen-drawer files.
Internationalisation and accessibility
Status: Next. Scope: A dedicated page covering multi-variant file naming (e.g. llms-fr.txt), locale-tagged fields inside identity.json, right-to-left language guidance, and accessibility considerations for llms.html. The single-language BCP 47 declaration field already shipped in Phase 2; this theme covers the harder cases.
Discovery via robots.txt
Status: Next. Scope: Define a Discovery: directive that publishers can add to robots.txt pointing at AI Discovery Files. Solves the cold-start problem for consumers that don't probe root-level paths blindly. The mechanism layers on top of RFC 9309 rather than redefining it.
4. Future
Media-type stance
Status: Future. Scope: A formal statement on this project's position on IANA media-type registration. The current direction (per the implementation plan) is to declare a stance rather than pursue registration, on the grounds that registration is heavy for a single-team spec. The statement will live alongside the HTTP behaviour page.
Multi-language file variants
Status: Future. Scope: Move beyond the single Lang: header to support per-language variants of the same file (e.g. /llms-fr.txt, /llms-de.txt alongside /llms.txt). Subsumed under the i18n theme above but called out separately because it has its own design questions (content negotiation? path-based? both?).
Conformance certification mark
Status: Future. Scope: Three SVG badges (Essential, Recommended, Complete) issued by the AI Visible Directory when a publisher passes verification. Documented in the conformance specification as a possible future feature. Requires Directory schema changes and a signed-issuance design; held back until the certification path is unambiguous.
Directory's formal role as canonical conformance registry
Status: Future. Scope: Document the AI Visible Directory's role as the canonical, public, verifiable record of conformance status for participating publishers. Currently the Directory operates this way de facto; the theme is to make the role explicit in the specification.
5. On hold
File integrity and signing
Status: On hold (2.0 territory). Scope: A way for publishers to cryptographically sign their AI Discovery Files so consumers can verify integrity against tampering or man-in-the-middle modification. Designs likely to draw on Sigstore-style attestation, JOSE/JWS, or a HTTPS-anchored alternative. Held back because the design has cross-cutting implications (key management, key rotation, downstream caching, validator behaviour) that warrant a major version. See the security and privacy trust model for the current (no-signing) baseline.
IETF or W3C engagement
Status: On hold. Scope: Submit a slice of the specification (likely the discovery mechanism or the file-format definitions) as an Internet-Draft or W3C Note. Held back until conformance, governance, and implementations are demonstrably stable; standards-body engagement is hard to retract once started.
IANA media-type registration
Status: On hold. The maintainer's current position is to declare a stance rather than pursue registration; see the Media-type stance theme above. Listed here as On hold to be explicit that registration is not on the agenda.
6. How themes are added or removed
A theme is added to this page when:
- It is identified as worth doing (by the maintainer, by an implementer, or via a GitHub issue on the project repository)
- Its scope can be stated in one or two paragraphs without "and other things"
- It does not duplicate an existing theme or an existing shipped specification
A theme is removed from this page when:
- It ships: the entry is replaced with a link to the relevant changelog entry
- It is abandoned: the entry is replaced with a brief note in the governance page so the decision is recorded
The maintainer reviews the page at least once per quarter. Suggested themes can be raised via the project repository.
References
- Versioning and Deprecation Policy: how a release maps to a SemVer increment.
- Governance and Editorial Process: how decisions on the roadmap are made and recorded.
- Conformance specification: source of the conformance mark and certification themes.
- Security and Privacy Considerations: source of the integrity / signing theme.
- Project changelog: shipped releases, with links to the specification pages affected.