KBYG, role-scoped: the Boarding Pass pattern, now native

When Black Coffee's team published their interactive KBYG for the 2025 North American tour, it did something every production team has tried and failed to do with a PDF: it gave each persona exactly the information they needed, scoped to their role, and let the production team update it the morning of the show.

We liked it enough to copy the pattern into the platform. Event guides are now a first-class module in Atlas, rendered on both Gateway (portal) and Compass (mobile) from one source of truth, with zero duplication.

The problem with PDF KBYG

A PDF can't be scoped by role. A guest and a production carpenter see the same document. So you either write one bloated PDF that confuses the guest with SOPs and PPE they don't need, or you write three PDFs and try to keep them in sync.

A PDF also can't be updated at 9am on show day when the weather changes the load-in schedule. You can generate a new PDF, rename it, re-upload it to a link, and hope every stakeholder refreshes from the new one. They won't.

One source of truth, six persona renders

An event guide is a single row in event_guides per project × persona. The JSONB config column holds a typed list of sections: overview, schedule, set_times, timeline, credentials, contacts, faq, sops, ppe, radio, resources, evacuation, fire_safety, accessibility, sustainability, code_of_conduct, or custom.

In Atlas CMS, you author one canonical guide. In the portal (Gateway) and mobile (Compass), a single <GuideView> component renders the sections that viewer's persona is entitled to see. A guest sees parking, schedule, FAQ. Crew sees radio channels, SOPs, PPE. Same data, filtered view.

The guest guide is public. The crew guide is not.

Guests shouldn't need to sign up to read the KBYG, so the guest copy is readable straight from the database with no link obfuscation, no anon token and no secret URL. It's public because it's supposed to be public.

The first version of that policy said only "published", and we wrote it up here as a win. It wasn't finished. Published is a state, not an audience: the same rule that opened the guest copy also opened the crew and staff copies, radio channels and SOPs included, to anyone holding the public API key. The tier gate was real, but it lived in the application, and the database is reachable without going through the application.

The policy now names the audience as well as the state: published, and a persona that is actually public. Everything above that tier needs an org session or a redeemed access code, and the code half is checked where a code can be seen. If you take one thing from this section, take that a check only protects the doors it stands in front of.

What we kept from the Boarding Pass original

• Tier 1–5 classification banners for venue zones
• Role-based timeline views (artist vs. crew vs. security)
• Radio channel allocations surfaced per persona
• Offline-accessible on the crew phone via Compass service worker

What we added

• CMS editor with draft → preview → publish flow
• Version history, so you can roll back any publish from Atlas
• Server-rendered PDF export for the handful of stakeholders who still print it
• Branded per project: logo, accent color, hero imagery overlay --p-accent

Start using it

Event guides are live on the Team plan and above. Open any project in Atlas, tap Guides, pick a persona, and you're in the editor. Read the full how-to at /guides/what-is-kbyg.