##### Context
The original domain model used `AccountType` to represent all roles — mixing platform access (Admin, Ops, Support), user experience (Benefactor, Beneficiary), and plan functions (Executor) into a single enum on Account. The `Relationship` entity carried an `IsExecutor` flag with `ExecutorPriority` to handle plan activation.

Analysis of the Rempla prototype (Matt Kelly's POC) revealed a richer model: people hold structural relationships, functional plan roles, and legal estate designations — all independently. The existing model couldn't represent a person who is simultaneously someone's daughter (relationship), gift recipient (plan role), and trust beneficiary (estate designation) without conflation.

Additionally, the platform needs to support multiple entry points (Benefactor, GiftRecipient, PlanProtector, Beneficiary) where users accumulate experiences over time, and the original AccountType couldn't express this journey.

##### Decision
Adopt a **person-centric architecture** with three independent edge types and timestamped user types.

**Person is the universal node.** Account is the auth/login wrapper. A Person can exist without an Account.

**Three independent Person→Person edges:**

| Edge | Purpose | Values |
|------|---------|--------|
| **Relationship** | Structural — how connected | Spouse, Child, Friend, Grandchild, Sibling, etc. |
| **RemembrancePlanRole** | Functional — gift/remembrance plan | GiftRecipient, PlanProtector, DigitalLegacyBeneficiary |
| **EstateDesignation** | Legal — fiduciary position | Executor, Trustee, TrustBeneficiary, BequestRecipient, Fiduciary |

Each edge is independent (no FK between them), composable (any combination), and multi-plan (a person can hold roles across multiple plan owners).

**UserType + AccountUserType** replaces AccountType for the main application. Timestamped join table — origin is derived from earliest `AcquiredAt`. Values: Benefactor, GiftRecipient, PlanProtector, Beneficiary.

**AdminRole** (Support, Ops, Admin) is separated entirely — scoped to Rempla.Admin only.

**Removed from Relationship:** `IsExecutor`, `ExecutorPriority` — now covered by RemembrancePlanRole (PlanProtector) and EstateDesignation (Executor).

##### Rationale
- **Clean separation of concerns**: structural, functional, and legal roles never conflate. Being someone's daughter doesn't automatically make you a gift recipient or executor — those are separate, intentional decisions.
- **Supports the growth funnel**: a GiftRecipient can organically become a Benefactor without role conflicts. The timestamped UserType tracks the journey.
- **Proper legal terminology**: estate designations use the term "designation" (industry standard) rather than "role."
- **Admin decoupled from UX**: no risk of confusing portal access with user experience.
- **Composability mirrors reality**: in the Rempla prototype, a single tree node (e.g., Robert) holds relationship (Son), plan roles (GiftRecipient), and estate designations (Executor + BequestRecipient) simultaneously.

##### Consequences
- More entities in the Identity bounded context: UserType, AccountUserType, AdminRole, RemembrancePlanRole, RemembrancePlanRoleType, EstateDesignation, EstateDesignationType
- Querying "everything about a person in someone's plan" requires joining across Relationship, RemembrancePlanRole, and EstateDesignation
- UI must compose the three edge types into a unified view (e.g., planning tree nodes show all three)
- EstateDesignation may need additional fields as features mature (e.g., conditions on TrustBeneficiary, asset descriptions on BequestRecipient)

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