##### Context
The Add Member modal needs to present relationship types in a meaningful, grouped dropdown rather than a flat list. The UI also needs to suggest relevant important dates (birthday, anniversary, etc.) based on the selected relationship type. Previously, relationship types had no grouping mechanism, and Son-in-Law/Daughter-in-Law were stored as custom labels with null RelationshipTypeId, which caused sorting bugs (defaulting to Level=0, SortIndex=0 and appearing above siblings).

Additionally, the system needed a way to know which date types (occasions) are meaningful for each relationship type — e.g., a child's birthday and graduation, a spouse's anniversary and wedding date.

##### Decision

**RelationshipTypeGroup as a lookup table.** Grouping is stored in its own table with Id, Name, and SortIndex rather than as a string column on RelationshipType. This allows the UI to query groups independently and sort them consistently.

Seeded groups:
- Immediate Family (SortIndex 0)
- Extended Family (SortIndex 1)
- Other (SortIndex 2)

RelationshipType gains a `RelationshipTypeGroupId` FK (replacing the old string `Group` field) and a `SortIndex` column for sub-level ordering within the same Level.

**DateType and RelationshipTypeDateType.** DateType is a standalone lookup table (Id, Name, SortIndex) seeded with: Birthday, Anniversary, Wedding, Baptism, Graduation, Retirement, Ordination. The junction table RelationshipTypeDateType (Id, RelationshipTypeId, DateTypeId) maps which date types are relevant for each relationship type.

Memorial was considered as a date type but excluded — gifts go TO living people, and memorial occasions don't fit the "important dates for this relationship" model.

**Proper in-law and extended family types.** Son-in-Law and Daughter-in-Law are now first-class RelationshipTypes (Level=1, SortIndex=1, Extended Family group) rather than custom labels. Cousin, Nephew, Niece (Extended Family) and Godchild (Other, IsFamily=false) are also added as seeded types.

**Custom/Other relationships default to non-family.** Relationships with null RelationshipTypeId (custom label) default to IsFamily=false and appear in the Extended Planning Network, not the family tree.

**Extended family connects to immediate family.** Extended family members (e.g., grandson, son-in-law, nephew) are saved as relationships to the relevant immediate family member (e.g., grandson to son, nephew to brother), not to the account owner. The tree service computes their label relative to the owner by walking the relationship chain. This keeps the data model structurally accurate and leverages the chain computation from ADR-006.

##### Rationale
- **Grouped dropdown**: RelationshipTypeGroup as its own table is cleaner than a string column — supports sorting, future groups, and independent querying
- **Date suggestions**: Driving date chips from a junction table keeps the logic data-driven rather than hardcoded in the UI
- **No Memorial**: The date type model is about occasions tied to a living person's relationship; memorial is a plan-level concern, not a relationship-level one
- **Proper in-law types**: Eliminates the sorting bug where null RelationshipTypeId defaulted to Level=0/SortIndex=0; gives in-laws proper placement in the tree hierarchy
- **Extended-to-immediate connection**: Matches how families actually work (a grandson is a child's child) and enables accurate chain computation without storing redundant owner-level relationships

##### Consequences
- All existing custom in-law relationships need migration to the new proper RelationshipTypes
- The Add Member modal must filter the dropdown dynamically (exclude ancestors, hide spouse if one exists, show "Connected to" options based on selected type)
- DateType seed data may grow over time — the junction table approach scales without code changes
- Custom relationships are permanently non-family; there is no UI path to promote a custom relationship into the family tree

---
**Decision Date**: March 27, 2026
**Author**: Joshua Angulo