Governance
A model commons only works if the rules are written down before they are needed. This page states who decides what, on what criteria, and what recourse a contributor has when a decision goes against them.
Status of this document
This is a working draft, not a ratified charter. It describes the governance model the project is building toward and the rules currently enforced in code (see certification). Sections marked proposed are not yet in effect and are open for comment — open an issue if you disagree with one. Sections marked enforced are implemented and tested in this repository.
Participation
Any registered institution or developer may submit a model or a code contribution. There is no membership fee and no invitation requirement.
Acceptance of a model is decided by a model-review board: at least two technical
reviewers and one clinical reviewer, plus the automated quality gate, judged against
published blocking criteria. proposed What ships enforces
k-of-n across distinct institutions; reviewer-role composition is not enforced in
code — Reviewer.role is a free string the policy never consults, and
no blocking criteria are published yet. Acceptance of a code contribution follows the ordinary
pull-request path described in
CONTRIBUTING.md.
Review and promotion partly enforced
A submitted model does not become part of the shared base by being good. It becomes part of the shared base by being certified. Certification has structural requirements in code — with the limits stated precisely, because a control you misunderstand is worse than one you know you lack.
No self-certification
Enforced when a case is opened with the model bundle itself.
CertificationAuthority.submit(bundle) derives the owner institution from
ModelBundle.published_by, which sits inside the content hash the bundle
ID commits to, so a reviewer from that institution is refused. A case opened with only
a bundle ID plus a declared owner is marked self_asserted: true
on the decision log — and that weaker form can still be defeated by declaring a false
owner.
k-of-n threshold across distinct institutions
A threshold over signatures, each bound to a registered reviewer key and to that key's registered institution: a signature cannot claim an institution its key is not bound to. Whether this is a cryptographic control depends on which API you use.
submit_signature()verifies a detached signature the authority did not produce, andReviewerKeyring.verify_only()gives the authority no private keys at all. This is the real control.review()is a demo and test convenience: it signs on the reviewer's behalf with a key the authority holds. Its docstring says so.
The keyring is local and unauthenticated. It models the policy layer — who may sign for whom, and what combinations satisfy a quorum — not a PKI. Binding reviewer identities to real institutional credentials is out of scope for what ships here.
Append-only decision log
Certification decisions are written to the ledger. A certification cannot be silently
edited after the fact; a revocation is a new entry and the original stays visible.
Signed dispute actions are available behind require_signed_actions=True,
which is off by default — unsigned actions are recorded with
actor_authenticated: false rather than rejected, so the log tells you how
much each entry is worth.
Promotion into the next base version additionally requires that the model be merge-eligible under its model-family contract, above the published evaluation thresholds, and board-approved. proposed
Disputes, decided by rule proposed
The point of writing this down in advance is that the hard cases are decided by a rule rather than by whoever is loudest. A concrete case:
Institution A submits a strong model. Institution B finds it underperforms for Black patients. Institution C suspects privacy leakage. The charter already answers:
- Who reviews: the bias auditor and the privacy screen.
- What blocks release: unresolved subgroup harm, or demonstrated leakage.
- What A may do: remediate and resubmit; a blocked submission is not a permanent rejection.
- What is recorded: every decision and its rationale, logged publicly.
Contributors may appeal any decision to the advisory board. A code of conduct governs behavior and is enforced through the same path.
Roles and advancement
| Role | May | Becomes |
|---|---|---|
| Consumer | Download and fine-tune certified models; verify lineage | Contributor, by having a model or code contribution accepted |
| Contributor | Submit models and code; vote on matters open to contributors | Trusted reviewer, by published criteria on review quality and volume |
| Trusted reviewer | Sign certifications on behalf of their institution | Maintainer, by nomination and board approval |
| Maintainer | Merge code, cut releases, act on security reports | — |
A documented succession plan is required to survive any individual's departure, including the founding maintainer's. A project whose bus factor is one is not a commons.
Neutrality and ownership proposed
No single university permanently controls the ecosystem. Code, models, and the project name are to be held by a neutral post-award home, and anti-capture rules bar any single institution or company from holding a board majority.
Industry participants may advise and may donate compute. Donated compute must be non-exclusive, and an industry advisor holds no governance vote.
Licensing
- Code: Apache-2.0. Contributors agree their contribution is licensed under Apache-2.0; a formal Developer Certificate of Origin sign-off is proposed, not yet required.
- Models: proposed a reciprocal, OpenRAIL-style license, backed by a service-reciprocity rule — downloads require lightweight registration, so review services and the next base version are genuinely withholdable from a party that takes without contributing.
Whether silent internal deployment (a site using certified models indefinitely without contributing back) should be permitted is an open scoping question, deliberately not yet answered.
Vulnerability response
Report vulnerabilities privately by opening a GitHub security advisory, as described in SECURITY.md — not in a public issue. SECURITY.md states the current commitment: reports are acknowledged within a few business days. A standing response team with published remediation timelines is proposed, not yet in place.
Because a compromised model in this ecosystem is a patient-safety problem and not only an accuracy problem, security reports take precedence over feature work.
Sustainability proposed
The ecosystem is intended to outlive any single grant, as a community-governed commons under a neutral home. The operating cost model covers hosting, per-review compute, evaluator labor, and staffing, against funding hypotheses to be tested rather than assumed:
- Automated review stays free.
- Deep clinical review is supported by institutional membership.
- Consortium sponsorship covers shared infrastructure.
- Evaluation nodes are contributed in kind, under the reciprocity rule.
Disagree with something here? That is the point of publishing it in draft. Open an issue and argue the case in public.