--- id: CON-MBR-MEM-004 name: Membership Application feature: FEAT-MBR-MEM-04 product_area: membership module: memberships revision: 1 status: draft product_intent: confirmed implementation_evidence: partially-observed source_sha: services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A membership application is the typed record connecting an applicant’s membership request to its configured process, external submission, decision and resulting purchase work. owned_by: MOD-MBR-MEM synonyms: - join application - renewal application not_to_be_confused_with: - 'Submissions owns the submitted answers, review stages and delivered decision.' - Commerce owns any order prepared following approval. facets: - name: Application process meaning: >- The configured process identifies the operation, program, offered packages, outcome, submission definition and review choice. used_for: Identifying the reviewed offer and the action associated with approval. - name: Kind and outcome meaning: The requested operation and configured outcome describe the intended membership result. used_for: Selecting the membership operation represented by the application. - name: Window and eligibility binding meaning: Stored opening and closing dates and an eligibility reference describe intended admission conditions. used_for: Recording restrictions whose runtime enforcement remains incomplete. - name: Outcome parameters meaning: Stored timing and package choices describe the intended outcome parameters. used_for: Retaining options currently not applied by the decision handler. - name: Chosen units and assigned contacts meaning: Ordered unit choices and named contacts record chapter selection and organizational seat assignments. used_for: Supplying purchase choices and organizational assigned beneficiaries. - name: Decision meaning: >- The delivered decision reference, result, code and time explain the resulting decided, awaiting-applicant, withdrawn or closed state. used_for: Distinguishing redelivery from replacement and choosing the next action. - name: Order and acknowledgement meaning: The application retains the placed dues order and the time its decision was acknowledged. used_for: Tracing action on approval and completion of the delivery exchange. relationships: - to: CON-MBR-MEM-001 statement: >- Requests concerning an existing member refer to the membership, and a join request can acquire that reference when purchase reservation establishes the holding. provenance: observed source: 'services-membership:modules/applications/db/applications.table.ts' - to: CON-MBR-MEM-002 statement: >- A placed approval purchase can reserve a pending term; rejection cancels the pending term while keeping its membership. provenance: test source: >- services-membership:modules/applications/tests/integration/decision-handler.integration.spec.ts#cancels the pending term of a rejected application whose purchase was placed acted_on_by: - CAP-MBR-MEM-011 - CAP-MBR-MEM-012 - CAP-MBR-MEM-009 visible_to: - ACT-MBR-006 - ACT-MBR-007 - ACT-MBR-008 - ACT-MBR-009 evidence: - >- services-membership at 5994c270e8a37a30f848e99ba5b5ee6b87c08893: modules/applications/db/*.table.ts, application-vocabularies.ts; services/configuration/application-process-records.ts; services/decisions/decision-handler.ts; services/reads/application-reads.ts; contracts/subject-kinds.ts; docs/migrations/participant/README.md. supersedes: - 'inventory:CAP-MBR-COM-010' - 'inventory:CAP-MBR-COM-011' --- # Membership Application ## What It Is A membership application records a request to enter or change a membership relationship through a configured application process. It connects Membership’s program and package choices to a submission reviewed by the Submissions engine. The record identifies the applicant, the operation requested, any membership concerned, chosen units and the delivered decision. The process describes what the association is reviewing. It names the program, offered packages, submission definition and whether review is required. The application then supplies the particular request and its result. This division lets Membership act on a decision without implementing its own form, reviewer assignments or review stages. ## What It Is Not The typed application does not contain or own the submission’s full review experience. Submissions owns that record and delivers its decision. An approval can lead to a Commerce order, but the application remains a record of the request and decision rather than becoming the order or the membership. Rejection of a reserved request cancels pending terms and retains the membership; it does not automatically erase the holding. ## How It Is Used Administrators configure a process for the offer under review. A reviewed package makes purchase preparation require approval unless the purchase identifies an approved application. Membership records a delivered decision once, accepts an explicitly superseding decision and ignores a conflicting later delivery that does not name the recorded predecessor. Approval of a purchase process prepares the package and required chapter dues through the checkout preparation path. Membership records the placed order and acknowledges successful handling to Submissions. Preparation or placement refusal leaves the decision unacknowledged for another delivery. These exchanges currently depend on unwired external ports, and ordinary application intake is also incomplete. Staff can inspect existing applications; officers use the scope of the linked membership, while an application without a membership is available only to workspace-wide readers. ## Its Facets **Application process.** The process identifies the configured offer. Version-checked updates retain omitted fields and package lists rather than requiring whole-record replacement. **Kind and outcome.** The request kind identifies the membership operation, while the outcome describes the intended consequence of approval. Affiliation-change processes do not place a dues order through the current decision path. **Window and eligibility binding.** Opening dates, closing dates and eligibility references are stored. The date order is validated, but runtime admission does not currently enforce these settings. **Outcome parameters.** Timing and package options have a bounded, validated shape. The decision handler currently uses the application’s package and process kind rather than applying these stored options. **Chosen units and assigned contacts.** Ordered chapter choices feed purchase preparation. Named organizational contacts identify assigned seats associated with organizational membership. **Decision.** The external result and its recording trail determine whether the application is decided, awaiting the applicant, withdrawn or closed. A decision identity also makes repeated delivery distinguishable from a new ruling. **Order and acknowledgement.** The order reference connects approval to its purchase work. Acknowledgement records completion of the exchange separately from whether Commerce has fulfilled the membership period. ## How It Relates Submissions supplies intake, review and decisions. Membership supplies the typed request and the membership-specific consequences. Commerce manages purchase placement and fulfilment. Existing membership references support scoped reads, while assigned contacts connect organizational applications to dependent memberships. ## What It Could Become The product should complete intake and the external order and acknowledgement ports before presenting this as a working application journey. It should also settle enforcement of process windows, eligibility and stored outcome parameters. Any decision to remove a rejected applicant’s retained membership needs an explicit lifecycle policy rather than being inferred from the rejection itself.