Findings and Open Questions: Membership → Memberships, Applications and Membership Billing
Findings record disagreements between the code, the records and the documentation, behaviour nobody wrote down, and debt. Each finding's evidence is in the frontmatter. Open questions are the material product decisions this module needs; routine choices were made and recorded as assumed.
Findings
| Id | Severity | Statement | Affects | Evidence | Kind |
|---|---|---|---|---|---|
FND-MBR-MEM-001 | medium | No membership milestone record or milestone plan exists. Product intent rests on Andrew's final acceptance of 18 October 2026 and on the dated decisions the phase records carry. The architecture's decision register was outside what this job could read, so rules that only an architecture chapter states are recorded by reference. | MOD-MBR-MEM | Structured evidence | inconsistency |
FND-MBR-MEM-002 | low | The registered scope names the structure's bulk loads, which belong in substance to the structure module and the data job engine. It also omits the records where this module's behaviour is written down: the service overview, the phase records, the attention account, the service-level registrations and the end-to-end suite. The corrected row lists them. | MOD-MBR-MEM | Structured evidence | inconsistency |
FND-MBR-MEM-003 | high | No console screen administers memberships through the service. The only membership page, Members, lists 52,340 synthetic members generated by the server-side prototype store, and no console page calls a Membership operation. Every staff, officer and portal surface named in this module is therefore an API surface today. | MOD-MBR-MEM, JNY-MBR-MEM-001, JNY-MBR-MEM-004, JNY-MBR-MEM-005, JNY-MBR-MEM-006 | Structured evidence | debt |
FND-MBR-MEM-004 | medium | The acceptance journeys run in process against the API; none runs in a browser. At their last recorded run, many journeys of these areas had failed or were blocked. In memberships 6 failed and 3 were blocked, in affiliations 5 failed and 5 were blocked, in commerce 17 failed and 7 were blocked, and in billing 2 failed and 3 were blocked. In security 6 failed and 4 were blocked, and in history 15 failed and 2 were blocked. Bound acceptance scenarios therefore prove only what their journey's last run passed. | MOD-MBR-MEM | Structured evidence | debt |
FND-MBR-MEM-005 | low | The acceptance defect register lists as open several defects the pinned code repairs. These are a catch-all dues product never being recognised, an addition racing a merge, a withdrawn tie that a transfer continues, and an officer changing ties of a membership they cannot see. | CAP-MBR-MEM-007, CAP-MBR-MEM-015 | Structured evidence | inconsistency |
FND-MBR-MEM-006 | medium | The acceptance inventory's area code for memberships produces capability identifiers identical to this module's own capability identifiers, with different meanings. This corpus records every inventory identifier with an "inventory:" prefix in its supersedes lists. | MOD-MBR-MEM | Structured evidence | inconsistency |
FND-MBR-MEM-007 | low | The inventory's business rules of these areas (about 250) are absorbed through the capabilities that supersede their inventory capabilities, not traced rule by rule. Its open decisions are folded into this module's findings and open questions. | MOD-MBR-MEM | Structured evidence | debt |
FND-MBR-MEM-008 | high | Adding a term locks the membership but not its owner. Two terms added at the same moment in two programs of one exclusivity group can both commit, leaving the owner in two exclusive programs at once. | CAP-MBR-MEM-002, BR-CAP-MBR-MEM-002-06 | Structured evidence | defect |
FND-MBR-MEM-009 | medium | Two undated renewals of one membership sent at the same moment both succeed. The second continues from the first's new term and books a further year. | CAP-MBR-MEM-002, BR-CAP-MBR-MEM-002-07 | Structured evidence | defect |
FND-MBR-MEM-010 | high | A correction checks overlap within the membership only and never the exclusivity group, so a correction can extend a term over the owner's term in an exclusive sibling program. | CAP-MBR-MEM-003, BR-CAP-MBR-MEM-003-03 | Structured evidence | defect |
FND-MBR-MEM-011 | medium | A correction that moves a term's start earlier leaves its chapter ties starting on the old date. On the days between, the member holds a term without the chapters the package requires. | CAP-MBR-MEM-003, BR-CAP-MBR-MEM-003-05, CAP-MBR-MEM-007 | Structured evidence | defect |
FND-MBR-MEM-012 | low | Rows written in one step are read back in no stable order when they share a millisecond. This affects a transaction's lifecycle events and a billing plan's actions, so the business log and the execution order of a run are not stable. | CAP-MBR-MEM-005, CAP-MBR-MEM-013 | Structured evidence | defect |
FND-MBR-MEM-013 | high | The program's "grace confers benefits" setting, decided as on by default, is stored and validated but never read. A member in grace never has member rights through it. | CAP-MBR-MEM-005, BR-CAP-MBR-MEM-005-11 | Structured evidence | inconsistency |
FND-MBR-MEM-014 | medium | Deleting a membership whose term is the source of a granted term silently detaches the granted term instead of refusing. The migration's foreign key sets the source to empty, which the table definition does not say. | CAP-MBR-MEM-006 | Structured evidence | defect |
FND-MBR-MEM-015 | medium | A workspace reset after a failed import removes memberships, terms and events but keeps their versions and change history. The reset workspace still reports history for memberships it no longer has. | CAP-MBR-MEM-018 | Structured evidence | defect |
FND-MBR-MEM-016 | high | Memberships are declared to carry custom fields, and their values are stored, versioned, captured in history and frozen in snapshots. No operation or import can write a value, so a customer who defines a field cannot fill it. | CAP-MBR-MEM-001, BR-CAP-MBR-MEM-001-13 | Structured evidence | inconsistency |
FND-MBR-MEM-017 | high | Imports do not apply the checks a staff creation applies. They accept an organization in a program for people, a deactivated program, type or package, and a retired product. A term upsert also trusts the record identifier it is given and can rewrite another member's term. | CAP-MBR-MEM-001, BR-CAP-MBR-MEM-001-12 | Structured evidence | defect |
FND-MBR-MEM-018 | medium | A membership's settings (do not renew, do not drop, directory opt-out, auto-renew), its join date and its owner cannot be changed after creation; no operation exists, and the owner-transfer permission is deliberately not declared. | CAP-MBR-MEM-001 | Structured evidence | undocumented |
FND-MBR-MEM-019 | medium | When CRM moves an organization out from under a member organization, only the moved organization's new ancestors are re-derived. Its people keep the membership the former parent gave them. | CAP-MBR-MEM-006, BR-CAP-MBR-MEM-006-10 | Structured evidence | defect |
FND-MBR-MEM-020 | low | After a corporate type's flow-down is switched off, a child kept by an assigned seat still says it flows down. | CAP-MBR-MEM-006 | Structured evidence | defect |
FND-MBR-MEM-021 | medium | CRM must add Membership's change handler to its own subscription list, and that is CRM's change. Until CRM does, flow-down children in a deployed workspace never react to role or organization changes in CRM. | CAP-MBR-MEM-006, BR-CAP-MBR-MEM-006-09 | Structured evidence | debt |
FND-MBR-MEM-022 | medium | The program's portal rule for members' own chapters is stored and stated, but no portal route lets members change their chapters. | CAP-MBR-MEM-007, BR-CAP-MBR-MEM-007-14 | Structured evidence | undocumented |
FND-MBR-MEM-023 | high | After a package's chapter maximum is narrowed below what a member holds, every change to the member's chapters is refused, including one that brings them back within the rule. The refusal names the wrong date and count. | CAP-MBR-MEM-007, BR-CAP-MBR-MEM-007-13 | Structured evidence | defect |
FND-MBR-MEM-024 | low | Adding and ending a chapter tie records no lifecycle event, although the event list declares both and other applications are told through business events. Only a transfer and a merge appear in the membership's business log. | CAP-MBR-MEM-007 | Structured evidence | defect |
FND-MBR-MEM-025 | medium | When a unit type allows several primaries, the past-date read names the earliest-starting primary of a type, while the reporting function names the latest-starting. | CAP-MBR-MEM-007, CAP-MBR-MEM-018, CAP-MBR-MEM-019, OQ-MBR-MEM-001 | Structured evidence | inconsistency |
FND-MBR-MEM-026 | high | No import loads chapter ties, and the imported term carries none. Every migrated member therefore holds no chapter. An imported member's first renewal order on a package with a chapter minimum fails, and imported chapter rosters are empty. | CAP-MBR-MEM-001, CAP-MBR-MEM-007, CAP-MBR-MEM-013 | Structured evidence | undocumented |
FND-MBR-MEM-027 | medium | When a member's merged tie was primary and their tie with the survivor was not, the survivor tie keeps its own flag. The member has no primary of that kind from the merge until staff set one. | CAP-MBR-MEM-008, BR-CAP-MBR-MEM-008-10, OQ-MBR-MEM-002 | Structured evidence | undocumented |
FND-MBR-MEM-028 | medium | A merge states a business event only for the ties it transfers. Ties it ends, withdraws or re-points are recorded in the business log but announced to no other application. The events record still says a merge moves nothing. | CAP-MBR-MEM-008, BR-CAP-MBR-MEM-008-09, CAP-MBR-MEM-020 | Structured evidence | defect |
FND-MBR-MEM-029 | high | Amendments are not built, either the preparation of a change or its application. Mid-term upgrades and downgrades, transfers with dues and moves into dues-charging chapters can only be refused today. | CAP-MBR-MEM-008, CAP-MBR-MEM-009, BR-CAP-MBR-MEM-008-02 | Structured evidence | undocumented |
FND-MBR-MEM-030 | critical | Commerce's placement transaction is refused at commit. The reservation names its writer's source as Commerce, which the change history does not accept, so the history write fails and the whole placement rolls back. | CAP-MBR-MEM-009, BR-CAP-MBR-MEM-009-14, JNY-MBR-MEM-002 | Structured evidence | defect |
FND-MBR-MEM-031 | medium | A renewal bought without naming chapters writes the carried chapters as chosen on an application rather than as inherited. A package line naming the same chapter twice is accepted and reserved, and then every fulfilment fails. | CAP-MBR-MEM-009, BR-CAP-MBR-MEM-009-15 | Structured evidence | defect |
FND-MBR-MEM-032 | medium | A unit deactivated between preparation and fulfilment can never be reactivated, so a purchase naming it can never be fulfilled. | CAP-MBR-MEM-009 | Structured evidence | defect |
FND-MBR-MEM-033 | low | The Commerce participant departs from the architecture in documented ways. A denial is answered as unavailable with a code, and the reservation writes the pending term but not its grants or chapters. Dues and grant lines carry a payload of their own, and the cancellation policy is the program's, not the package's. | CAP-MBR-MEM-009, CAP-MBR-MEM-010 | Structured evidence | inconsistency |
FND-MBR-MEM-034 | high | Voiding an order whose line was already fulfilled answers as if Membership never knew the line. Commerce is not told the reservation was kept because it was committed. | CAP-MBR-MEM-010, BR-CAP-MBR-MEM-010-08 | Structured evidence | defect |
FND-MBR-MEM-035 | low | A cancellation of a line whose term is already closed is denied as "no claim" instead of "already cancelled". | CAP-MBR-MEM-010 | Structured evidence | defect |
FND-MBR-MEM-036 | high | Four connections to other applications are stubs that refuse: Commerce's order placement, the Submissions acknowledgement, Commerce's order lines and CRM's contact update. In a deployed workspace, approvals cannot order dues and billing runs cannot place renewal orders. Officers' orders, the financial summary and officers' contact changes fail. | CAP-MBR-MEM-012, CAP-MBR-MEM-013, CAP-MBR-MEM-016 | Structured evidence | debt |
FND-MBR-MEM-037 | low | A rejected application's reserved term is cancelled but its membership is kept with no status, whereas a voided first purchase removes the membership. | CAP-MBR-MEM-012 | Structured evidence | inconsistency |
FND-MBR-MEM-038 | low | The expiry-alert contract, under which a refusal by Platform fails the business write, has no automated proof. Publishing is off unless the environment switches it on. | CAP-MBR-MEM-014 | Structured evidence | debt |
FND-MBR-MEM-039 | medium | Whether a package needs approval is decided by a flag on the application process, not by the Submissions definition's review stages, which Membership cannot read yet. | CAP-MBR-MEM-011, CAP-MBR-MEM-009 | Structured evidence | inconsistency |
FND-MBR-MEM-040 | medium | An application process's window, eligibility binding and outcome parameters are stored and read by nothing. A closed or ineligible process behaves as an open one. | CAP-MBR-MEM-011, BR-CAP-MBR-MEM-011-07 | Structured evidence | undocumented |
FND-MBR-MEM-041 | high | Membership has no intake from the Submissions engine: applications exist only where an import created them. A decision about any other submission is left unacknowledged, so live applications cannot drive membership yet. | CAP-MBR-MEM-011, BR-CAP-MBR-MEM-011-05, CAP-MBR-MEM-012 | Structured evidence | undocumented |
FND-MBR-MEM-042 | medium | Reading applications within an officer's scope has no automated proof. A refusal names the scope rule and the linked membership, unlike a refusal for an application that does not exist. | CAP-MBR-MEM-011, BR-CAP-MBR-MEM-011-06 | Structured evidence | defect |
FND-MBR-MEM-043 | low | Application processes can be of kind rejoin or change of chapter, but no outcome drives a rejoin and a change of chapter orders nothing. | CAP-MBR-MEM-011 | Structured evidence | inconsistency |
FND-MBR-MEM-044 | low | The path where the dues order's preparation or placement is refused, which leaves the decision unacknowledged, has no automated proof. | CAP-MBR-MEM-012, BR-CAP-MBR-MEM-012-08, JNY-MBR-MEM-003 | Structured evidence | debt |
FND-MBR-MEM-045 | medium | Renewal notices, reminders and card warnings are skipped for organization members, because no billing contact is resolved for an organization. | CAP-MBR-MEM-013, OQ-MBR-MEM-003 | Structured evidence | undocumented |
FND-MBR-MEM-046 | high | Platform's communications does not yet know the purposes of the renewal notice, reminder and expiring-card warning. Platform stores such requests and sends nothing. | CAP-MBR-MEM-013, JNY-MBR-MEM-004 | Structured evidence | debt |
FND-MBR-MEM-047 | medium | Expiring-card warnings are planned for every auto-renewing member with a stored payment method, because the card's expiry is Accounting's and is not read. | CAP-MBR-MEM-013 | Structured evidence | defect |
FND-MBR-MEM-048 | medium | No job reconciler is deployed for Membership's jobs. A run whose execution never starts stays executing for ever and can be neither cancelled, replanned nor executed. The failure path that returns a run to planned has no automated proof. | CAP-MBR-MEM-013, BR-CAP-MBR-MEM-013-10, JNY-MBR-MEM-004 | Structured evidence | debt |
FND-MBR-MEM-049 | low | The monthly snapshot's job family is missing from Membership's cross-job views and job family list, so platform job monitoring does not see it. | CAP-MBR-MEM-019 | Structured evidence | debt |
FND-MBR-MEM-050 | medium | A drop run planned as of a date in the future terminates members whose terms are still in force today, and records a future effective date on the termination. | CAP-MBR-MEM-013 | Structured evidence | defect |
FND-MBR-MEM-051 | medium | With grace members kept in scope, an officer's roster filtered by one of their own units still omits members in grace, and so does an export with the same filter. The officer's unfiltered list shows them. | CAP-MBR-MEM-015, BR-CAP-MBR-MEM-015-06 | Structured evidence | defect |
FND-MBR-MEM-052 | medium | A refusal for a membership outside an officer's scope is worded differently from one for a membership that does not exist, which tells the caller the membership exists. Refusals also carry internal prefixes and raw identifiers. | CAP-MBR-MEM-015, BR-CAP-MBR-MEM-015-11 | Structured evidence | defect |
FND-MBR-MEM-053 | low | A grant on a unit always reaches the units below it. A grant for one unit alone, such as region-level members without their chapters, is not available. | CAP-MBR-MEM-015 | Structured evidence | debt |
FND-MBR-MEM-054 | high | An officer's enrolment into a program bound to an identity unit is prepared and placed for a unit that is merged or does not exist. The preparation checks only that a unit is named. | CAP-MBR-MEM-016, BR-CAP-MBR-MEM-016-09 | Structured evidence | defect |
FND-MBR-MEM-055 | medium | The financial summary fails for every membership while Commerce's order lines cannot be read, instead of answering the terms with no order history. | CAP-MBR-MEM-016, BR-CAP-MBR-MEM-016-08 | Structured evidence | defect |
FND-MBR-MEM-056 | medium | Portal members gain Membership's own-memberships access only when Platform attaches Membership's built-in portal policy to the Portal Member role. That is Platform's change and is not made, so until then a deployed portal member sees nothing. | CAP-MBR-MEM-017 | Structured evidence | debt |
FND-MBR-MEM-057 | low | A member's own portal view shows Commerce's order and order-line references on its terms and events. | CAP-MBR-MEM-017, BR-CAP-MBR-MEM-017-08 | Structured evidence | defect |
FND-MBR-MEM-058 | medium | History hides facts a change touched: the suspension reason, a purchase's Commerce references and a term's closing instant. It attributes Commerce's fulfilment, cancellation and enforcement to Rhythm's automation rather than to Commerce. One save that changes the stored status advances the membership's version by two. | CAP-MBR-MEM-018, BR-CAP-MBR-MEM-018-10 | Structured evidence | defect |
FND-MBR-MEM-059 | medium | An "as known at" instant is cut to milliseconds wherever it is accepted, while versions record microseconds. A past-date read or a snapshot run can therefore answer for an earlier instant than the one asked. | CAP-MBR-MEM-018, BR-CAP-MBR-MEM-018-11 | Structured evidence | defect |
FND-MBR-MEM-060 | low | History is readable by workspace-wide staff only. Officers cannot see the history of their own members, and a member's own view has only the business log. | CAP-MBR-MEM-018, OQ-MBR-MEM-004 | Structured evidence | inconsistency |
FND-MBR-MEM-061 | high | An empty or blank value in a captured contact custom field makes every snapshot run of the month fail, so the month never publishes. | CAP-MBR-MEM-019, BR-CAP-MBR-MEM-019-11 | Structured evidence | defect |
FND-MBR-MEM-062 | medium | Months after a migration report no members, because a month is known at its own end, before the migration recorded anything. A month's movements are not reconciled against its opening and closing counts. Generation runs in one transaction, which an association of more than about 250,000 memberships will outgrow. | CAP-MBR-MEM-019, BR-CAP-MBR-MEM-019-12 | Structured evidence | defect |
FND-MBR-MEM-063 | medium | Business events use the change-event mechanism with keys that Rhythm's integration catalogue does not list, a choice the events record leaves to Andrew. Events are kept for the life of the workspace and wait up to a minute for delivery. The invoke grant is broader than intended. A lapse tells Committees the term's last day, which may be weeks before the lapse was found. | CAP-MBR-MEM-020, OQ-MBR-MEM-005 | Structured evidence | inconsistency |
FND-MBR-MEM-064 | high | When CRM merges two contacts or organizations, the merged-away record's memberships stay on the deleted record. Membership's merge participants are not built, and nothing resolves two principal memberships in one program. | CAP-MBR-MEM-020, BR-CAP-MBR-MEM-020-10, OQ-MBR-MEM-006 | Structured evidence | undocumented |
FND-MBR-MEM-065 | low | Membership reads other applications' tables directly: CRM's people, Accounting's products and prices, and Platform's workspaces, users and number seeds. The test copies of those tables are not checked against their owners, so a change by an owner can break Membership without a failing test. | CAP-MBR-MEM-020 | Structured evidence | debt |
FND-MBR-MEM-066 | low | Changes to programs, types, packages, status reasons and change policies are recorded as revisions, but no operation reads them. | CAP-MBR-MEM-018 | Structured evidence | undocumented |
| FND-MBR-MEM-067 | medium | The draft overstates immutability, import event creation and business-event coverage, and conflates term correction with supersession. Import upserts can replace membership values and do not record a fresh imported event for an existing term; staff corrections update the current term, record history excludes cache bookkeeping, and business-event publication covers selected changes. The examined capability and concepts are corrected. | CAP-MBR-MEM-001, CON-MBR-MEM-001, CON-MBR-MEM-002 | Structured evidence | inconsistency | | FND-MBR-MEM-068 | medium | Four creation acceptance scenarios claim more than their bound tests assert: owner eligibility, all type and package checks, staff-supplied join dates and suppression of import fan-out. Their bindings are removed pending complete proof; the import refusal scenario no longer claims successful processing of other items. | ATS-MBR-MEM-001, BR-CAP-MBR-MEM-001-01, BR-CAP-MBR-MEM-001-04, BR-CAP-MBR-MEM-001-09, BR-CAP-MBR-MEM-001-10 | Structured evidence | debt |
| FND-MBR-MEM-069 | medium | Application process updates preserve omitted fields and package lists, contrary to the draft’s whole-replacement description. The decision handler includes a closed state and retains a membership after rejection cancels its pending terms; stored outcome parameters do not alter order preparation. These descriptions are corrected, but the intended use of outcome parameters remains unresolved. | CAP-MBR-MEM-011, CAP-MBR-MEM-012, CON-MBR-MEM-004 | Structured evidence | inconsistency | | FND-MBR-MEM-070 | low | The charter claims all twenty in-scope end-to-end files are indexed, but direct capability evidence names eighteen. The idempotency-ledger and packages-as-products files remain unindexed; both predominantly exercise neighboring structure or configuration operations, while the package suite also tests initial membership refusal for an inactive product. The charter ratio is corrected. | MOD-MBR-MEM, CAP-MBR-MEM-001, CAP-MBR-MEM-009 | Structured evidence | debt |
| FND-MBR-MEM-071 | medium | The draft confuses action suppression with candidate exclusion, calls the executed billing state final even though another execution job is allowed, and implies that the affiliation primary upper bound guarantees a primary exists. The billing concept and primary rule are corrected to distinguish these behaviors. | CON-MBR-MEM-005, CAP-MBR-MEM-007, BR-CAP-MBR-MEM-007-04 | Structured evidence | inconsistency |
| FND-MBR-MEM-072 | medium | The overlap rule previously implied identical service and database coverage. The database exclusion covers committed, superseded and terminated terms, while the service also considers pending terms. The rule now states that distinction; the existing direct-insert test proves an effective-term overlap only. | CAP-MBR-MEM-001, BR-CAP-MBR-MEM-001-06, ATS-MBR-MEM-001 | Structured evidence | inconsistency |
| FND-MBR-MEM-073 | high | The independent examination and OpenAI wording pass remain incomplete. Nineteen capabilities, nineteen acceptance sets, all six journeys and the charter, findings and registry still require their complete pass. Sixteen documents have complete wording rewrites, which does not establish module-wide evidence verification or readiness for design. | MOD-MBR-MEM | Structured evidence | debt |
| FND-MBR-MEM-074 | medium | The draft treated package-granted coverage as a child membership that rejects direct term additions. Grant application actually creates principal memberships with source-linked granted terms. The staff-extension and grant descriptions now distinguish those records from flow-down and assigned children; the remaining artifacts need the same distinction checked. | CAP-MBR-MEM-002, CAP-MBR-MEM-006, MOD-MBR-MEM | Structured evidence | inconsistency | | FND-MBR-MEM-075 | medium | Seven compound acceptance scenarios lose their claimed proof bindings during this continuation because the cited assertions do not establish the complete case. They remain proposed: stale correction plus cancelled-term closure, child suspension plus restoration, assigned-seat selection, future-child withdrawal, reordered CRM delivery, incompatible merge refusals, and identity movement plus collision. Retained bindings also require continued scrutiny for the unexamined capabilities. | ATS-MBR-MEM-003-01, ATS-MBR-MEM-004-03, ATS-MBR-MEM-006-06, ATS-MBR-MEM-006-08, ATS-MBR-MEM-006-09, ATS-MBR-MEM-008-05, ATS-MBR-MEM-008-06 | Structured evidence | debt | | FND-MBR-MEM-076 | low | A sweep test named as crossing into lapse advances only through the final grace day and asserts grace. The standing acceptance set now uses the late-lapse and actual expiry assertions instead. The source test title still needs correction in the service repository. | CAP-MBR-MEM-005, ATS-MBR-MEM-005-05 | Structured evidence | inconsistency |
| FND-MBR-MEM-077 | medium | Application processes and billing templates change by merging the supplied fields over the stored record, while scope settings and snapshot dimension settings are replaced whole. One module therefore has two update models: leaving a field out keeps it on a process or template and removes it from a settings document. No record says which rule the module follows. | ADR-MBR-MEM-016, SVC-MBR-MEM-applications, SVC-MBR-MEM-billing, OQ-MBR-MEM-007 | Structured evidence | inconsistency | | FND-MBR-MEM-078 | medium | The custom field rule names membership applications among the records that carry custom fields, but Membership registers no application object with Platform and has nowhere to store the values. | DOM-MBR-MEM-004, ADR-MBR-MEM-011, OQ-MBR-MEM-008 | Structured evidence | inconsistency | | FND-MBR-MEM-079 | low | The renewal-pending Commerce fence is declared in the membership's closed list of fences, but no owner function sets it. A renewal in progress is recognised from its pending term instead, so the declared value is dead. | DOM-MBR-MEM-001, STATE-MBR-MEM-002 | Structured evidence | undocumented | | FND-MBR-MEM-080 | medium | This design draft could not read the platform standards or the membership architecture, which live in the Platform repository its credential does not cover. Every mechanism is attributed to a standard through the service's own references, and no design intent is marked confirmed from a standard it could not read. | MOD-MBR-MEM, RESP-MBR | Structured evidence | debt | | FND-MBR-MEM-081 | medium | When a person stops qualifying for an organization's flow-down, their derived term ends on the day the change handler runs, not the day the role ended in CRM. A delayed or retried CRM delivery therefore extends the person's coverage, and a backdated role end is never reflected. | WF-MBR-MEM-007, CAP-MBR-MEM-006, OQ-MBR-MEM-009 | Structured evidence | undocumented |
| FND-MBR-MEM-082 | low | The requested design brief is missing from the examination baseline. The approved planning artifacts and examination task establish the available scope, but brief-specific constraints cannot be independently checked. | MOD-MBR-MEM | Structured evidence | debt |
| FND-MBR-MEM-083 | high | The members screen uses a shared synthetic store without Membership permission evaluation or workspace and unit filtering. Its future live-record contract therefore has unsatisfied server authorization and scope controls; synthetic data does not prove isolation. | TC-AZ-002, TC-AZ-003, TC-TEN-001, TC-TEN-002, TC-TEN-003, TC-TEN-004, SCR-MBR-MEM-001 | react-console:app/(console)/console/[tenantId]/membership/members/page.tsx:MembersPage; react-console:lib/members-store.ts:getStore; FND-MBR-MEM-003 | control-gap | | FND-MBR-MEM-084 | high | Direct staff renewal locks the holding but recomputes the next period after every request without a repeat key or a required holding version. Two undated requests can create successive periods rather than one renewal, leaving repeat-delivery and concurrent-intent protection incomplete. | TC-PI-002, TC-PI-003, CAP-MBR-MEM-002, WF-MBR-MEM-002, SVC-MBR-MEM-memberships | services-membership:modules/memberships/services/operations/staff-operations.ts:addTerm, addTermSchema; BR-CAP-MBR-MEM-002-07; WF-MBR-MEM-002 | control-gap | | FND-MBR-MEM-085 | high | Billing execution commits its job and executing state before requesting startup. The examined deployment has no job reconciler, so failed startup can strand the run rather than resume or settle it; durable-work recovery and reconciliation remain incomplete. | TC-AVL-004, TC-PI-004, CAP-MBR-MEM-013, WF-MBR-MEM-018, SVC-MBR-MEM-billing | services-membership:modules/billing/services/runs/billing-run-operations.ts:executeRun; services-membership:modules/billing/aws/logic/billing-run.step-function.ts; FND-MBR-MEM-048 | control-gap | | FND-MBR-MEM-086 | medium | Published membership events remain stored until workspace purge and have no enforced retention period. The retained membership identifiers and payloads need a recorded retention decision and enforcement; event transport cleanup does not remove the published history. | TC-DAT-003, CAP-MBR-MEM-020, WF-MBR-MEM-025, SVC-MBR-MEM-events | services-membership:modules/events/db/published-events.table.ts:publishedEvents; services-membership:modules/events/services/persistence/published-events.ts; OQ-MBR-MEM-005; FND-MBR-MEM-063 | control-gap | | FND-MBR-MEM-087 | medium | Every roster request creates a fresh submission identity, so retrying the same export request can create multiple jobs and retained outputs. The request has no stable caller repeat key to prove one effect under repeated delivery. | TC-PI-002, CAP-MBR-MEM-017, WF-MBR-MEM-023, SVC-MBR-MEM-memberships | services-membership:modules/memberships/services/rosters/roster-exports.ts:requestRosterExport | control-gap | | FND-MBR-MEM-088 | medium | Membership declares its portal-member policy, but the permitted pinned sources do not establish deployed Platform attachment or the effective Membership grants of shared customer roles. The authorization model labels customer role bundles as proposed profiles and leaves deployed composition unverified. | AUTH-MBR, ROLE-MBR-001, ROLE-MBR-002, ROLE-MBR-003, ROLE-MBR-004, ROLE-MBR-005, ROLE-MBR-006, CAP-MBR-MEM-017 | services-membership:aws/membership.service.ts:PORTAL_MEMBER_POLICY; services-membership:docs/migrations/scope/README.md#What differs from 06; rhythm-v2-docs:specs/platform/security/planning/capabilities/CAP-PFM-SEC-013-ship-rhythm-s-built-in-roles-and-policies-with-each-release.md | undocumented |
Open Questions
| Id | Question | Why it matters | Options | Recommendation | Affects |
|---|---|---|---|---|---|
OQ-MBR-MEM-001 | When a unit type allows several primaries, which primary unit should a membership's "as of a date" answer and its reports name? | The record and the reports disagree today, so a roster built from one and a report built from the other name different primary chapters for the same member. | A: the earliest-starting primary. B: the latest-starting primary. C: every primary held on the date, with reports choosing the latest-starting. | The product should choose C: it states the truth on the record and gives reports one deterministic choice. | CAP-MBR-MEM-007, CAP-MBR-MEM-018, CAP-MBR-MEM-019, FND-MBR-MEM-025 |
OQ-MBR-MEM-002 | After a chapter merge, should a member whose merged tie was primary have their tie with the survivor made primary? | Today such a member has no primary chapter of that kind until staff act, which affects mailings, voting and reports that need one chapter per member. | A: leave it to staff (today). B: make the survivor tie primary from the merge's date, splitting it at that date. C: refuse the merge until staff choose a primary for each such member. | The product should choose B: it keeps the past as it was and leaves no member without a primary. | CAP-MBR-MEM-008, FND-MBR-MEM-027 |
OQ-MBR-MEM-003 | Who should receive an organization member's renewal notice, reminders and card warning? | Organization members receive nothing today, so corporate renewals depend on staff remembering them. | A: the contact holding CRM's billing contact role at the organization. B: the organization's own e-mail address. C: keep skipping and list them for staff. | The product should choose A, with C as the fallback when the organization has no billing contact. | CAP-MBR-MEM-013, FND-MBR-MEM-045 |
OQ-MBR-MEM-004 | Should chapter and regional officers see the change history of the members in their scope? | Officers manage their members' chapters and contact details but cannot see who changed them, which makes disputes in a chapter hard to settle. | A: staff only (today). B: officers see the history of members in their scope today. C: officers see only the business log. | The product should choose B, which follows the same scope rule as every other officer read. | CAP-MBR-MEM-018, FND-MBR-MEM-060 |
OQ-MBR-MEM-005 | Should Membership's business events move to Rhythm's integration catalogue and its outbox, and how long should they be kept? | The events Committees relies on use keys the catalogue does not list, and they are kept for ever. Other applications and outside integrations need one catalogue and a known retention. | A: keep the change-event mechanism and register these keys in the catalogue. B: move to the catalogue's business-events outbox with its keys and 90-day retention. C: keep both, each for its own receivers. | The product should choose B, decided with the Integration Platform owner, keeping the nine events' contents. | CAP-MBR-MEM-020, FND-MBR-MEM-063 |
OQ-MBR-MEM-006 | When CRM merges two contacts or organizations, what happens to their memberships? | Today the merged-away record's memberships stay on a deleted record. When both held a membership in the same program, the member has two. | A: move every membership to the survivor, and refuse the merge while both hold a principal membership in one program until staff resolve it. B: move them and combine the two memberships' terms automatically. C: leave them and flag them for staff. | The product should choose A: nothing is lost, and the hard case is decided by a person. | CAP-MBR-MEM-020, FND-MBR-MEM-064 |
OQ-MBR-MEM-007 | Should changes to application processes and billing templates send the complete record, as the module's settings documents and Accounting's configuration do? | Today a field left out of a change is kept, so a caller cannot clear an optional field by omitting it, and the module behaves two ways. | A: keep merging for configuration records and replacing for settings documents (today). B: replace every configuration record whole at the version read. C: offer both, a complete replacement and an explicit partial change. | The product should choose B: one rule for every change, which the shared configuration routes would then apply to every Membership resource. | ADR-MBR-MEM-016, FND-MBR-MEM-077 |
OQ-MBR-MEM-008 | Should membership applications carry custom fields, as the custom field rule names them? | Associations ask applicants for information of their own; without a decision it is unclear whether that lives in Membership or only in the Submissions engine's answers. | A: register applications with the shared custom field capability once applications have an intake. B: keep application-specific answers in the Submissions engine and remove applications from the rule's list. C: defer until the intake from the engine is built. | The product should choose C, then A: the rule names applications, and their values have nowhere to come from until the engine's intake exists. | DOM-MBR-MEM-004, ADR-MBR-MEM-011, FND-MBR-MEM-078 |
OQ-MBR-MEM-009 | When a person leaves an organization's flow-down, from which day should their derived membership end? | Coverage today depends on when the handler happens to run, so two members who left on the same day can lose coverage on different days. | A: the day the handler runs (today). B: the day the role or affiliation ended in CRM, never earlier than the term's start. C: the instant CRM recorded the change, as a local date. | The product should choose B, falling back to C when CRM records no end date. | WF-MBR-MEM-007, CAP-MBR-MEM-006, FND-MBR-MEM-081 |