--- id: AREA-MBR title: Membership product_area: membership revision: 1 status: draft product_intent: proposed source_sha: rhythm-v2-docs: ca10379cd33c971f26af3422dfef95e110a1e39d services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f provenance: documented source: >- rhythm-v2-docs:specs/PRODUCT-AREAS.md#MOD-MBR-STR, MOD-MBR-MEM; rhythm-v2-docs:specs/membership/structure/MODULE.md; rhythm-v2-docs:specs/membership/memberships/MODULE.md; rhythm-v2-docs:specs/membership/ACTORS.md; rhythm-v2-docs:specs/membership/RESPONSIBILITIES.md modules: - MOD-MBR-STR - MOD-MBR-MEM owns: - >- Association units and their dated structure, membership programs and offerings, and reusable period interpretation. - >- Member holdings, periods and unit connections, with membership-specific application and purchase consequences. - >- Renewal operations, scoped member work, roster generation, membership history and monthly reporting. does_not_own: - 'CRM owns people, organizations and their relationships.' - >- Accounting owns shared products and prices; Commerce owns orders, payments and refunds. - 'Submissions owns intake answers, review stages and authoritative decisions.' - Committees owns appointments and the source of officer authority. - >- Platform owns identity and access administration, shared execution, query infrastructure and workspace lifecycle coordination. handoffs: - to: CRM what: >- Owner identity and relationships used to derive coverage; permitted contact changes. - to: Accounting and Commerce what: >- Product extensions, purchase eligibility and coverage effects associated with order obligations. - to: Submissions what: Typed membership requests and delivered review outcomes. - to: Committees what: >- Unit context and membership outcomes; appointment-derived authority supplied through Platform. - to: Platform what: >- Declared permissions, metadata, datasets, jobs, attention, communications and workspace lifecycle participation. invariants: - >- Association setup and individual membership records have separate owners within Membership. - >- Records and operations stay within their authorized workspace and any applicable narrower scope. - >- Shared period interpretation belongs to the setup module; recording and executing member-specific consequences belongs to the operations module. - >- Referenced records keep their owning application; Membership does not become the authority for identity, prices, payment or review decisions. - Membership performs no model inference in the examined modules. open_questions: - OQ-MBR-STR-008 - OQ-MBR-STR-009 - OQ-MBR-STR-010 - OQ-MBR-MEM-005 - OQ-MBR-MEM-006 - OQ-MBR-MEM-008 evidence: - 'rhythm-v2-docs:specs/PRODUCT-AREAS.md#MOD-MBR-STR, MOD-MBR-MEM' - 'rhythm-v2-docs:specs/membership/structure/MODULE.md' - 'rhythm-v2-docs:specs/membership/memberships/MODULE.md' - 'rhythm-v2-docs:specs/membership/ACTORS.md' - 'rhythm-v2-docs:specs/membership/RESPONSIBILITIES.md' --- # Membership ## Purpose and Outcomes Membership gives an association a shared account of its membership offer and the people and organizations covered by it. Customers use that account to connect national programs with local chapters, sections and regions, and to understand standing over time. The area brings association setup and member operations together while preserving a clear owner for each kind of information. The intended outcome is consistent membership meaning across staff work, officer work, reviewed applications, purchases and reporting. Setup administrators establish the context that membership operations use. Coordinators work with member records, analysts inspect recorded results, officers work within their assigned units, and signed-in members see the holdings associated with their linked contact. Connected applications consume membership facts while keeping responsibility for their own decisions and records. The corpus distinguishes that intended experience from what the examined implementation supports. The current console member list is a prototype, and several partner connections remain incomplete. A reader uses the module findings to assess those limits before treating a service interface as a complete customer journey. The overview establishes ownership and reading order; detailed requirements and evidence remain in the modules. ## Scope and Boundaries Membership owns association structure, the membership offer and the interpretation and recording of membership coverage. It also owns the operational and reporting records that explain how that coverage changes. Association units provide membership context; they are distinct from CRM organizations and from Accounting business units. CRM supplies people, organizations and relationships. Accounting supplies product identity and pricing. Commerce controls orders and settlement and asks Membership for membership-specific purchase decisions and effects. Submissions controls review and delivers outcomes for Membership to apply. Committees owns appointments that can produce officer authority through Platform. Platform supplies security, shared jobs, queries, metadata, attention, communications and workspace lifecycle coordination. These handoffs do not transfer ownership of the partner's records. ## How the Area Is Divided Organizational Structure, Membership Configuration and Terms describes the association's arrangement and the shared meaning of its membership offer and periods. Open this module when the question concerns setup ownership, unit context, offering configuration or the interpretation supplied to another operation. Its boundary ends where member-specific records and execution begin. Memberships, Applications and Membership Billing describes the records and operational work of membership. Open this module when the question concerns a particular holding, a membership request, purchase consequences, renewal operations, scoped work or evidence about membership over time. It consumes the setup module's definitions and calculations and keeps partner responsibilities visible at each service boundary. ## Area-Level Invariants Each fact has one owner. Association setup and member records stay in their respective modules, and partner records retain their application owner. Access is evaluated within the workspace and, where applicable, within the caller's unit or personal boundary. Shared period interpretation and member-specific persistence remain separate responsibilities. Neither examined module delegates a decision to a model. These are proposed area boundaries drawn from the landed charters and responsibilities. Detailed enforcement, exceptions and unresolved behavior belong to the referenced module artifacts. ## Open Ownership Questions Product still needs to choose the administration screen scope and the owner of a complete offering save spanning Membership and Accounting. Structure's findings also ask who follows through on the finance and committee work left by a unit merge and which structural outcomes other applications receive. Membership's business-event catalogue and retention require a decision with Platform integrations. CRM merge participation requires a decision about carrying membership ownership to the surviving person or organization. Application-specific answers need a settled boundary between Membership custom values and Submissions. The module questions retain these decisions and their alternatives.