Unit Affiliation

What It Models

A unit affiliation explains where a member belongs during a term: a chapter, section or another permitted unit. Its dated span supports historical rosters, officer visibility and the identification of chapter dues.

Identity and Attributes

The connection names its term, unit and unit type, its dates, primary flag and source. A purchased connection can record the dues product and paying line. Scope is computed for the reader rather than stored as an attribute of the affiliation.

Relationships

Term ownership bounds the affiliation’s life. Transfer lineage references the earlier connection so moves remain traceable. Units remain owned by Structure, and the predecessor reference itself does not enforce a one-to-one relationship.

Invariants

Date and reference constraints protect stored rows. The service checks minimums, maximums, permitted types and primary conflicts for the requested change. A direct change cannot bypass the dues requirement.

How It Is Stored and Shared

Memberships owns connections and versions. Scope queries combine units with their ancestors; checkout writes the selected set and later stamps dues lines. Structure calls Membership during a merge, and snapshots preserve the dated unit hierarchy. Transfers publish start and end events; merge deletions, re-pointings and term trimming do not publish separate affiliation events.

Open Design Questions

Multiple-primary reporting and preservation of a primary during a merge remain product questions. Portal self-service and affiliation imports are absent. An explicit end can retrospectively withdraw a row, so a promise that previously effective connections cannot be withdrawn would need additional enforcement.