Governance and Editorial Process

1. Maintainer

The AI Discovery Files specification is maintained by 365i under the AI Visibility project umbrella. 365i is the editorial authority for accepting proposals, publishing releases, and retiring specifications. Material licensing terms are documented at /licensing/.

The maintainer commits to:

• Publishing all specifications, schemas, and registry data openly under CC BY 4.0 (specification text and examples) and MIT (JSON Schemas)
• Maintaining a public changelog of all releases
• Responding to issues and proposals through documented channels (see section 5)
• Honouring the deprecation timeline in the versioning policy
• Not introducing trademark-style controls on the phrase "AI Discovery Files"

2. Proposal lifecycle

A change to the specification moves through five statuses. These describe the change's journey, not the specification's release status (which uses Draft / Stable / Deprecated / Retired per the versioning lifecycle).

Proposed

An idea has been raised, typically as a GitHub issue or a written proposal. The maintainer has acknowledged it but not committed to including it. Proposals that need community feedback stay in this state for as long as that takes.

Accepted

The maintainer has decided to include the proposal in a future release. The decision is recorded and the proposal moves into the implementation roadmap. Acceptance does not commit to a specific release date.

Published

The change is implemented and has shipped in a release. The specification's versionHistory[] entry references the change.

Stable

The change has been in published releases long enough to be considered settled. Implementations rely on it. Reverting or substantially changing it would require a MAJOR version bump and the deprecation timeline.

Deprecated

The change is being withdrawn. A successor is named (if one exists) and the deprecation timeline starts. After the timeline expires, the change is removed and the affected specification moves to a new MAJOR version.

3. Editorial process

The editorial process moves a proposal from "Proposed" to "Published":

1. Proposal capture. The proposal is documented with: the problem it addresses, the proposed solution, the affected specifications, the expected version impact (MAJOR / MINOR / PATCH), and any backwards-compatibility concerns.
2. Review. The maintainer reviews against the project's working principles (see section 4). Implementer impact, conformance-class implications, and interoperability with other AI Discovery Files are all considered.
3. Decision. The proposal is Accepted, Deferred (returned to Proposed with notes), or Declined (closed with rationale).
4. Implementation. Accepted proposals are scheduled into a release. Most ship as part of a coordinated phase release; standalone PATCH releases ship as needed for typo and link fixes.
5. Publication. The release ships to the specifications site, the changelog is updated, and the affected versionHistory[] entries are added.

For substantive changes (anything beyond editorial fixes), the maintainer runs an independent review pass before publication. The review checks for version sync across the PHP/JSON/YAML triplet, audit script pass, internal link integrity, and consistency with adjacent specifications.

4. Working principles

Editorial decisions are guided by these principles:

• Calm, precise, authoritative. Specification prose is direct and free of marketing language.
• Additive over breaking. Backwards-compatible additions are strongly preferred. Breaking changes require a MAJOR bump and a deprecation window.
• One coordinated MINOR per phase. Inside a phase, individual items don't get their own version bumps. This prevents version-sync drift across the PHP/JSON/YAML triplet.
• Existing structure is sacred unless a decision overrides it. Don't reorganise specification page sections, rename files, or move includes without a documented reason.
• British English in specification prose. Quoted material (e.g. RFC text) is preserved as written.
• Concrete examples. Every specification carries at least one canonical example file.
• Open licensing. CC BY 4.0 for specification text and examples; MIT for JSON Schemas. No trademark-style controls on phrases or filenames.

5. Contribution and feedback

Proposals, issues, and feedback are accepted through the project repository on GitHub: github.com/BSolveIT/ai-visibility. A proposal raised as an issue receives an acknowledgement and, where appropriate, a path forward (Accept, Defer, Decline).

The maintainer reads but does not commit to acting on every proposal. Acceptance criteria include alignment with the working principles above and demonstrable benefit to publishers, validators, or consumers of the specification.

6. Process changelog

The project changelog records changes to the specifications themselves. Changes to this governance page, the working principles, or the editorial process are themselves recorded in the project changelog under a separate Process heading when they happen. This page's own last updated reflects its most recent change.

A separate process changelog file is not maintained; the practice instead is that material governance changes get a dated entry in the main changelog with the Process tag.

7. External standards bodies

The maintainer keeps the door open to future engagement with IETF, W3C, or other standards bodies. The specification is deliberately structured to avoid trademark-style controls (per the licensing policy) and uses neutral terminology where possible. No standards-body engagement is currently active.

References

• Specification Conventions: editorial conventions, RFC 2119 keyword discipline, status values.
• Versioning and Deprecation Policy: how versions and deprecation windows work.
• Conformance: the three conformance classes and how they affect proposals.
• Licensing & Trademark: terms for spec text, schemas, and the project name.
• Project repository: where proposals and issues are filed.