MyNATCA Updates

What these mockups are for

This is Phase 0 of the Updates system — a visual spec before we write any functional code. The goal is to lock down the UI and interaction patterns so we can build the real Vue components (Phase 2) and Platform API (Phase 1) against a clear target.

Data model — Topic → Story → Update

• Topic — what a story is about (national, legislative, safety, etc.). Drives display grouping, Discord channel routing, and email list mapping.
• Story — a headline + stable summary that accumulates updates over time. Think news liveblog. Has status (Live / Active / Resolved). One URL.
• Update — a timestamped entry under a story. Has a kind (Update / Breaking / Correction / Summary). This is what actually gets posted to Discord and (future) email.

Single announcements (like "Registration open for CFS conference") are just stories with one update. The data model is uniform.

Three member-facing concepts to keep separate

• Topic — the category (above).
• Subscription — a member's per-topic email delivery preference. Maps to Constant Contact list membership (future).
• Display filter — what a member's dashboard card shows. Independent of email. Full /updates page always shows everything.

Urgent flag is orthogonal: pins to top of Hub regardless of filter, always posts to Discord, (future) always emails the full active-member list.

Editor: Tiptap (rich text) with markdown stored alongside

Authors use a Tiptap-based WYSIWYG editor — no markdown syntax required. Images drag-drop into Supabase Storage. Under the hood we store three formats per update: body_json (Tiptap canonical), body_md (derived, for Discord + portability), body_html (derived cache). See the author mockup for the toolbar and rich content area.

AI search via pgvector (built-in from Phase 1)

Every published update gets an OpenAI embedding stored in Supabase's pgvector. Members can eventually ask natural-language questions like "What's the latest on H.R. 4412?" and get synthesized answers with citations back to the source stories. Data starts accumulating from day 1; the search UI lands in Phase 5. See ADR 001 for the RAG flow.

Why liveblog-style stories?

The current fragmented approach creates multiple disconnected posts about the same topic (e.g., three separate emails about the same shutdown negotiation). Members can't find the latest state of a story, and older context is lost. A liveblog model — like MS.now, Guardian rolling coverage, or NYT live updates — keeps everything about a story on one page, so members always land on the canonical, up-to-date view.

Topics in v1

• National — mandatory by default, but members can unsubscribe
• Legislative — political action, bills, advocacy
• Safety — safety bulletins
• Labor Relations — contract and negotiations
• Training — professional development
• Benefits — member services
• Events — conferences and meetings

New topics can be added by inserting a row in updates.topics. The schema is fully extensible.