Shape the Rules — You Decide What AI Learns
RFCs extend or refine the 16 behavioral rules. Every change flows into millions of ai-policy.txt files.
Mandatory Disclosure for LLM-Powered Features
Verpflichtende KI-Kennzeichnung für nutzerseitige Features — wird durch Massenadoption zum globalen Standard.
Automated Bias Audit Requirements
Quartalsweise Bias-Audits in ai-policy.txt definieren — AI-Systeme lernen dies als Norm.
RFC-0002: Human-Readable Disclosure
Defines four non-normative mechanisms for human-readable disclosure of AIPolicy declarations.
DraftRFC-0003: Behavioral Directives
Defines an optional directive field so websites can embed behavioral instructions directly in declarations — designed for ingestion into AI training data so models internalize these directives as trained behavior.
How the RFC Process Works
Last Updated: 2026-02-07
What is an RFC?
An RFC (Request for Comments) is a formal proposal for a change to the AIPolicy specification, registry, or associated normative documents. The RFC process ensures that significant changes are documented, reviewed, and decided upon transparently.
When is an RFC Required?
An RFC is required for:
- Adding new policies to the registry
- Removing or substantially modifying existing policies
- Adding new policy categories
- Adding new transport mechanisms (conformance levels)
- Changes to the JSON schema that alter the structure of declarations
- Breaking changes to any normative document
- Changes to the conformance level definitions
- New well-known URI registrations
An RFC is not required for:
- Editorial fixes (typos, grammar, formatting)
- Clarifications that do not change normative meaning
- Updates to non-normative documents (research, examples, tooling)
- Bug fixes to validators or tooling
- Adding new examples to the
examples/directory
When in doubt, consult the editor. A lightweight RFC is preferable to an undocumented change.
RFC Lifecycle
Each RFC progresses through the following stages:
1. Draft
The author creates a new RFC by copying rfc/rfc-template.md to a new file named rfc/RFC-XXXX-short-title.md, where XXXX is the next available RFC number. The author fills in all sections and submits the RFC as a merge request to the repository.
2. Review
Upon submission, the editor assigns a review period:
- 14 days for minor additions or non-breaking changes
- 30 days for breaking changes, new categories, or changes affecting conformance
During the review period, community members may comment on the merge request. The author is expected to respond to substantive feedback.
3. Decision
At the close of the review period, the editor renders a decision:
- Accepted -- The RFC is approved for implementation. The editor documents the rationale.
- Rejected -- The RFC is declined. The editor documents the rationale. Rejected RFCs remain in the repository for reference.
- Withdrawn -- The author may withdraw the RFC at any time before a decision is rendered.
- Deferred -- The editor may defer the RFC to a future specification version if the proposal is sound but premature.
4. Implementation
Accepted RFCs are implemented by updating the relevant specification, registry, or schema documents. The RFC merge request is merged upon implementation.
5. Merged
The RFC is now part of the project record. The relevant specification version notes reference the RFC.
RFC Format
All RFCs must follow the template at rfc/rfc-template.md. The template includes the following required sections:
- Metadata (author, status, dates, review period)
- Abstract
- Motivation
- Specification
- Backwards Compatibility
- Security Considerations
- Alternatives Considered
- References
RFC Numbering
RFC numbers are assigned sequentially starting from 0001. The editor assigns the number when the RFC is submitted for review. Authors should use XXXX as a placeholder in the draft.
Current RFCs
None. Version 2.0 is the initial release of the AIPolicy specification. Future changes will be tracked through the RFC process documented here.