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

Concept	Admin Meaning	Current Notes
Artist	A performer, act, creator, or project that can have a profile and be associated with events.	Supports a primary profile image and ordered gallery images.
Event	A time-based occurrence that can connect artists, venues, and event-series membership.	Preserves organizer-local scheduling and supports one Poster plus ordered Gallery images.
Venue	A place or hosting context that can be associated with events.	Supports current-location review, Event relationship sheets, and ordered profile/gallery images.
Event Series	A durable identity for a direct program or a family of Editions.	Uses one exclusive direct-Events or Editions structure; membership never replaces Event identity.
Edition	One installment of an editioned Series with its own program scope.	Owns its overall window, official Venues, attendance links, program, destinations, and media.
Media Asset	A persisted image or future media item attached to a content entity.	Artist, Event, Venue, Series, and Edition images remain separate entity-owned collections.
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

Treat scalar fields and relationships differently.

Scalar fields belong in ordinary create/edit forms:

Names and titles.
Descriptions and summaries.
External links.
Simple display metadata.

Media authoring may appear in the same page, but it remains a separate saved collection with its own permission, validation, progress, and recovery state rather than a scalar URL field.

Relationship sets should move into a dedicated management surface when they can grow:

Artist events.
Event artists.
Event venues.
Series direct Events and Edition children.
Edition program Events and official Venues.
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

The current durable media model supports Artist, Event, Venue, Event Series, and Edition images:

Artist profiles can use a profile-purpose image.
Artist galleries can use gallery-purpose images.
Events can use one editor-facing Poster and an ordered Gallery. Removing a Poster does not automatically promote another image; primary-image selection is an editorial decision.
Venues can use one profile-purpose image plus an ordered Gallery. Upload and final-sync retry never recreates the already-saved Venue.
Series and Editions can each use one profile-purpose image plus an ordered Gallery. Empty public showcases display one large placeholder without an empty thumbnail strip.
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 its content owner. Event editors use Poster language even though the stable persisted purpose code is shared with other profile images. Storage providers, object keys, thumbnails, blur previews, and cleanup reports are platform concerns unless an operator asks for targeted evidence. If parent creation succeeds but a later media upload or final sync fails, the entity remains saved and the editor should use the supplied retry path rather than recreate it.

Event Authoring Expectations

Add Event and Edit Event use the same editor language, field order, and responsive composition. Their saved-state behavior differs deliberately: Add creates one independently valid occurrence before any media upload, while Edit starts from the saved Event, writes only meaningful changes, and can require conflict recovery when another editor has advanced the Event revision.

When authoring an Event:

Choose organizer-local dates and times plus an explicit IANA reference time zone. Venue time zones are visible advice, not schedule authority.
Treat physical Venues and digital destinations as attendance contexts for one occurrence. Online and hybrid Events require the corresponding digital attendance information.
Manage Artists through the compact relationship surface, and keep ticket links separate from ordinary external links.
Treat Event media as independently saved Poster/Gallery work. A media failure after creation does not mean the Event should be recreated.
Expect relationship and media controls to follow separate permissions. Being allowed to create or update Event fields does not automatically grant every relationship or media action.
Use the explicit cancel and recovery actions. Edit conflicts retain the draft so the newest revision can be loaded and the intended changes reapplied.

Event forms show compact read-only Series and Edition context plus links into the owning relationship editor. A Series owns its direct Event membership and Edition children; an Edition owns its program Events and official Venues. This keeps every Event independently valid and scheduled without creating competing membership controls on the Event form. See Event Series for the complete authoring model.

Venue Authoring Expectations

Venue Add/Edit shares one editor form for scalar, contact, link, current-location, relationship, and media context. Editors confirm a provider-neutral location snapshot, correct it manually, or choose location TBA. Event relationships move into a dedicated sheet; Edit relationship changes use their own revision-aware save boundary. Venue media is independently permissioned and recoverable after the parent saves. See Venue Authoring for the current workflow and recovery language.

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 event media	Admin-capable users today; separate from Event scalar, relationship, and delete work.
Manage venue media	Admin-capable users today; separate from Venue scalar and relationship work.
Manage Series or Edition media	Admin-capable users today; separate from scalar and relationship capabilities.
Manage Series and Editions	Admin-capable users today through capability-specific scalar and relationship access.
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

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.
Media management for future entities beyond Artists, Events, Venues, Series, and Editions.
Event Series recurrence generation, stage/track ordering, and CMS publication workflow.

When those surfaces settle, promote them into focused admin pages instead of expanding this concept map into a long implementation guide.