Governance

The Citadel Project is a community effort. No individual, employer, or vendor owns its standards. This document describes how decisions get made, who makes them, and how those people change over time.

It is deliberately lightweight. We would rather have a short document people actually follow than a constitution nobody reads.

Roles

Contributor

Anyone who opens an issue, comments on a discussion, or sends a pull request. No application process and no permission needed. Most of the work happens here.

Maintainer

Contributors with commit rights to a repository, responsible for reviewing and merging changes, triaging issues, and upholding the Code of Conduct.

Maintainers are nominated by an existing maintainer on the basis of sustained, substantive contribution, and confirmed by lazy consensus among the current maintainers over a 7-day period. Maintainers who have been inactive for six months move to emeritus status; they keep the credit and lose the commit bit, and can be reinstated by asking.

Spec Editor

Each standard has one or more spec editors who own the coherence of its text. Editors decide what the specification says, resolve conflicting review comments, and are accountable for the standard being internally consistent and implementable. Editors are appointed by maintainer consensus when a working group forms.

Founding Spec Editor is a permanent honorific recording who authored the work a standard is built on. It carries the editorial responsibilities above for as long as the person wants them, and the credit permanently regardless.

Standard	Founding Spec Editor	Current Spec Editors
OARS	Khurram Chaudhary (@kuddyc)	Khurram Chaudhary (@kuddyc)

Chair

The chair keeps the project moving: convening meetings, keeping the agenda, making sure decisions get recorded, representing the project publicly, and breaking deadlocks procedurally — by calling a vote, never by casting a deciding one.

The chair rotates every six months. The chair is elected by simple majority of maintainers and may serve at most two consecutive terms. Rotation is a feature, not a formality: it is the mechanism that keeps the project from becoming any one person’s.

The chair has no special authority over technical content. A chair who is also a spec editor wears those hats separately.

Term	Chair
Founding term, to be elected	—

How decisions get made

Lazy consensus (the default)

Most changes are proposed as a pull request and merged if nobody objects.

Change type	Minimum open period	Approvals needed
Typos, formatting, broken links	none	1 maintainer
Rating change to an existing permission	7 days	1 maintainer + 1 spec editor
New or changed factor, weight, or threshold	14 days	2 maintainers + 1 spec editor
Ratifying a standard version	30 days	two-thirds of maintainers
Governance or charter change	14 days	two-thirds of maintainers

An objection is not a veto. It is a request for discussion, and it obliges the proposer to engage with it. If discussion cannot resolve the disagreement, the chair calls a vote.

Voting

When a vote is needed, it is held in a public GitHub Discussion, open for at least 7 days, decided by the threshold in the table above with a quorum of half the maintainers. Votes are public — no secret ballots.

Recording decisions

Every decision affecting the standard or the project is recorded in a GitHub Issue, Discussion, or merged pull request, capturing:

• Who decided
• Background and motivation
• Options considered
• Rationale for the chosen approach
• Implementation steps, if any

Nothing is decided in chat. Discord is for conversation; GitHub is for decisions. Any Discord discussion trending toward a decision moves to GitHub before it becomes one. See COMMUNICATION.md.

Standard lifecycle

Draft  ──▶  Public Review  ──▶  Ratified vX.Y  ──▶  Superseded

Draft. Under active development. Anything may change without notice. Not suitable for production use. Marked status: Draft in spec.yaml.

Public Review. The text is considered complete and is published for formal comment for a minimum of 30 days (60 for a major version). Comments are collected as issues and each one must be resolved — accepted, rejected with reasons, or deferred — before ratification.

Ratified. Approved by a two-thirds maintainer vote and assigned a version number. The text of a ratified version does not change; corrections are published as errata and folded into the next version.

Superseded. Replaced by a later version. Ratified versions stay published permanently so that implementations referencing them keep working.

Versioning

The specification and the ratings dataset version independently, because they change at very different rates. A corrected rating for one permission should not require re-ratifying the model.

Both follow semantic versioning:

	Specification	Ratings dataset
Major	Model changes that alter scores — new dimension, changed weights, changed tier thresholds	Re-baselining that changes many ratings at once
Minor	New factors or guidance that are backward compatible	New permissions rated
Patch	Clarifications with no scoring effect	Corrections to individual ratings

Every release publishes JSON artifacts with the version embedded, so an implementation can pin to a known model and dataset.

Working groups

A working group forms when there is a standard to write and at least two people committed to writing it. Forming one requires a proposal in GitHub Discussions naming the scope, the initial editors, and the intended deliverable, plus maintainer approval by lazy consensus over 14 days.

Working groups get a channel in Discord, a label in the issue tracker, and a directory in the repository. They do not get private decision-making — the rules above apply to them in full.

A working group whose standard is ratified and which has no further work in flight is dissolved, and maintenance passes to the spec editors.

Conflicts of interest

Contributors are welcome to work for vendors whose products implement these standards — most of us do. What we ask:

• Disclose the affiliation when it is relevant to what you are proposing
• Argue from the merits of the standard, not the needs of your product
• Recuse yourself from votes where you have a direct commercial interest

Standards must be implementable by anyone. A proposal that only one tool could reasonably implement is a bug in the proposal.

Changing this document

Governance changes are proposed as a pull request, stay open for at least 14 days, and require a two-thirds majority of maintainers. The chair announces proposed changes in Discord and in GitHub Discussions when the review period opens.