Glossary
Glossary
The words used across this design. Where a word already means something to attendees, the design keeps that meaning; where the code needs a word attendees never see, it is marked (internal).
| Term | Meaning |
|---|---|
| Site | One installation. Has settings, persons, events, API tokens. |
| Event | One conference or weekend, with days, places, phases and participants. Never used for “something that happened in the system” — that is a change. |
| Day | A calendar date of an event in the event’s time zone, with a bookable window and a slot grid. |
| Phase | Proposal, voting or scheduling. Derived from the event’s phase windows and the clock, never stored as state. |
| Place | Somewhere a session or meeting happens: a room, an area, a meeting point, or “anywhere”. Has floor, directions, capacity, a map pin, and which uses it allows. Replaces today’s location and meeting point. |
| Venue | An event’s places plus its map image and general directions. |
| Person | A human known to the site. Site-wide; profile lives here. |
| Participation | A person’s membership in one event, with their event role (attendee, organizer) and per-event preferences. Replaces guest and the event↔guest assignment. |
| Actor (internal) | Who is acting in a request: a person with an assurance level and roles, a bot with token scopes, or the system. |
| Assurance | How sure the server is that the actor is the person: claimed (picked a name) or verified (join link, code, password or passkey). |
| Proposal | An idea for a session, with hosts, votes and comments. Owned by the proposals module. |
| Vote | Interested / Maybe / Skip, one per participant per proposal. Private to the voter; aggregated for hosts. |
| Session | Something placed on the schedule. Has a kind: session (a talk, workshop, discussion), shift (a volunteer slot needing a minimum headcount), or fixture (an organizer item everyone sees, such as a meal or the opening). |
| RSVP | A public commitment to attend a session. Counts toward capacity. Can be anonymous (counts, name hidden). |
| Mark | A private annotation by a person on a session, proposal or person: star (interested, on my agenda), hide (not for me), note (free text). Never visible to anyone else, never counted. |
| Agenda | A person’s own view: sessions they host or RSVP’d or starred, fixtures, confirmed meetings, with clashes computed. A derived view, not stored. |
| Meeting | A 1-on-1 between two persons in a slot at a place, with a request → accepted / declined / lapsed / cancelled lifecycle. |
| Booking rule | What may be placed where and when: bookable windows per day, bookable places, maximum length, and reserved windows (place × time range × restriction, e.g. “spontaneous sessions only, bookable from one hour before”). |
| Policy (internal) | A pure function deciding a rule: (actor, subject, context) → allow | deny(reason). Lives in domain, used by server and client. |
| Change (internal) | A recorded fact: something that happened, with a type, subject, actor, time, payload and audience. Committed in the same transaction as the state it describes. What other systems call a domain event. |
| Change log | The append-only table of changes, ordered by sequence number. Source of the change feed, of reactions, of notifications, and of the audit trail. |
| Change feed | The per-viewer SSE stream of changes the viewer’s audience permits, resumable from a sequence number. |
| Audience | Who may see a change: the public (public-schedule events only), everyone in the event, a set of persons, a session’s hosts, the event’s organizers. |
| Snapshot | Everything in the viewer’s audience for one event, at one sequence number. What the client loads before subscribing. |
| Replica | The client’s local copy of a snapshot kept current by the feed. Persisted so the app opens offline. |
| Reaction (internal) | A handler in one module that runs after a change from another module was committed, at least once, idempotently. How modules cooperate without calling each other. |
| Notification | An in-app record telling one person something. Delivered additionally over the channels they bound: email, push, chat. |
| Channel | A way to reach a person outside the app: email, web push, a chat platform. Each is an adapter behind one port. |
| Use case (internal) | One command or query in a module’s application layer: authorize, load, apply the domain, record changes, respond. The only thing HTTP, jobs and other modules may call. |
| Kernel (internal) | The server’s shared code: unit of work, change log, clock, ids, actor context, errors. |