The Pub is one product with several audiences: patrons use public pages, venue screens present glanceable information, and authorized staff use protected workflows. The service coordinates those experiences while keeping identity, product authorization, and venue control as separate boundaries.
At a glance
flowchart TB PATRON["Patron browser"] --> PUBLIC["Public pages and APIs"] DISPLAY["Venue displays"] --> PUBLIC OPERATOR["Authorized operator"] --> ACCESS["Identity and product access"] ACCESS --> OPS["Protected workflows"] PUBLIC --> SERVICE["Pub application service"] OPS --> SERVICE CALENDAR["Published calendar projection"] --> SERVICE SERVICE <--> VENUE["Limited venue adapters"] SERVICE --> DATA["Product data and media"]
Responsibilities
| Part | Responsibility |
|---|---|
| Public pages | Present hours, events, people, specials, setlist information, and patron participation flows |
| Venue displays | Turn selected public information into large, glanceable layouts |
| Protected workflows | Let authorized staff manage schedules, content, feedback, and temporary display changes |
| Pub service | Validate requests, apply product permissions, shape data for each audience, and coordinate updates |
| Published calendar source | Supply a limited set of approved event information for Pub surfaces |
| Venue adapters | Exchange narrowly scoped status or commands with on-site systems |
The website and displays do not receive administrator privileges. Venue integrations do not receive general product access. Each boundary exposes only what the receiving surface needs.
Identity and authorization
Staff identity is established before a protected request reaches the product. The Pub then checks its own role assignment for every action. Shared sign-in therefore answers who is this? while Pub authorization answers what may this person do here?
See Admin access and permissions.
Data flow
Published information
Public pages read presentation-ready information from the Pub service. Event data arrives through a limited publishing projection rather than through access to another product’s internal records. See Calendar event source.
Operator changes
An operator action passes through product admission and a capability check before it changes data. The resulting public view is generated from the accepted state; the browser is not trusted to enforce permissions or validate business rules on its own.
Venue state
On-site components exchange only the information needed for a specific experience, such as current media status or a bounded display action. The public site does not expose device-control interfaces or the venue network.
Reliability principles
- Public surfaces prefer the last useful, validated information over a partially malformed update.
- Venue screens recover automatically from ordinary network interruption and show a clear fallback when current data is unavailable.
- Temporary display changes end automatically if an operator forgets to stop them.
- Protected changes are recorded so operators can understand what happened without relying on device logs.
- A failure in an optional feature should not grant access or make unrelated protected actions less strict.
Privacy boundaries
The product publishes only information intended for patrons. Staff availability, contact details, role assignments, feedback details, moderation queues, and operational records remain protected. Public music history describes what was heard in the room and is not linked to a listener identity.
This page intentionally describes responsibilities and guarantees rather than production configuration, schemas, device identities, or recovery procedures.