Schema.org compliance

Schema.org is a great way to define these objects, but I would think that how they appear on the internet/in the HTML would be less important for a CRM than compatibility with someone hoping to extend the project's core features. As you start looking at data standards for CRMs, it is also worth looking Salesforce's standards. I'm most familiar with https://help.salesforce.com/s/articleView?id=sfdo.education_data_archite... as EDA support is often how the Salesforce Managed Packages targeting higher ed use cases differentiate themselves as being something that works well together in a common, EDA ecosystem vs. needing to define every object itself.

If you search https://appexchange.salesforce.com/appxSearchKeywordResults?keywords=EDA for packages that claim to support the EDA standard, you will be able to mix and match EDA-compatible packages with your own custom development with little risk of updates to one package requiring updates to all others due to schema changes.

If you go with something like https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A0000..., you are limited to only using other KindSight packages and run the risk of KindSight changes breaking any customizations you build.

The equivalent in early Drupal distributions was Phase2's Open Atrium project management distribution. While it was possible to extend Open Atrium installs with additional contrib modules and custom features, it was discouraged. The only modules Phase2 would even attempt to support were the modules included in the distribution. This allowed the Phase2 developers to make major changes that only required testing updates within the context of a standard Open Atrium install, but limited to potential use of the distribution to organizations that found Open Atrium's features "out of the box" a good fit for their needs. Extending and customizing Open Atrium was risky.

If you are paying attention to the roadmaps and change communication, building on the core Drupal CMS (not to be confused with Drupal CMS) or Salesforce CRM today, customization has little risk of expensive debt.

All of that said, I REALLY like where you are going with this project!

I think relevant adherence to Schema.org makes sense. While the CRM project itself doesn't expose CRM entities to the public, it is possible that the metadata would be used by some tool that does have access to the content OR (more likely) modules in the greater CRM ecosystem might expose CRM entities to the public. For example, Member Platform might (optionally) expose some fields of members' Contact entities in a public-facing member directory.

I appreciate the commentary on Salesforce's data standards, with which I am unfamiliar. We would do well to formulate a clear strategy for interoperability among CRM ecosystem modules (as well as migration paths from other CRMs' well known field schemas). The most obvious area for which to do this is coherent sets of fields, but I'm not sure where that should live or what the best first steps are. @kreynen, please do open a separate issue if you're interested in helping with such a strategy!