Responsible use / Open-Robust Lab
What our work
is for.
Everything the lab releases is a research artifact. This page states what that means for how you can use it, what we ask you not to do with it, and how to tell us when something goes wrong.
Last updated 6 August 2026
Everything here is research
Open-Robust Lab publishes research artifacts: code, and in future models, datasets, and demos. They exist to support research, education, and reproduction of our results.
They are not production systems. They have not been through safety certification, security review, or the kind of testing a deployed product needs. Treat every artifact as a starting point for your own evaluation, not as something ready to put in front of users.
Licensing comes first
Each artifact carries its own license, stated in its own repository. Code, model weights, and datasets frequently have different terms, even within a single project.
The artifact's own license governs. Nothing on this website grants you rights to an artifact, and nothing here overrides or loosens the terms attached to it. If this page and a license disagree, the license wins.
If an artifact has no stated license, it is not licensed for reuse. Ask before building on it.
Uses we ask you to avoid
Beyond whatever a specific license requires, we ask that you do not use the lab's artifacts for:
- Surveillance or biometric identification of people without their informed consent.
- Generating deceptive media about real people, or content presented as authentic when it is synthetic.
- Safety-critical or clinical decision-making. Nothing the lab publishes is validated for medical, legal, financial, or safety decisions about individuals.
- Harassment, targeting, or profiling of individuals or groups.
- Any use that violates the artifact's own license.
Individual releases may add further restrictions in their model or dataset cards. Those apply on top of this list.
Limitations are part of the release
Every research project on this site documents its known limitations, its intended use, and where it falls short. Those sections are not boilerplate — they are the parts most worth reading before you build on something.
A model that performs well on a benchmark can still fail badly under distribution shift, on inputs unlike its training data, or on populations the training data underrepresents. Where we know about such failures, we publish them.
Reporting a problem
Problematic model outputs or data
If an artifact produces harmful output, contains data that should not be there, or behaves in a way its documentation does not describe, open an issue on the relevant repository on GitHub or Hugging Face.
Include what you did, what happened, and what you expected. If the output itself is sensitive, describe it rather than reproducing it.
Personal data in a dataset
If you believe a dataset contains your personal data, or data that should not have been collected, tell us and we will investigate. Reports of this kind take priority over everything else.
Security vulnerabilities
Report security issues privately through GitHub's security advisory flow rather than in a public issue. See the organization's security policy for details.
For anything that does not fit the above, use the Email the lab link.
What we commit to
- Documenting intended use, limitations, and licensing for every release.
- Publishing failure cases and negative results, not only successes.
- Correcting the record when we get something wrong.
- Responding to reports about harm or personal data as a priority.
The lab is small and volunteer-run, so we cannot promise a fixed response time. We can promise that reports get read.