mono.profile rows with role enrollee), invited on the Users & roles Screen. The experimenter has the experimenter or admin role.name, then hand-pick the people, optionally a notes line, and Save. Groups are always explicit rosters, so who is in a run is exact and reproducible.cohort row plus one cohort_member row per person is written. The group is a shared, reusable pool: any run can target it, and the same person may be in several groups. The one hard rule is enforced later, at launch: two runs that are live at the same time must target non-overlapping groups.cohort, cohort_member| If… | Then… |
|---|---|
| The name is already in use | Refused on save: cohort.name is unique across the install. |
| Any run references the group | Its name and membership are read-only and it cannot be deleted (RESTRICT); only notes stays editable. To run a changed roster, clone the group, so every run's enrollees stay exactly reproducible. |
| The same person is placed in two groups | Allowed. Overlap is checked only at launch, when a second concurrent run would target overlapping people (Launch a Run). |
cohort and N cohort_member rows exist and the group appears in the launch picker.A cohort, also called an enrollee group, is a named list of people you want to run a study on, the equivalent of a class roster.
You hand-pick the people you want. Groups are reusable: build one once and point many runs at it.
One rule matters, and it applies only when runs are live at the same time. The same person cannot be in two running studies at once, or their answers would be shaped by two different conditions. You can still reuse a group over time, just not simultaneously.
cohort; membership is cohort_member. The disjoint-cohort rule is a launch-time check, not a stored field.