Reference
The normative rules behind Event state, visibility, publishing, participation, refunds, money, access, and gating
Reference pages state the rules the running implementation enforces. Each one answers a single question normatively — what values exist, what a transition requires, who may trigger it — and leaves the walkthrough to Guides.
When a Guide and a Reference page appear to disagree, the Reference page is the one written against the code.
Event status
Every state dimension an Event carries, its transitions, and who may trigger each.
Event visibility
Public, unlisted, and private, and what each changes for discovery and links.
Publishing rules
The preconditions publish validates, which edits a published Event accepts, and which changes need a dedicated workflow.
Participation mode
Individual versus team entry, attendance mode, and one Registration per person.
Cancellation
Refund obligations when an Event or a Registration is cancelled, and what buyers are told.
Pricing and tax
Currency exponents, platform fee, tax profile, list versus offer price, and snapshots.
Capabilities
How Capabilities, Roles, Scopes, and API keys compose into authority.
Requirements
Requirement subjects, gates, inheritance, and eligibility evaluation.
How to read these pages
Three conventions run through the section.
| Convention | What it means |
|---|---|
| State is dimensional, not one field | An Event's publication, schedule, sales, visibility, and moderation are separate. A page that says "the Event is cancelled" always means the schedule dimension, and never implies that publication or visibility changed. |
| Derived values are not stored decisions | Where a status is computed — Pass sale state, Event sales state, a Registration's readiness — the page names the facts it derives from, because those facts are what you can change. |
| Additive composition, no negation | Requirements inherit downward and only add. RoleAssignments only add too, but domain operations currently resolve Organization-scoped assignments only; Capabilities states the consequence. There is no "deny" rule, so restriction means adding a condition or removing a grant. |
The dimension map
| Question | Page |
|---|---|
| Can a buyer see this Event? | Event visibility |
| Is this Event live, ended, or withdrawn? | Event status |
| What must be true before it goes live? | Publishing rules |
| Who may enter, and as what? | Participation mode |
| What do we owe if we cancel? | Cancellation |
| What does the buyer pay, and what is tax? | Pricing and tax |
| Who may do this? | Capabilities |
| Why is this Pass locked? | Requirements |
What these pages deliberately leave open
One question is explicitly unresolved rather than answered by a page: place of supply for a hybrid Event's online-attending Registrations. The code applies the Event's participation mode, so those Registrations follow the hybrid venue rule today. Splitting them per attendance mode is an accounting question that requires professional sign-off.