The entity model
Everything scientific data can be across Commonscience — a compound, an experiment, a notebook entry, a calculation result — is designed to be modeled the same way: as an entity.
An entity is Commonscience's model for anything that counts as scientific data: a compound, an experiment, a notebook entry, a calculation result, and more. Every entity is designed to carry the same base information — who created it, how (typed by hand, computed, imported, AI-generated, or synced from elsewhere), and what it depends on. That shared shape is what's meant to let any client apply the same provenance and compliance handling everywhere, instead of re-deriving it per feature. Today only a handful of entity types (project, org, user) are live in GUIDE, the first client built on this model; the rest of this page describes the architecture the wider entity model — compounds, experiments, and the rest — is designed to grow into.
The entity model is designed so a new entity type is added by registering a config — its fields, its compliance requirements, its provenance level — rather than by writing a new code path for it. That's the architectural intent the entity system is built around; not every entity type has been registered yet, but the mechanism is designed to make adding one a configuration change, not a rewrite.
Whenever an entity changes, the model is designed to record that change as an event, not just overwrite the old value. Events are designed to be ordered and append-only, so an entity's full history — who changed what, when, and how — can be reconstructed from the event record itself, without relying on anyone's memory or a separate audit process bolted on afterward. This mechanism is furthest along for projects today; extending it to every entity type is part of what the model is designed to grow into. This substrate is what's meant to make the GitHub for Science lifecycle possible.