Who Decides What AI Learns?

This document defines the decision-making process, roles, change management procedures, and organizational structure for the AIPolicy Web Standard. It is modeled after established practices in W3C and IETF standards development.

This document is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Applies to: All normative specification text, JSON Schema definitions, policy registry entries, and reference implementations maintained under this repository.

Related documents: This governance document operates within the boundaries defined by CHARTER.md. For contribution procedures and style guidelines, see CONTRIBUTING.md. For the RFC template and filing instructions, see rfc/README.md.

---

1. Overview#

This document serves two purposes:

1. Process definition. It describes how changes to the AIPolicy Web Standard are proposed, reviewed, decided upon, and implemented.
2. Organizational structure. It defines the roles and bodies that participate in governance, their authorities, and their constraints.

The governance model is designed to evolve. In its initial phase, a single editor holds decision-making authority. As the project matures and institutional adopters emerge, governance transitions to a multi-stakeholder model through the Technical Steering Committee described in Section 3.

---

2. Roles and Responsibilities#

2.1 Editor#

The editor is responsible for the consistency, quality, and technical direction of the specification text. The editor:

• Makes editorial decisions (formatting, terminology, structural organization) without requiring an RFC.
• Manages the RFC lifecycle as described in Section 5.
• Assigns RFC tracking numbers and review periods.
• Renders decisions on RFCs after the close of review periods.
• Maintains the policy registry and JSON Schema definitions.
• Represents the project in external communications when no TSC exists.

The editor has final authority on all decisions until a Technical Steering Committee is formed (see Section 3). After TSC formation, the editor retains day-to-day operational authority but defers to the TSC on strategic decisions as defined in Section 3.3.

Current editor: Guido Mitschke

2.2 Contributors#

A contributor is any individual who submits issues, merge requests, review comments, or RFC proposals. There are no membership requirements. All contributions are subject to the intellectual property terms described in Section 9.

Contributors SHOULD familiarize themselves with the charter (CHARTER.md) and contribution guidelines (CONTRIBUTING.md) before submitting their first contribution.

2.3 Reviewers#

Reviewers are contributors who have demonstrated sustained, constructive participation in the project. The editor MAY grant reviewer status to contributors who meet the following criteria:

• At least three accepted contributions (merge requests, substantive issue reports, or RFC reviews).
• Familiarity with the specification, registry structure, and JSON Schema.
• Adherence to the project's code of conduct.

Reviewers MAY:

• Approve merge requests for minor changes (see Section 5.4).
• Be invited by the editor to participate in formal RFC review periods.
• Provide domain-specific expertise (web standards, AI/ML policy, data protection law, or related technical fields).

Reviewer status does not confer decision-making authority over RFCs. Reviewer participation in formal review periods is voluntary.

2.4 Spec Maintainer vs. Site Maintainer#

The AIPolicy Web Standard distinguishes between two types of maintainer roles that operate in separate domains:

• Specification Maintainers (editor, reviewers, TSC members) maintain the standard itself: specification text, schemas, registry, and governance documents. Their authority is defined in this document.
• Site Maintainers (website operators, publishers) implement the standard on their own properties by publishing AIPolicy Declarations. Site maintainers are not governed by this document. They operate independently and make their own editorial decisions about which policies to endorse and how to present their declarations.

These roles may overlap (a specification contributor may also be a site maintainer), but the authorities do not transfer. A specification maintainer has no authority over how a site maintainer implements the standard, and a site maintainer has no special authority over the specification.

2.5 Visual Identity#

The AIPolicy project's visual identity (logo, badge designs, color palette, typography guidelines) is maintained outside the specification repository. Visual assets are managed in /tools/ and on the project website.

Changes to visual identity do not require an RFC. The editor (or TSC, if formed) approves visual identity changes through the standard merge request process. Visual identity guidelines are non-normative and do not affect specification conformance.

---

3. Technical Steering Committee (TSC)#

3.1 Formation#

A Technical Steering Committee SHALL be formed when three or more institutional adopters (organizations that have deployed AIPolicy in production) exist and express interest in participating in governance.

The formation process MUST be initiated through a dedicated RFC that defines:

• The initial membership nomination process.
• Election or appointment procedures for the first TSC.
• Any modifications to the procedures outlined in this section.

Until the formation threshold is reached, the editor retains sole decision-making authority as described in Section 2.1.

3.2 Composition#

• The TSC SHALL consist of 5 to 7 members.
• Members serve 2-year terms, renewable once. A member who has served two consecutive terms MUST wait at least one full term before being eligible for re-appointment.
• The editor is an ex-officio member of the TSC with voting rights.
• Remaining seats are filled through nomination and election by existing TSC members and active contributors, as defined in the formation RFC.
• The TSC SHOULD aim for diversity of organizational affiliation. No single organization SHOULD hold more than two seats.

3.3 Responsibilities#

The TSC is responsible for:

• Specification direction. Approval of the roadmap and prioritization of major specification work.
• Registry governance. Approval of new policy categories, removal of existing categories, and changes to registry structure.
• Breaking changes. Final approval of any change that would cause a conforming implementation to become non-conforming (see Section 5.4).
• Versioning. Approval of major version increments.
• Governance amendments. Approval of changes to this document and to CHARTER.md.

The editor retains authority over:

• Day-to-day editorial decisions.
• Minor change approvals.
• RFC lifecycle management (assigning numbers, setting review periods).
• Non-breaking policy additions (subject to the standard RFC process).

3.4 Meetings#

• The TSC SHALL meet at least quarterly.
• Meeting agendas MUST be published at least 7 days in advance.
• Meeting minutes MUST be published publicly within 14 days of the meeting.
• Meetings MAY be held remotely.
• Contributors and Advisory Board members MAY attend as observers.

3.5 Quorum and Decisions#

• Quorum requires a simple majority of current TSC members.
• Decisions require a simple majority of members present, except where a supermajority is required (see Section 6).
• The TSC SHOULD attempt to reach consensus before resorting to a formal vote.

---

4. Advisory Board#

4.1 Purpose#

The Advisory Board provides non-binding guidance to the editor and TSC on matters that intersect multiple domains, including but not limited to legal interpretation, AI policy, data protection, web standards interoperability, and accessibility.

4.2 Composition#

• Advisory Board members are invited by the TSC (or by the editor, if no TSC exists).
• There is no fixed size. Membership is based on relevant expertise.
• Advisory Board members have no voting rights on specification decisions.
• Members serve at the discretion of the TSC and MAY be removed at any time.

4.3 Scope#

The Advisory Board MAY:

• Review major RFC proposals and provide written commentary.
• Advise on cross-domain implications of proposed changes (e.g., legal compatibility, regulatory alignment, accessibility impact).
• Recommend topics for future specification work.

The Advisory Board MUST NOT:

• Approve or reject RFCs.
• Direct the editor or TSC on specification decisions.
• Represent the project externally without explicit authorization from the editor or TSC.

---

5. RFC Workflow#

All substantive changes to the specification follow the RFC (Request for Comments) lifecycle. For the full RFC template and filing instructions, see rfc/README.md.

5.1 RFC Numbering#

RFCs are numbered sequentially: RFC-0001, RFC-0002, and so on. The editor assigns the number when the RFC is submitted for review. Authors SHOULD use XXXX as a placeholder in drafts.

5.2 RFC Categories#

Each RFC MUST declare one of the following categories:

Category	Description	Minimum Review Period
Policy Addition	New policy fields or registry entries	14 days
Policy Modification	Changes to the semantics of existing policies	14 days
Spec Change	Non-breaking changes to the specification format	14 days
Breaking Change	Any change causing conforming implementations to become non-conforming	30 days

The editor MAY extend the review period for any RFC at their discretion.

5.3 Lifecycle#

Each RFC progresses through the following stages:

1. Draft. A contributor opens an RFC document in the rfc/ directory. The draft describes the proposed change, its motivation, and its expected impact on existing implementations. Drafts have no formal status and MAY be revised freely by their authors.

2. Public Comment. The editor assigns a tracking number and opens the public comment period (minimum durations per Section 5.2). During this period, any contributor MAY comment on the associated merge request or issue. The editor MAY invite domain-specific reviewers or Advisory Board members.

3. Editor Review. After the comment period closes, the editor evaluates all feedback. If a TSC exists and the RFC falls within TSC authority (Section 3.3), the editor prepares a recommendation for the TSC.

4. Decision. The decision authority (editor or TSC, as applicable) renders one of the following decisions:

• Accepted -- The RFC is approved for implementation.
• Accepted with modifications -- The RFC is approved subject to specified changes, which MUST be applied before implementation.
• Rejected -- The RFC is declined.
• Deferred -- The RFC is sound but premature; it is deferred to a future specification version.
• Withdrawn -- The author may withdraw the RFC at any time before a decision is rendered.

The decision MUST be recorded in writing within the RFC document, including a rationale that addresses substantive objections raised during the comment period.

5. Implementation. Accepted RFCs are implemented as concrete changes to the specification text, schemas, or code. The author of the RFC or a designated contributor prepares a merge request. This merge request undergoes standard code review before merging.

6. Merged. The merge request is merged into the main branch. The RFC document is moved to rfc/accepted/ (or rfc/rejected/ if declined). The specification version is incremented according to the versioning policy.

5.4 Fast-Track Process#

Editorial corrections (typos, formatting, broken links, clarifications that do not alter normative meaning) do not require an RFC. These changes follow the minor change process:

• A merge request is submitted.
• At least one reviewer MUST approve the merge request.
• The editor merges the change.

5.5 Emergency Changes#

In exceptional circumstances (e.g., security vulnerabilities in the schema, critical errors in normative text), the editor MAY apply a change without completing the full RFC process. Emergency changes MUST be:

• Documented in a retroactive RFC filed within 7 days.
• Reviewed by the TSC (if it exists) at the next meeting.
• Reversible if the retroactive RFC is rejected.

---

6. Voting#

6.1 Pre-TSC Phase#

While no TSC exists, the editor has sole decision authority on all RFCs and governance matters. No formal vote is required; the editor renders decisions directly.

6.2 Post-TSC Phase#

Once a TSC is formed, the following voting rules apply:

Decision Type	Required Majority
Non-breaking RFC approval	Simple majority (>50%)
Breaking change approval	Supermajority (2/3 of TSC members)
Governance document amendment	Supermajority (2/3 of TSC members)
Charter amendment	Supermajority (2/3 of TSC members)
TSC member removal	Supermajority (2/3 of TSC members)
All other decisions	Simple majority (>50%)

6.3 Voting Procedures#

• Votes are cast on-record and MUST be recorded in meeting minutes or the relevant RFC document.
• Proxy voting is not permitted.
• In the event of a tie, the editor casts the deciding vote.
• Abstentions are recorded but do not count toward the majority calculation.
• TSC members who are absent without proxy (since proxy voting is not permitted) are not counted for quorum or majority purposes for that specific vote, but quorum MUST still be met.

---

7. Conflicts of Interest#

7.1 Disclosure Requirement#

All TSC members and Advisory Board members MUST disclose:

• Current employment or consulting relationships with AI companies, AI research laboratories, or organizations with a direct commercial interest in AI governance standards.
• Financial interests (equity, advisory compensation, or similar) in entities that would be materially affected by specification decisions.
• Any other relationship that a reasonable observer would consider relevant to impartial decision-making.

Disclosures MUST be filed upon appointment and updated annually, or within 30 days of any material change.

7.2 Recusal#

A TSC or Advisory Board member MUST recuse themselves from discussion and voting on any matter where they have a direct commercial interest in the outcome. The member SHOULD proactively declare the conflict; if they do not, any other TSC member MAY raise the conflict for consideration.

7.3 Enforcement#

Failure to disclose a material conflict of interest constitutes grounds for removal from the TSC or Advisory Board. Removal requires a supermajority vote (2/3) of the remaining TSC members.

7.4 Editor Conflict of Interest#

The editor role carries heightened conflict-of-interest obligations due to its decision-making authority in the pre-TSC phase.

The editor MUST:

• Disclose all professional affiliations relevant to AI governance, web standards, or AI development.
• Recuse from editorial decisions on RFCs submitted by organizations with which the editor has a direct financial relationship. In such cases, the editor MUST delegate the decision to a reviewer or, if a TSC exists, to the TSC.
• Refrain from using editorial authority to advance proposals that primarily benefit the editor's affiliated organizations at the expense of the broader community.

These obligations apply from the moment the editor assumes the role and continue for 12 months after the editor steps down, with respect to decisions made during their tenure.

---

8. Conflict Resolution#

Disagreements are resolved through a three-step escalation process:

1. Discussion in issue. The relevant parties discuss the disagreement in the associated issue or merge request thread. Contributors are expected to engage constructively and support their positions with technical arguments.

2. Editor decision. If discussion does not produce consensus, the editor renders a decision. The decision MUST include a written rationale that addresses the substantive arguments raised by all parties.

3. Appeal. A contributor who disagrees with the editor's decision MAY:

   • File a new RFC proposing an alternative resolution. The new RFC follows the standard lifecycle and receives a fresh review period.
   • Request TSC review (if a TSC exists). The TSC MAY override the editor's decision by supermajority vote.

The editor MUST recuse from sole decision-making on appeals of their own prior decisions once a TSC exists. In such cases, the TSC renders the final decision.

---

9. Intellectual Property#

• Specification text (all .md files in spec/, rfc/, and the root directory) is licensed under CC BY 4.0.
• Code (schemas, validators, reference implementations, tooling) is licensed under the MIT License.
• No Contributor License Agreement (CLA) is required. By submitting a merge request, issue, or review comment, contributors agree that their contribution is made available under the applicable license terms stated above.
• Contributors MUST NOT submit content that is encumbered by patents, trade secrets, or incompatible license terms.

---

10. Amendments#

This governance document MAY be amended through the RFC process. Amendments to governance require:

• A dedicated RFC with a 30-day public comment period.
• Supermajority (2/3) approval by the TSC, if one exists.
• If no TSC exists, the editor MAY approve governance amendments directly, subject to the standard public comment period.

All amendments MUST be recorded in the repository's version history with a clear description of the changes.

---

AIPolicy Web Standard v2.0.0-draft.4 -- Working Draft