Community

The barrier to contributing here is deliberately low. You do not have to write framework code to participate — returning a model, or an evaluation of someone else's model, is a first-class contribution.

Ways to contribute

Clinical and neuroscience groups

Submit a model you have already trained. You get an independent multi-site evaluation you could not produce alone; the commons gets a model with provenance attached.

ML and robustness researchers

New attacks and defenses land as pull requests against the benchmark harness, so they are compared on common ground instead of living in a one-off paper repository.

Confidential-computing engineers

The attestor is an interface. Real TEE backends — SGX/TDX, SEV-SNP — plug in behind it without touching the rest of the system.

Clinicians and reviewers

Review submissions for clinical correctness, and help hold the fine-tuning manuals to a standard a treating physician can actually act on.

Security and compliance officers

Tell us where the provenance and audit artifacts fall short of what your institution would need before it could say yes. That feedback shapes the threat model.

Documentation and onboarding

If something in the quickstart did not work on your machine, that is a bug worth filing. Onboarding friction is treated as a defect, not a fact of life.

Your first contribution

  1. Get it running. Follow the quickstart. It should take a few minutes and requires nothing but Python and numpy. If it does not work, that is the first issue worth filing.
  2. Read CONTRIBUTING.md. It covers the development setup, the ground rules on data and dependencies, and the test expectations.
  3. Pick something small. Issues labelled good first issue are scoped so that a first-time contributor can finish them in one sitting, and each says what "done" looks like. If none are open yet, say so in an issue and one will be scoped for you.
  4. Open the pull request early. A draft PR with a question in it is more useful than a perfect PR three weeks later. We would rather redirect you at the start than at the end.

Service levels we are committing to target

These are targets, not a description of current operations. The project does not yet have a standing review board or a submission queue, so nothing below has an operating history behind it. They are published in advance so that the commitments exist before the volume does — and so you can hold us to them once it arrives.

You do thisWe respond
Open an issue or a model submissionTriaged within two business days
Submit a model for reviewAutomated quality gate reports within one week
Open a pull requestFirst review within one week; two approvals to merge
Report a vulnerability privatelyAcknowledged ahead of feature work, per SECURITY.md

If submission volume outgrows these, the honest response is to add reviewer capacity — not to quietly let the targets slip. The intent is that misses get recorded rather than absorbed.

How credit works

Most contributors here are clinicians and academics, and the incentives are built to pay in the currency those careers actually count:

  • Citation. Every accepted model gets a citable identifier and release attribution. Identifiers are currently minted locally and are not registered with an external resolver.
  • Evidence. A multi-site evaluation report is external validation — a result a single lab or hospital cannot produce alone, and one that strengthens your own papers and applications.
  • Visibility. Reviewed models will appear on the public benchmark under the contributor's name. target The benchmark harness ships and runs locally; the public instance does not exist yet.
  • Voice. Contributor standing maps to governance weight, on the ladder described in governance.
  • Reciprocity. Evaluation labor is reciprocal by rule: to receive a multi-site evaluation, a site serves as an evaluator for others. This is enforced in code, not by good manners.

Where we most need help right now

Being specific about this is more useful than a general invitation. The areas where an outside contributor would have the most leverage today:

  • A real TEE attestation backend. The shipped attestor is a software mock. An SGX/TDX or SEV-SNP implementation behind the existing interface is the single highest-value contribution to the trust plane.
  • Adaptive attacks. The benchmark harness is only as honest as the strongest attack in it. Attacks that specifically target the aggregator in use are more valuable than another defense.
  • Fine-tuning manual review. Clinicians who will tell us where the schema fails to capture what a treating physician needs to know before trusting a model.
  • Integration adapters. Making OpenMed's robust aggregator and admission gate usable from existing federated frameworks, rather than asking anyone to switch.

Contact

  • Bugs, features, questions: GitHub issues — public by default, so the answer helps the next person too.
  • Vulnerabilities: privately, per SECURITY.md. Please do not open a public issue.
  • Conduct concerns: per CODE_OF_CONDUCT.md.