---
id: DOM-MBR-MEM-004
title: Membership Application
realises: CON-MBR-MEM-004
product_area: membership
module: memberships
revision: 1
status: draft
design_intent: proposed
implementation_evidence: partially-observed
source_sha:
  services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
owned_by: SVC-MBR-MEM-applications
readable_by:
  - SVC-MBR-MEM-memberships
  - SVC-MBR-MEM-commerce-participant
lifecycle: STATE-MBR-MEM-006
custom_fields: none
identity: >-
  A workspace has one typed application for each submission and can record a
  decision identifier only once. Process records have permanent identifiers and
  program-unique names.
attributes:
  - name: application process
    kind: reference
    required: true
    computed: false
    notes: >-
      The process links a Submissions definition to an operation, program,
      ordered package choices, outcome and review flag.
  - name: process window and eligibility binding
    kind: collection
    required: false
    computed: false
    notes: >-
      Opening and closing dates and an eligibility reference are stored; no
      active decision or checkout path enforces this window or binding.
  - name: outcome parameters
    kind: collection
    required: false
    computed: false
    notes: >-
      The bounded document accepts effective timing and a package override, but
      the decision handler does not apply them.
  - name: applicant
    kind: reference
    required: true
    computed: false
    notes: Exactly one person or organization is recorded as the applicant.
  - name: 'program, type and package'
    kind: reference
    required: false
    computed: false
    notes: >-
      The requested program is required in storage, while type and package can
      be absent.
  - name: membership
    kind: reference
    required: false
    computed: false
    notes: >-
      The reference identifies an existing holding or one connected during
      purchase processing.
  - name: submission
    kind: reference
    required: true
    computed: false
    notes: >-
      The submission reference identifies the form and review record owned by
      Submissions.
  - name: chosen units
    kind: collection
    required: false
    computed: false
    notes: The applicant’s unit selections are stored in order.
  - name: assigned contacts
    kind: collection
    required: false
    computed: false
    notes: >-
      Organization applications retain the ordered contacts proposed for
      assigned seats.
  - name: status
    kind: enum
    required: true
    computed: false
    notes: >-
      The row uses the engine’s draft, submitted, review, awaiting-applicant,
      decided, withdrawn and closed vocabulary; decision handling sets the
      relevant outcome status.
  - name: decision
    kind: collection
    required: false
    computed: false
    notes: >-
      Decision facts include identifier, time, result and outcome code, plus the
      Membership outcome when approved.
  - name: dues order and acknowledgement
    kind: collection
    required: false
    computed: false
    notes: >-
      The application records the placed dues order and the successful
      acknowledgement time.
relationships:
  - to: DOM-MBR-MEM-001
    cardinality: many-to-one
    ownership: >-
      The application references the holding it concerns and does not own that
      holding.
    cross_service: false
  - to: DOM-MBR-MEM-002
    cardinality: one-to-many
    ownership: >-
      Purchase placement can reserve a term, and rejecting the request can
      cancel pending coverage.
    cross_service: false
invariants:
  - id: INV-DOM-MBR-MEM-004-01
    statement: >-
      An application identifies one applicant through either the person or
      organization reference.
    enforced_at:
      - database
    provenance: observed
    source: >-
      services-membership:modules/applications/db/applications.table.ts:applications_applicant_check
  - id: INV-DOM-MBR-MEM-004-02
    statement: >-
      Submission and decision identifiers cannot be reused by another
      application in the same workspace.
    enforced_at:
      - database
    provenance: observed
    source: >-
      services-membership:modules/applications/db/applications.table.ts:applications_submission_uidx,
      applications_decision_uidx
  - id: INV-DOM-MBR-MEM-004-03
    statement: >-
      Decision identifier, time and result must be populated together or remain
      absent together.
    enforced_at:
      - database
    provenance: observed
    source: >-
      services-membership:modules/applications/db/applications.table.ts:applications_decision_check,
      applications_decision_result_present_check
  - id: INV-DOM-MBR-MEM-004-04
    statement: >-
      Process windows must be ordered and package choices must belong to the
      process program.
    enforced_at:
      - service
      - database
    provenance: test
    source: >-
      services-membership:tests/e2e/database-refusals.e2e.spec.ts#refuses a
      package of another program 400 naming package_ids[0] and the program
  - id: INV-DOM-MBR-MEM-004-05
    statement: >-
      Outcome parameters accept only timing and package override and cannot
      exceed the configured size bound.
    enforced_at:
      - service
      - database
    provenance: test
    source: >-
      services-membership:tests/acceptance/commerce/MBR-ACC-0347.acceptance.ts#MBR-ACC-0347
  - id: INV-DOM-MBR-MEM-004-06
    statement: >-
      Repeated decisions reuse recorded facts, superseding decisions replace
      them, and unrelated later deliveries are ignored.
    enforced_at:
      - service
      - database
    provenance: test
    source: >-
      services-membership:modules/applications/tests/unit/submissions-contracts.spec.ts#ignores
      a decision a later one has replaced
  - id: INV-DOM-MBR-MEM-004-07
    statement: >-
      Application reads intend to follow the referenced membership’s scope, with
      unattached applications restricted to workspace-wide readers; a known
      finding limits this guarantee.
    enforced_at:
      - service
    provenance: unknown
    source: FND-MBR-MEM-042
physical:
  - membership.application_processes
  - membership.application_process_packages
  - membership.applications
  - membership.application_affiliations
  - membership.application_assigned_contacts
evidence:
  - >-
    services-membership at 5994c270: 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, decision-delivered.ts; AGENTS.md (R2-ARCH-001
    lists membership applications among the entities with custom fields).
---

# Membership Application

## What It Models

Membership keeps a typed account of a request made through Submissions, including the membership purchase or chapter change it concerns. Submissions retains the form answers, review stages and decision authority. Process configuration tells Membership how to interpret that request.

## Identity and Attributes

The application identifies its submission and applicant and can record selected packages, units and assigned contacts. Decision processing records the outcome and then any order and acknowledgement. The handler guards changes by decision identity and supersession, rather than requiring a particular previous application status.

## Relationships

Applications reference holdings and can lead to purchase reservations. Rejection, withdrawal and closing cancel pending terms of the referenced holding while retaining the holding itself. Organizational seat derivation reads selected contacts from decided applications.

## Invariants

Storage enforces applicant identity, submission uniqueness and aligned decision facts. Services validate process configuration and recognize repeated decisions. Read scope has an existing enforcement finding and is not an unconditional guarantee.

## How It Is Stored and Shared

Applications owns processes and typed application records. Memberships reads their seat selections, and checkout checks reviewing processes. The current metadata registration declares no application custom-field capability, despite the architecture record naming applications.

## Open Design Questions

The engine intake remains unconnected, and application creation currently depends on import. Window, eligibility and outcome settings are stored without their intended execution. Product must resolve application custom-field ownership against the existing architecture requirement.
