Domain Rules

This is the non-negotiable layer: rules enforced server-side, independent of UI.

Memberships

• A member can have multiple historical memberships but at most one active membership period per plan.
• Grace period rules must be applied consistently (expiry vs grace end).

Group memberships

• occupiedSeats <= totalSeats.
• You cannot remove seats below occupied count.
• Seat assignment must be tenant-scoped.

Events

• endAt > startAt.
• Ticket sale windows must be within event lifecycle.
• Check-in only allowed for confirmed/paid registrations.

Courses

• Completion and CPD awarding are idempotent.
• Enrollment uniqueness: a member should not have duplicate active enrollments for the same course.

Payments / orders

• Payment status transitions must be monotonic and auditable.
• Refunds require privileged role and must log refundedBy.

CRM sync

• crmTags must be stable (slug) and referenced, not free-typed strings.
• Sync records must include enough context to retry safely (idempotency keys).

Features

Domain Rules

Acceptance Criteria

Frontend

• Developer-facing configuration and usage is documented and internally consistent.

Backend / API

• Convex implementation matches the rules and contracts described on this page.

Permissions

• Tenant scoping and access controls are enforced as described.

Business Rules

• Domain rules/invariants are enforced as described.

Error Handling

• Access violations and validation failures produce deterministic errors.