Content Model
Use this page as the first admin-facing map of Wavemap content. It explains the concepts a content editor should understand without requiring knowledge of the implementation details behind API contracts, database tables, media storage, or route permissions.
This is not a CMS authoring guide yet. Publishing workflows, moderation policy, approval queues, and user-facing role management should wait until those product surfaces exist.
Core Concepts
Section titled “Core Concepts”| Concept | Admin Meaning | Current Notes |
|---|---|---|
| Artist | A performer, act, creator, or project that can have a profile and be associated with events. | Current media work is artist-first, including profile and gallery images. |
| Event | A time-based occurrence that can connect artists, venues, and event-series membership. | Event relationships should be managed as collections once they become too large for inline forms. |
| Venue | A place or hosting context that can be associated with events. | Venue relationship management should follow the same collection pattern when the surface matures. |
| Event Series | A named grouping for related events. | Series membership is a relationship, not a field copied onto every event. |
| Media Asset | A persisted image or future media item attached to a content entity. | Artist images are the current implemented path; broader media-bearing entities remain deferred. |
| Relationship | A managed association between two content entities, such as artist-event or event-venue. | Relationships may later carry metadata such as billing order, role, provenance, or audit fields. |
| User | An account that can authenticate and receive roles. | Content editing and user management are separate responsibility areas. |
| Admin | A trusted account role for content creation and update workflows. | Admin UX should check permissions, not hard-code assumptions about role names. |
| Root | A higher-trust role for user management, admin control, deletion, and token revocation workflows. | Root-facing controls should stay separate from ordinary content editing. |
Content Editing Shape
Section titled “Content Editing Shape”Treat scalar fields and relationships differently.
Scalar fields belong in ordinary create/edit forms:
- Names and titles.
- Descriptions and summaries.
- External links.
- Profile image selection.
- Simple display metadata.
Relationship sets should move into a dedicated management surface when they can grow:
- Artist events.
- Event artists.
- Event venues.
- Event-series membership.
- Future user, role, or permissions administration tables.
The parent form should show a compact summary, count, and management action instead of rendering a long removable-card list inline. A trusted admin may eventually manage the same relationship from either side, such as from an artist page or an event page, but the interaction model should stay consistent.
Media Expectations
Section titled “Media Expectations”The current durable media model is artist-first:
- Artist profiles can use a profile-purpose image.
- Artist galleries can use gallery-purpose images.
- The backend returns render-ready URLs and generated thumbnail or preview fields.
- Media records should carry useful metadata such as alt text where the UI asks for it.
- The stored media identity is not just a public URL. Provider-specific storage details stay behind the application.
Admins should think in terms of content meaning: profile image, gallery image, useful alt text, and whether an image still belongs to the artist. Storage providers, object keys, thumbnails, blur previews, and cleanup reports are platform concerns unless an operator asks for targeted evidence.
Roles And Permissions
Section titled “Roles And Permissions”Wavemap separates content responsibilities from user-management responsibilities.
| Responsibility | Current Role Direction |
|---|---|
| Create or update content | Admin-capable users. |
| Manage artist profiles | Admin-capable users today; modeled separately from artist media and relationships. |
| Manage artist media | Admin-capable users today; may later separate from profile editing. |
| Manage artist-event associations | Admin-capable users today; separate from controlling either entity’s profile. |
| Delete content | Higher-trust controls may be required depending on the surface and deletion impact. |
| Invite or manage admins | Root-level user-management workflows. |
| Enable, disable, or delete users | Root-level user-management workflows. |
| Revoke refresh tokens | Root-level security workflow. |
The product should expose human-friendly admin concepts when those screens exist. Internal permission codes, development roles, and route-access details should stay in developer docs until there is a concrete admin UX for them.
Content rows also carry lightweight platform metadata such as lifecycle status, creation/update actors, timestamps, and a revision counter. That metadata supports editor trust and future conflict/audit workflows, but it is not itself a full audit trail or publishing workflow.
What Is Not Settled Yet
Section titled “What Is Not Settled Yet”The admin docs should not pretend these areas are complete:
- CMS authoring and publishing workflows.
- Moderation queues or public-content approval policy.
- Admin role and permission display or editing UI.
- Audit-log presentation.
- Deletion, restore, and soft-delete policy for content relationships.
- Account-controlled artist, venue, event, or series profiles.
- Cross-entity media management beyond artist images.
- Venue, event, and series-specific authoring guides.
When those surfaces settle, promote them into focused admin pages instead of expanding this concept map into a long implementation guide.