Households and Membership Coverage

What This Record Is

Proposes how Rhythm 2.0 CRM should record households (the group an organization mails and recognizes as one unit), person-to-person relationships such as spouse or guardian, and who a membership covers and why, for museums, churches, fundraising shops and family clubs. Andrew ruled all nine decisions on 2026-10-21 (six as recommended, three changed: CRM-owned relationship tables, a household may hold a membership, implementation deferred until a signed customer needs it); nothing is built.

(Summary from the Rhythm 2.0 Architecture Library card; the parts below are the proposal's own text, converted verbatim.)

Parts

1. Households, Constituent Relationships, and Membership Coverage: Research and Architecture Recommendation: Status: **proposed 2026-10-21; all nine decisions ruled by Andrew the same day (chapter 14 "Rulings"); implementation
2. 01. Executive Summary: Part of Households, Constituent Relationships, and Membership Coverage.
3. 02. The Architectural Problem and Why It Matters: Part of Households, Constituent Relationships, and Membership Coverage. Terms used in every household
4. 03. Rhythm 1.0 Functionality and Lessons Learned: Part of Households, Constituent Relationships, and Membership Coverage. Evidence:
5. 04. Rhythm 2.0 Design Constraints: The Existing Architecture, Assessed: Part of Households, Constituent Relationships, and Membership Coverage. Evidence reports, each with
6. 05. Competitive Research: Part of Households, Constituent Relationships, and Membership Coverage. Six research reports hold every
7. 06. Cross-Industry Requirements and Use Cases: Part of Households, Constituent Relationships, and Membership Coverage. Across the brief's scenarios,
8. 07. Alternative Architecture Models: Part of Households, Constituent Relationships, and Membership Coverage. This chapter evaluates the five
9. 08. Tradeoff and Decision Matrix: Part of Households, Constituent Relationships, and Membership Coverage. A. Recommended hybrid is the
10. 09. Recommended Domain Model: Part of Households, Constituent Relationships, and Membership Coverage. Chapters
11. 10. Proposed Data Model and Service Boundaries: Part of Households, Constituent Relationships, and Membership Coverage. The model is chapter
12. 11. Membership Coverage and Benefit Inheritance Strategy: explicit beneficiary rows, whether designated by a person or derived from CRM facts. Package rules determine who
13. 12. Migration and Implementation Implications: Part of Households, Constituent Relationships, and Membership Coverage.
14. 13. Risks and Unresolved Questions: Part of Households, Constituent Relationships, and Membership Coverage.
15. 14. Architecture Decisions Requiring Approval: Part of Households, Constituent Relationships, and Membership Coverage. HC-D1 to HC-D9 require Andrew's
16. A1. Household Lifecycle Rules: Part of Households, Constituent Relationships, and Membership Coverage. The tables are in
17. A2. Household 360 and the Console Experience: Part of Households, Constituent Relationships, and Membership Coverage. Evidence:
18. A3. Cross-Application Integration: Part of Households, Constituent Relationships, and Membership Coverage. Evidence:
19. A4. Security, Privacy and Authorization: Part of Households, Constituent Relationships, and Membership Coverage. Evidence:
20. A5. Testing Requirements: Part of Households, Constituent Relationships, and Membership Coverage. Tests follow the Rhythm standards
21. R1 — Rhythm 2.0 CRM macroservice: what a Households / Relationships / Family-membership proposal can build on: Written 2026-10-21 04:30 ET. Read-only research; nothing in any repository was changed.
22. Rhythm 2.0 Membership: what exists today, read for the household-membership proposal: Written 2026-10-21 from ~/rhythm2/services-membership master fcbddf2 (primary checkout, branch master), the
23. R3. How the money-handling and engagement applications identify the person or organization: Research for the Households proposal (households = groups of related people, with household memberships). Question
24. R4 — Platform primitives for Households, person-to-person relationships and family memberships: Read-only research of the Rhythm 2.0 Platform macroservice, written 2026-10-21 for the CRM Households proposal.
25. R5 — Console and portal architecture for Households (research report): Written 2026-10-21 04:30 ET. Read-only; nothing was modified. Every claim carries a label: Implemented (read in
26. R6 — Rhythm 1.0 precedent for households, families and person-to-person links: Research for the Rhythm 2.0 household architecture. Read-only pass over ~/rhythm (Rhythm 1.0 production code), the 2.0
27. R7 — Rhythm 1.0 relationships, membership flowdown and eligibility, precisely: Extends /Users/andrew/rhythm2/briefs/households/research/r6-rhythm1.md (R6). R6 established the inventory (what
28. W1 — How Blackbaud products model households, family relationships and family memberships: Research brief for the Rhythm 2.0 "Households" architecture proposal. Written 2026-10-21 (ET) from public sources only.
29. W2 — How NetForum and iMIS model households, family relationships and family memberships: Research input for the Rhythm 2.0 "Households" architecture proposal. Written 2026-10-21 from public sources only.
30. Households in nonprofit and association software: Salesforce NPSP, Salesforce Nonprofit Cloud, Tessitura, and eight smaller CRMs: Research for the Rhythm 2.0 Households architecture proposal. Written 2026-10-21.
31. W4 — Association-management platforms: households, constituent relationships and membership coverage: Research date: 2026-10-21. Scope: Fonteva, Nimble AMS, MemberSuite, GrowthZone (ChamberMaster lineage), YourMembership,
32. W5 — Museum, zoo, aquarium, garden and cultural-institution membership platforms: Research brief for the Rhythm 2.0 households / constituent relationships / membership coverage architecture. Written
33. W6 — Church management and community/alumni platforms: households, relationships, giving units, guardian authorization: Research memo for the Rhythm 2.0 households / constituent-relationship / membership-coverage architecture