The Erde data model
Erde organizes environmental data along two scopes that meet in the records you work with every day. A Site is the spatial scope — a physical place under management. A Project is the work scope — a unit of work. Field structure hangs off the Site; samples and lab data hang off the Project; the two connect where a Project investigates a Site. This page maps that spine so the rest of the documentation has a shared vocabulary.
The spine of the model
Two hierarchies grow from the two scopes and join through the Sample.
A Site contains Locations — the points and features you monitor. Each Location may be realized as a physical artifact: a Well, a Borehole, a Test Pit, or a Sediment Core.
A Project owns Samples and Lab Reports. A Sample is collected at a Location; a Lab Report groups the Lab Analyses run on its samples, and each analysis carries its Lab Results. A Program sits above Projects, grouping them into a longer-running effort.
Figure: the core hierarchy. A Project spans many Sites (and a Site many Projects); the Sample is where field structure and lab data meet.
A few relationships are looser than they look. A Project and a Site form a many-to-many link, so one Project can investigate several Sites and one Site can belong to several Projects. A Program links only to Projects (a Project can belong to more than one Program) — Sites relate to a Program transitively, through its Projects. A Lab Analysis anchors to a Sample, to the lab's own report sample, or to both; lab quality-control rows belong to a report without a field Sample. Test Pits, Sediment Cores, and the other artifact types are shown trimmed here so the diagram stays readable.
Aggregate roots and their children
Every record in Erde is an entity with a stable, client-facing External ID (a time-ordered UUID) and audit fields that record who created and last changed it. Entities are grouped into aggregates: a parent record — the aggregate root — together with the child records it owns. Erde validates, saves, and audits each aggregate as one unit.
Sites, Projects, Locations, Wells, Samples, Lab Reports, Lab Analyses, and Lab Results are all aggregate roots. Their children — a Well's casing intervals, a Lab Report's samples and batches — exist only inside their parent and are created, edited, and deleted through it. A child is attached to exactly one aggregate and never moves to another.
| Aspect | Aggregate root | Child record |
|---|---|---|
| Identity | Has its own External ID and detail page | Has an External ID; reached through its parent |
| Lifecycle | Created and deleted on its own | Created, edited, and deleted with the parent |
| Scope | Carries Site and/or Project scope | Inherits its parent's scope |
| Example | Site, Project, Sample, Lab Report | Casing interval, Lab Batch, Site area |
This grouping is what makes locking and the audit trail work: lock a Project and every aggregate scoped to it is frozen as a set. See Aggregates, locking, and auditing for that depth.
Related
- Sites and Projects — the two scoping axes in detail, and where Programs fit.
- Aggregates, locking, and auditing — how aggregates are locked and audited as a unit.
- Sites & Locations — working with Sites, Locations, and field artifacts.
- Laboratory Data — Lab Reports, Analyses, Results, and validation.