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.