Normalization

The CSV entity registry is a field inventory + UI spec. For Convex, we must convert it into a normalized model optimized for:

• predictable queries (lists, filters, reporting)
• multi-tenant isolation
• avoiding large/unbounded embedded arrays

Table vs embedded

Prefer a table when

• the collection can grow without bounds (tickets, registrations, enrollments, orders, audit logs, messages)
• you need filtering/sorting/pagination across many items
• the items have their own lifecycle/status

Acceptance Criteria

Frontend

• Prefer a table when workflow is implemented in the UI as described.

Backend / API

• Backend behavior supports Prefer a table when as documented.

Permissions

• Access is restricted per the Capabilities matrix on this page (or equivalent role rules).

Business Rules

• All business rules for this feature are enforced.

Error Handling

• Error states return clear messages and appropriate HTTP status codes.

Embed when

• the list is small and bounded (e.g., a handful of speaker objects)
• you only ever fetch it together with the parent document

Acceptance Criteria

Frontend

• Embed when workflow is implemented in the UI as described.

Backend / API

• Backend behavior supports Embed when as documented.

Permissions

• Access is restricted per the Capabilities matrix on this page (or equivalent role rules).

Business Rules

• All business rules for this feature are enforced.

Error Handling

• Error states return clear messages and appropriate HTTP status codes.

Recommended join tables

Use join tables instead of ORM-style ManyToMany:

• courseCategories (course ↔ category)
• memberInterests (member ↔ interestCategory)
• eventSponsors (event ↔ sponsor)

Key boundaries

• Auth user (users) is not the same as member profile (memberProfiles).
• Registrations/enrollments are first-class tables (eventRegistrations, courseEnrollments).
• Support ticket conversation should be modeled as a messages table (supportTicketMessages).

Output artifacts

• The schema blueprint is codified in convex/schema.ts.

Features

Normalization

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.