52 — Discovery & Events (envisioning)

Envisioning doc — Release headline feature. Governed by 00-ROADMAP.md — defer to it on any conflict. Created 2026-07-03 (owner-raised, stakeholder-confirmed: Discovery is one of the two headline features for the Release, alongside Contact ID — 53-CONTACTID-RELEASE.md). Builds on: 51-INVITES-UX-REFERENCE.md (Apple Invites patterns, cited as INV-xx) · the Discovery/Events fragments in 17-UX-ARCHITECTURE-ACTOR-DRIVEN.md and 15-FEATURE-STRATEGY-MATRIX.md · 47-PRODUCT-NORTH-STAR.md (zones + principles). This is the first dedicated Discovery/Events doc — it consolidates those fragments and supersedes them as the source for this feature. Envisioning altitude: shapes and grammar, not schemas or endpoints.

---

1. The owner's vision

"Discovery would allow to discover events around, be invited, be related… the info available a timespan, an aspect of the app that can provide momentum in different points, and a request for action. Discovery we think can be available for musicians, studios, and probably more." — owner, 2026-07-03

Unpacked into product language:

• Discover events around you — a surface where events (gigs, sessions, listening parties, release parties, showcases, studio open days) are findable: by your network first, by proximity/scene later.
• Be invited, be related — the event is a social object: you're invited to it, you RSVP, you see who's hosting; being on the lineup or the guest list relates you to people (feeds the Contact ID contacts graph, doc-53 §4).
• Info alive for a timespan — an event is a timespan-bound node: it has a before, a during, and an after, and what it shows/asks changes accordingly (§5). It doesn't rot in a list; it retires to the archive lens (INV-05).
• Momentum at different points — the event pushes energy into the product at each stage: announcement buzz, approaching-date reminders, day-of coordination, afterglow (photos, recordings, new contacts).
• A request for action — every event leads with the thing it wants from you: attend / decline / interested (INV-02), and for pros: confirm the lineup slot, deliver the set, approve the flyer — the same request-for-action grammar as approvals (doc-32).
• For musicians, studios, and probably more — hosts and audiences span our actor roster (§6): artists play, studios host, managers book, organizers program, fans (later) attend.

Why it's a Release headline: the core loop (create → review → approve, doc-25) keeps existing work moving; Discovery is what makes Sonnance alive — the reason to open the app when nothing is waiting for your approval, and the first surface that creates value between accounts rather than inside one workspace.

2. What already exists on paper (consolidation map)

Fragments this doc consolidates — and now supersedes as the Discovery/Events source:

Fragment	Where	What it said
Actor 9: Event Organizer	doc-17 §Actors (~L317–325)	Wants "discover and book artists, review portfolio/credits, manage event lineup"; nav priority "Events/Calendar, Community (discovery)"
Community / DiscoveryFeed / MapView	doc-17 (~L1165–1172)	Network discovery, public profiles, optional geographic discovery ("producers near me")
EventDrawer · /calendar	doc-17 (~L1198, L1452)	Calendar view = "timeline + events + releases"; P2
Event entity sketch	doc-17 (~L1777)	{ title, date, type: 'release'|'session'|'deadline', entities: [] } — P2
Maps (location-based discovery)	doc-15 (~L345)	P0 for venue-type actors + fans
Discovery Agent	doc-15 (~L388)	Phase-2 AI matching (artists ↔ studios/producers/managers) — "LinkedIn for music" network effects
Calendar Reservations	doc-15 (~L225, L266)	Booking studio time — Phase 3

Docs 15/17 are reference-era; none of this is on the roadmap as a coherent feature until now. The pieces were right — this doc gives them one object (the Event), one surface (Discovery), one grammar.

3. Placement in the product grammar

• Zone: Discovery is a Browse-family surface in the doc-47 three-zone model — but its entries surface through the action-first Home (doc-50, doc-37): an invite awaiting your RSVP is exactly a "needs my attention" item. Fork (not forced here): Discovery as a lens inside Browse vs a fourth top-level surface — decide when the Release IA is cut (§9 Q1).

  Resolved by doc-54 (2026-07-04): neither — Discovery is not a fourth zone; it hangs off the identity corner. The entry sits top-right of the new Contact tab (5th tab, doc-54 §3.2). Home still surfaces RSVP items as attention entries — Home is Discovery's doorbell, the Contact tab is its home.

• The Event as a node: an Event is a timespan-bound node that can ride the doc-49 Portal anatomy — Identity (card, INV-01) · Health (RSVP counts, time-to-date) · Content (lineup, venue, tiles INV-16) · Workflow (lifecycle §5) · People (host, guests, INV-12 visibility rules) · Sharing (INV-09/10/11) · Notes (doc-33). Whether it's a full node or a light satellite of Workspace/Artist is open (§9 Q2).
• Sharing rides doc-26: event invite links are Link principals (doc-26, doc-44) with expiry + rotation surfaced in the UI (INV-10); the one-time per-guest link (INV-09) is the model extension our link module doesn't have yet.
• Config is a place (doc-47 §7, doc-48): every privacy/guest policy lives in one per-event settings panel (INV-13), not scattered toggles.

4. What we take from Apple Invites

Full study in doc-51; the Discovery-critical patterns:

Pattern	Verdict	Use here
INV-01 invitation-card anatomy	Adapt	The Event card — hero, title, when/where, host mini-card
INV-02 pinned tri-state RSVP	Adopt	The request-for-action: attend / decline / interested
INV-03 preview-before-publish + drafts	Adopt	Hosts see the guest view before publishing
INV-04 auto-enriched context (opt-out)	Adapt	Venue map, "time until", travel context from data we hold
INV-05 timespan + role lenses, counts	Adopt	Upcoming / Past ÷ Hosting / Attending / Drafts — the owner's "timespan"
INV-06 card wears your role	Adopt	"Hosting" badge on the card, one surface for all roles
INV-07 host verbs on the live object	Adapt	Send-a-note broadcast, invite, per-event calendar sync
INV-08 rich link unfurl	Adopt	The share card is the first impression (OG metadata)
INV-09 dual-mode inviting	Adopt	Broadcast link + approve-gate vs one-time per-guest links
INV-12/INV-13 asymmetric visibility, per-object config	Adopt	"Only hosts see who's invited" default; Event Settings panel
INV-16 tiles as event resources	Adopt	Presave, tickets, merch, lineup profiles, stems — capped, composable

5. Momentum & the timespan model

The event's lifecycle is the momentum engine. Envisioning-level states and what each surfaces:

Stage	Window	The card leads with	Momentum it generates
Draft	until publish	Preview + publish (INV-03)	Host-side anticipation; lineup confirmations
Announced	publish → T-week	RSVP (INV-02) + share	Invites ripple through the network (INV-08)
Approaching	~T-week → T-day	Logistics: map, time-until (INV-04), host notes (INV-07)	Reminders; guest-list settles (approve-gate INV-09)
Live	day of	Day-of essentials; check-in (QR, INV-11, later)	Presence; "happening now" in Discovery
Afterglow	T+1 → ~T+week	Recap: photos/recordings tiles, "you met…"	New contacts → doc-53 graph; content lands back in Tracks/Files
Archive	after	Past-lens record (INV-05)	Portfolio/credits trail (doc-31 fair-credit)

Notifications follow the doc-38 calm posture: each transition earns at most one signal, and the pre-permission pitch (INV-19) is how we ask for the channel in the first place.

6. Audiences & actors

Mapped to the doc-12 / doc-17 roster:

• Artists / musicians — host listening sessions, play gigs, get discovered via lineups; their Contact ID is the card they drop at every event (doc-53).
• Studios — host open days and sessions; Calendar Reservations (doc-15 P3) eventually plugs booking into the same Event object.
• Managers / labels (A&R) — scout via Discovery (doc-12 "talent scout… discovery"); book through lineup requests (request-for-action, doc-46 verbs).
• Event organizers — the doc-17 Actor 9 wishlist verbatim: discover/book artists, manage lineup, calendar-first navigation.

  Updated by doc-54 §8.4 (2026-07-04): organizers use the same iOS app, role-driven (owner-confirmed): event roles ride doc-44 grants (scope=Event); host/admin/contributor edit via the event card+sheet; the Hosting lens + a Contact ID hosting relation identify them. Growth path = a mgmt.ctrl events lens — never a separate app.

• Fans / guests — attend via links without accounts (guest principals, doc-26) in v1; a fuller fan surface is post-Release (§8).
• "Probably more" — venues, promoters, educators: the Event object stays generic enough (host + timespan + place + lineup + guests) that new actor types are configuration, not code (doc-43 spirit).

7. Data-model sketch (envisioning altitude — sketch, not schema)

Extends the doc-17 Event sketch (~L1777); backend design is a later pass (doc-41 discipline applies when it lands):

Event {
  title, slug/shortId,
  timespan: { start, end, tz },            // the owner's "info available a timespan"
  venue: { name, address, geo? },          // geo optional-first (privacy, INV-04)
  host: ActorRef (User | ArtistSpace | Workspace),
  lineup: [ActorRef],                      // relates people → doc-53 graph
  visibility: 'network' | 'link' | 'public',
  guestPolicy: { approveGuests, showWhosInvited, plusOnes },   // INV-12/13
  rsvps: [{ principal, state: going|declined|interested, at }],// INV-02
  tiles: [Tile],                           // INV-16: links / media / playlist-like
  lifecycleState: draft|announced|approaching|live|afterglow|archived,  // §5
  links: [ShareLink],                      // doc-26; + one-time per-guest links (INV-09)
}

Notable choices: RSVP is a first-class record (auditable, doc-41) not a counter; lineup is the bridge between Events and Contact ID; visibility defaults to network — public events are opt-in.

Updated by doc-54 (2026-07-04): the owner asked for cross-references from user content: the rsvps / lineup / guest records feed contact-card event relations — attending (upcoming) · registered (RSVP'd) · attended (past) — and events reference people (host · lineup · guests) as Contact refs (doc-53 §4.3), under the doc-53 §3 visibility lenses. The refs live in the graph/provenance, not a Portal.

8. Non-goals / trade-offs (v1)

• Not a ticketing platform — no payments, no seat maps; a Tickets tile (INV-16) can point at one.
• Not a social feed — Discovery surfaces events and (later) matches, not an engagement timeline (doc-47 §7 calm; doc-38 posture).
• Geo depth deferred — v1 discovery = your network + invites; map/radius discovery (doc-15 Maps, doc-17 MapView) comes after there's density to map.
• Discovery Agent (AI matching, doc-15) — post-Release; the Event object must exist before matching over it means anything.
• Fan accounts — guests ride links (doc-26 principals) in v1; a real audience product is its own later pass.
• Trade-off owned: events add a second "clock" to the product (deadlines vs dates). We accept the complexity because timespan + momentum is precisely the owner's thesis — but v1 keeps recurrence, multi-day festivals, and timezone-spanning tours out.

9. Open questions for the stakeholder

1. IA: Discovery as a lens within Browse, or a fourth top-level surface next to Browse / Manage / Configure? (doc-47 fork; affects the Release tab bar.)

   Resolved by doc-54 (2026-07-04): neither — Discovery lives in the Contact tab (owner decision); see the §3 update.

2. Node weight: full doc-49 Portal for Event v1, or card + sheet until usage earns the Portal?

   Resolved by doc-54 (2026-07-04): card + sheet built from the PortalZone grammar (Portal-compatible), no full Portal v1 — graduate when usage demands (host-verb volume · tile depth · afterglow content). Recommendation validated with the owner.

3. Visibility default: is network the right v1 default, and what does "my network" mean before the Contact ID graph (doc-53) is dense — collaborators + invited guests?
4. Which momentum stages ship v1? Draft → Announced → Approaching → Archive feels minimal; is Live (check-in) or Afterglow (recap) worth the extra scope at Release?
5. Studio booking: do Calendar Reservations (doc-15 P3) fold into Event later, or stay a separate object bridged by the calendar?