@tsalo I am currently experimenting with the schema and think it would be better to have the entities as an array at the top level of the entities.yaml files.
Example:

subject:
  name: Subject
  entity: sub
  description: |
    A person or animal participating in the study.
  type: string
  format: label

would become

- name: subject:
  **label**: Subject
  **key**: sub
  description: |
    A person or animal participating in the study.
  type: string
  format: label

It is also a bit confusing to have the whole object being called an "entity", then have one of its properties also named "entitiy".
Instead use name/label/key to differentiate between those aspects.

I am currently experimenting with the schema and think it would be better to have the entities as an array at the top level of the entities.yaml files.

I really would prefer to separate the object definitions into separate files. Hypothetically, we could have one YAML file for each type of object (metadata fields, data types, suffixes, etc.), but I would like to avoid massive files for now. While entities.yaml isn't currently very large (and probably won't ever be), I'm leaning toward splitting it up to match our convention for other, similar objects, like the metadata fields.

It is also a bit confusing to have the whole object being called an "entity", then have one of its properties also named "entitiy".
Instead use name/label/key to differentiate between those aspects.

That's reasonable. I know that others have raised concerns with the field names in the entity definitions. I'd prefer to have that in a separate PR though, since hopefully this one will be more about reorganization and the addition of rules than redefining the objects.

I'm closing this in favor of a more limited version that doesn't include pseudo-code rules.