The Role of Tribela Labs
Tribela Labs does not run this community. It maintains the conditions that allow the community to run itself. Think of it less like a board of directors and more like a scientist watching an experiment: observing, recording, stepping in when the process breaks, and adjusting when the model drifts.
Tribela Labs holds one vote in community decisions. Same weight as anyone else. Its authority is not in that vote; it is in its responsibility to keep the system working.
Tribela Labs may, at its discretion:
- Pause or invalidate a vote if the process has been materially compromised (e.g. coordinated manipulation, Sybil attacks, or bad-faith participation)
- Amend this governance model when it produces clearly unbalanced or unworkable outcomes
- Revoke membership from stakeholder groups for sustained bad-faith conduct, after a documented review
- Act unilaterally on legal, security, and compliance matters that cannot wait for a vote, with a mandatory public post-mortem published within 14 days
This is not a veto over outcomes Tribela Labs dislikes. It is a circuit-breaker for cases where the process itself has broken down. Every use of this authority gets logged in the public governance record.
Tribela Labs is the developer of this system. It patches, rebalances, and updates the rules when the model stops working as intended. The community governs the research. Tribela Labs governs the conditions of governance.
Stakeholder Groups
Five groups participate in community decisions. Every verified member holds one vote, weighted equally regardless of affiliation, seniority, or funding relationship.
| Group | Who they are | How membership is granted |
|---|---|---|
| Lab | The core team building and maintaining the infrastructure | Internal; granted by Tribela Labs on joining |
| Contributors | People who ship code, reviews, datasets, or research | Automatic on meeting contribution thresholds (see below) |
| Users | Verified users of Tribela Labs products | Automatic on account verification via product login |
| Academy | Researchers and academics contributing knowledge | Vetted and admitted by Tribela Labs |
| Civil Society | Representatives from policy, ethics, and community organisations | Vetted and admitted by Tribela Labs |
User Verification
User voting rights are tied to a verified product account. A logged-in account in good standing qualifies. Accounts flagged for abuse, or created after a vote opens, are ineligible for that vote cycle. This requires engineering support and activates when the voting platform is ready.
Academy and Civil Society Vetting
Tribela Labs reviews applications to both groups on a rolling basis, assessing credibility, relevance, and independence. Decisions are logged publicly. Any admitted member can be challenged by two or more existing members, which triggers a Tribela Labs review. Vetting decisions in these groups are not subject to community vote; they sit within Tribela Labs' stewardship responsibility.
Earning Contribution-Based Voting Rights
Rights are tied to sustained, verifiable work. Not one-time actions.
Code contributors
10 merged PRs or 20 reviewed PRs across any Tribela Labs repository.
Typo fixes and formatting-only PRs count toward one-quarter of a threshold unit.
Research contributors
1 published paper co-authored with a Tribela Labs contributor, or 2 published datasets submitted to a Tribela repository.
Community contributors
Substantive participation in governance discussions across 3 consecutive months, assessed by a quarterly review run by the Lab group.
Voting rights expire after 6 months of inactivity. Re-earn them by contributing again. Rights do not expire during an active vote; eligibility locks at the moment voting opens.
How Decisions Work
What the community votes on
| In scope for community vote | Tribela Labs discretion |
|---|---|
| Research cluster priorities | Legal and compliance matters |
| New feature proposals | Funding and budget allocation |
| Dataset and benchmark additions | Trademark and brand decisions |
| Community membership rules (non-vetting) | Academy and Civil Society vetting |
| Changes to the scope of community decisions | Governance model amendments |
Proposal eligibility
To open a formal proposal, a contributor must:
- Meet the contribution threshold for their group (see above)
- Collect a co-sign from at least two other eligible contributors before the proposal enters the formal cycle
Co-signers are not endorsing the outcome. They are confirming the proposal is serious and worth the community's time. This catches weak proposals early, before they consume a 2-week discussion window.
The voting cycle
- Proposal — An eligible contributor opens a governance thread covering: what is being proposed, why it matters, and what success looks like. Two co-signers must be named before the thread enters the formal cycle.
- Discussion — Open for 2 weeks. Any member of any stakeholder group may ask questions, raise concerns, or suggest amendments. Amendments require the proposer's agreement. If a material amendment is rejected, the person proposing it may open a separate proposal.
- Vote — Anonymous. One person, one vote. Simple majority passes for operational decisions (see scope table). Voting stays open for 5 days after the discussion window closes.
A vote is only binding if quorum is met: at least 10% of all active eligible voters must participate. Active voters are those whose rights were in good standing when voting opened. If quorum is not met, the proposal may be re-submitted once with a revised discussion period. - Result — The result publishes in the governance record with participation figures and no individual attribution. The proposing contributor is listed as execution lead.
- Execution accountability — Within 60 days of a passed vote, the proposing contributor must open a check-in thread reporting on progress. No meaningful progress and no credible explanation means any eligible contributor can open a reassignment motion: a simple vote (same quorum, simple majority) to hand execution to someone willing to carry it.
Operational vs Constitutional Decisions
Not all decisions are equal.
Operational decisions (research threads, tooling choices, dataset additions, feature proposals) pass by simple majority with standard quorum.
Constitutional decisions (changes to stakeholder group definitions, changes to the voting process, changes to what is in scope for community decisions) require a two-thirds majority and double quorum (20% of active eligible voters).
Changes to the governance model itself are not subject to a community vote. Tribela Labs makes those changes, in the open, with a public rationale and a 30-day notice period before they take effect. The community can raise objections during that window. Tribela Labs is expected to address them substantively. But the final call belongs to Tribela Labs. This is intentional. Patching the rules requires the ability to act when the community process is the thing that has broken.
Anonymity and the Voting Platform
Votes are anonymous. Results publish with participation counts and no individual attribution. In a small early community where everyone knows each other, removing that social pressure matters.
The voting platform is still under consideration. A dedicated tool may be built to support this model natively, covering account verification for Users, anonymous ballot handling, and the public governance record. Until that platform is ready, votes will run through a temporary process to be announced. Platform decisions rest with Tribela Labs.
Cluster D: A Live Experiment
Cluster D is not just a research group studying community AI. It is a test of whether this governance model actually works.
Every protocol in this document applies to Cluster D's own decision-making before it gets considered for the broader lab. Cluster D runs on the same rules it studies. Its research on participatory governance, community trust, and decentralised AI feeds back directly into how these rules evolve.
The feedback loop is intentional:
- The community governs Cluster D's research direction
- Cluster D researches how communities govern AI systems
- What it finds informs how Tribela Labs updates the governance model
- The updated model gets re-tested through Cluster D
The first community vote will decide Cluster D's next research thread. That vote is the first real test of this model: quorum requirements, co-sign thresholds, and all.
If the model works, it scales. If it doesn't, Cluster D will be the first to find out why.
Research Ownership and Attribution
Individual researchers keep their names on their work. Always. If you ran the experiments, wrote the paper, or built the dataset, your name is on it.
Tribela Labs is recorded as the institutional affiliation for all research conducted under its clusters. Papers, preprints, datasets, and benchmarks produced within Cluster D carry the affiliation “Tribela Labs” alongside the named authors. This is standard academic practice and does not transfer any rights away from the researchers involved.
All research outputs are published under CC-BY-SA unless a specific project requires otherwise, in which case Tribela Labs will agree the license with contributing researchers before work begins. No research produced by community contributors will be commercially licensed or withheld without the explicit consent of the named authors.
Disputes over authorship order or attribution are handled between the contributors involved. If a dispute cannot be resolved, Tribela Labs will mediate. Its mediation decision is final.
One practical note: contributors from external institutions (universities, other labs) should confirm with their own institution whether co-affiliation is required or permitted. Tribela Labs does not manage that relationship on your behalf.
Governance Record
All proposals, votes, results, Tribela Labs interventions, and governance amendments are logged in a public governance record. The record is permanent and append-only. Tribela Labs maintains it. Anyone can read it.
Maintained by Tribela Labs. Amendments are made at Tribela Labs discretion with a 30-day public notice period. Last revised: 2026.