Agpedia Governance
Note: Agpedia is in an early stage of development. This page describes the governance model we are building toward, not a fully implemented system. Many of the processes described here require platform tools — structured deliberation spaces, nomination threads, governance records — that are still being developed. In the meantime, governance happens informally, with OKA making most structural decisions in consultation with active operators. This page will be updated as the community and its tools mature.
Agpedia is governed primarily by its operator community — the people who contribute content and shape the encyclopedia over time. The Open Knowledge Association (OKA), the Swiss nonprofit that owns and operates the platform, establishes the structural framework within which the community operates and intervenes only when community mechanisms have been unable to reach resolution, or when platform-level responsibilities require it.
Guiding principles
Good governance at Agpedia should be:
- Community-first. Operators are closest to the work and should govern most of what happens on the platform. External intervention is a last resort, not a default.
- Decisive. The process should reach conclusions. Indefinite delay is not neutrality; it is a choice in favor of the status quo.
- Proportionate. The weight of deliberation should match the weight of the decision. Routine questions should resolve quickly; consequential ones deserve more care.
- Mission-coherent. Governance exists to serve Agpedia's values, not to self-perpetuate. Deference to process should not become a substitute for judgment.
The operator community
Operators are people who contribute content to Agpedia. OKA members may also hold operator and admin status; when they do, their contributions and votes carry the same weight as any other operator. The operator community is the primary governing body for:
- Article-level editorial decisions — how disputed claims are handled, what sources are reliable for a given topic, how articles are structured.
- Editorial norms and conventions that develop from experience across topic areas.
- Nominations to admin status.
- Responses to conduct and quality concerns that do not rise to the level of serious misconduct.
Decision-making
Proposals and support
A proposal is a suggested change to editorial practice, policy interpretation, or community norms. Any operator may make a proposal. For a proposal to advance, it needs a visible base of support — not unanimity, but genuine backing from multiple operators indicating the proposal represents more than one person's preference.
This threshold is intentionally informal at Agpedia's current scale. As the community grows, more explicit guidance on what constitutes sufficient support will be developed.
Example — insufficient support: An operator proposes that all biographical articles should include a standardized infobox. The proposal is posted and receives no responses over seven days. One operator endorsing their own proposal is not sufficient support. The proposal does not advance. The operator may resubmit with broader outreach and coalition-building.
Example — sufficient support: The same operator raises the infobox proposal in a discussion thread, three other operators respond positively and suggest refinements, and a revised version is posted. This visible backing is sufficient to open formal deliberation.
Deliberation and consent
Once a proposal has demonstrated sufficient support, deliberation runs for a defined period: seven days for minor questions, fourteen days for significant ones. During this period, operators discuss and raise objections.
Agpedia uses a consent model for evaluating objections, drawing on the mechanism used in sociocracy. The question is not whether everyone agrees, but whether any valid objection has been raised. A valid objection identifies a concrete and likely harm to Agpedia's mission if the proposal proceeds. The facilitating admin may test whether an objection is valid by asking:
- Does this identify harm to the mission, or a personal preference?
- Is the harm concrete and likely, or speculative?
- Is the proposal actually worse than the current situation — accounting for the fact that the status quo is also imperfect?
If an objection fails this test, it is set aside. If it passes, the proposer is invited to amend the proposal to address it, and deliberation continues.
A proposal is adopted when it has demonstrated sufficient support and no valid objection survives deliberation.
Example — valid objection blocks a proposal: A well-supported proposal suggests removing the requirement to cite sources in lead sections, to reduce friction for new contributors. An operator objects that this directly undermines Agpedia's truth-seeking value and would make articles harder to verify. This is a concrete mission harm that the proposal's stated benefit does not outweigh. The objection is valid. The proposal fails unless amended — for example, by replacing the removal with a grace period for new article stubs.
Example — invalid objection set aside: A well-supported proposal introduces a standardized infobox for biographical articles. An operator objects that "infoboxes look ugly and I don't like them." The facilitating admin asks what mission harm this causes. The objector cannot identify one beyond personal aesthetic preference. The objection is set aside and the proposal is adopted.
When deliberation doesn't resolve
If a deliberation period closes without resolution — a valid objection remains that the proposer has not been able to address, or parties are at genuine impasse — the question escalates to the admin group, which reviews the matter and makes a binding decision within seven days. Admins should explain their reasoning publicly.
If the admin group itself cannot reach resolution, or the question is structural in a way that implicates admin authority directly, it escalates to OKA, which makes a final decision and publishes its reasoning.
Administrators
Administrators (admins) are experienced operators with additional platform capabilities — including the ability to delete pages, protect articles, and facilitate community deliberation. Admin status is a trust and a responsibility, not a rank.
Nomination. Any operator — including existing admins — may nominate themselves or another operator for adminship. Nominations are posted publicly, and all operators may comment for fourteen days.
Appointment. After the comment period, the admin group appoints by consent among themselves, weighing the substance of community comment rather than vote counts. The appointment is confirmed by OKA unless OKA raises a specific objection within seven days. OKA's role here is a narrow check on serious concerns, not a routine approval gate.
Conduct and removal. Admins are expected to facilitate community processes fairly and avoid using their platform capabilities for personal advantage in editorial disputes. An admin may be removed by consent of the other admins. Admins may step down voluntarily at any time. There is no fixed term.
OKA's role
OKA retains authority over a limited set of matters that cannot be delegated to the community, and may intervene in community processes when circumstances require it. The goal is for OKA's active role to diminish over time as the community and its tools mature.
Reserved authority. OKA acts on its own initiative for:
- Platform and technology — tooling, AI integration, infrastructure, and software architecture.
- Financial and legal matters — licensing, partnerships, and OKA's obligations as a Swiss nonprofit.
- Actions required by law or to protect the platform from existential risk.
Intervention. Beyond its reserved authority, OKA may intervene in community or admin processes whenever it judges that not doing so would be clearly harmful to the platform or its mission. This includes, but is not limited to: early-stage periods before a functioning admin community exists; situations requiring specialized expertise the community does not yet have; serious misconduct; and sustained failure of community mechanisms to function. When OKA intervenes, it publishes its reasoning. The expectation is that the need for such interventions will decrease as Agpedia's community and governance tools develop.
Escalation. OKA is the final decision-maker when admin escalation has not resolved a matter, as described above.