Membership History

What It Models

History makes membership changes explainable. Temporal versions support reconstruction, revisions give staff an attributed timeline, monthly snapshots support stable reporting, and published events tell partner applications about committed changes.

Identity and Attributes

Versions carry recorded intervals rather than just business dates. Revision settlement occurs at commit, giving the timeline the same durability boundary as the write. Snapshots distinguish successive publications of a month, while business events preserve identifiers across delivery attempts.

Relationships

History describes holdings, periods and units without changing their ownership. Snapshot affiliations retain ancestry at the reporting date. Event payloads describe business changes independently of the transport rows used to deliver them.

Invariants

Attribution is checked before commit. Cache-only refreshes do not create timeline noise. Snapshot validation controls publication, and business-event insertion rolls back with its source write. These mechanisms do not establish that every possible stored fact is exposed by the timeline.

How It Is Stored and Shared

The history service implements versions, timelines and reconstruction for the broad history concept. Snapshots and Events implement its reporting and partner-delivery facets. Query permissions control dataset reads, and deletion participants remove snapshot data only during workspace removal.

Open Design Questions

The existing findings cover missing timeline details, automation attribution, reduced timestamp precision and reporting after migration. Product decisions remain open for officer access to history and event catalogue ownership and retention.