Ethics — draft, seeking community input

Status: DRAFT. This document is not authoritative. We are seeking review from neuroscientists, bioethicists, and dual-use specialists. Please open an issue with the ethics-review label to contribute.

Why this document exists

OrganoidOS is software. But it is software that, when run on real wetware, controls stimulation of living biological neural tissue. That raises questions that ordinary software projects do not face:

1. Welfare. Is a cortical organoid a subject for the purpose of welfare considerations? If so, what stimulation intensities are acceptable, and for how long?
2. Attribution. When an organoid learns a task and we publish a LearningReport, who is the author of the learned behavior — the lab that trained it, the OS, the organoid itself?
3. Migration. The migration protocol produces a second culture whose behaviorally-equivalent learned state to a first. Is the second culture a “copy” for the purpose of attribution, IP, or welfare? If the source culture is subsequently euthanized, has anything been lost?
4. Dual use. Closed-loop protocols that combine stimulation with reward could in principle be used to suppress activity (e.g., persistent punishment). Is there a class of protocols this spec should refuse to support?

The spec is deliberately silent on these questions because the authors are not ethics specialists. This document is where we collect the community’s evolving answer.

Disclosures this spec already requires

These are mandatory regardless of how the questions above are answered:

• A LearningReport MUST include the HealthReport at the time of training, so downstream consumers can decide whether to trust the results (a sick culture produces misleading data).
• The published stimulation protocol format MUST disclose the intensity range and reward magnitude range of any closed-loop protocol.
• A MigrationSnapshot MUST NOT include lab-identifying metadata (cell line, dish age) in the shareable portion — only in a separate Provenance document under the originating lab’s control.

Open questions for the community

We do not have answers to these. We list them so contributors can propose them.

Q1. Is there a maximum stimulation intensity the spec should prescribe?

The biological literature has rough norms but no consensus. Cortical Labs has published intensities for DishBrain; FinalSpark has its own ranges. Should v0.2 of the spec include a non-binding recommended range, with the option for a lab to override with disclosure?

Q2. Should the migration protocol be reversible?

Currently, migration is one-way (source → target). Should the spec require that a MigrationSnapshot carry enough information that the target could be “rolled back” to its pre-migration state? This would require saving the target’s pre-migration state as well — which has its own ethical implications (we now have two snapshots of two living cultures).

Q3. Is there a class of tasks the spec should refuse to support?

For example, tasks whose only purpose is to suppress activity in the culture, rather than to learn a useful behavior. The current spec does not distinguish “learning” from “suppression”. Should it?

Q4. Who owns the weights of a trained organoid?

If Lab A trains an organoid on Lab A’s task, snapshots the state, and the snapshot is published openly under MIT, can Lab B use the snapshot to bootstrap a competing product? The MIT license covers the software; it does not necessarily cover the learned state. v0.2 should clarify.

How to contribute to this document

Open an issue with the ethics-review label. We particularly welcome review from:

• Neuroscientists with closed-loop MEA experience
• Bioethicists with subject-welfare expertise
• IP lawyers with open-source licensing expertise
• Dual-use risk specialists (e.g., from biosecurity)

We will iterate this document publicly. Versions will be tagged ethics-v0.1, ethics-v0.2, etc., with diffs in the CHANGELOG.