How Discera fits together

An organization is a regional administrative identity. Its home region is fixed when the organization is provisioned, and every team workspace it creates belongs to that organization and region. Personal workspaces stay outside organizations.

Organization roles are Owner, Administrator, and specialist administrator roles for security, compliance, identity, and billing. An Administrator holds every owner power except ownership itself, and a specialist role holds only its named permission. Ownership transfer is an owner-only action.

Organization membership is separate from workspace membership. Creating a team workspace requires an organization owner or administrator, but changing an organization role never rewrites anyone’s workspace role, and removing someone from an organization does not remove their workspace access.

No organization role grants live Run control. Live writes always use Run-scoped host or crew credentials.

A workspace is the ownership silo for host library assets. Activities, Activity versions, Formats, Themes, Brand Kits, Audiences, Events, and Runs (through their source Activity) each belong to exactly one workspace. Every signed-in host also has a personal workspace, so ownership always resolves.

Members hold one of four roles: owner, admin, editor, or viewer. Content outside a member’s workspaces reads as not found rather than forbidden, and writes require the editor role or higher.

Content crosses the silo by copy, never by shared editing. Share links for Content Templates, Formats, Themes, Brand Kits, and Audiences grant snapshot preview and import into another workspace. The imported copy is independent, later source edits do not sync, and Activities are never link-shared directly. Rosters and other people data never cross the silo.

Two exceptions apply: organization owners and administrators can see workspace-level administration and compliance detail, and approved aggregate telemetry may be consented across workspaces. Players are never workspace members; they join Runs by code.

An Event is an optional occasion-planning and reporting object owned by a workspace. It is not a playable room: players join Runs, and a Run may be attached to an Event or created ad hoc without one. Both states are permanent, and every report and retention rule handles both.

An Event carries planning defaults: an advisory schedule window and time zone, a Run language, a default Audience, a Brand Kit, and a Run retention period. Each new planned Run resolves those defaults into its own settings, so editing the Event’s Brand Kit or Audience later never rewrites an existing Run.

Event Pass grants attach to the Event, and every attached Run inherits the most capable active tier. Ad-hoc Runs without an Event use the free capacity.

An Event with finished Runs archives rather than deletes. Deleting is reserved for Events with no Runs or only planned Runs, which are cancelled and detached first.

Each Event-attached Run holds one unique agenda position. Planning a saved Activity onto the Event creates a planned Run at the end of the agenda and inherits the Event’s default Audience when one is set. The agenda is bounded at 100 Runs.

Agenda order is not the content order inside a Run. A Run plays its Activity’s content items in the Activity’s sequence; the agenda only decides which Run comes next for the occasion.

Only planned Runs can be reordered, by pointer, touch, keyboard, or arrow buttons. A Run that has already been opened or played keeps its recorded slot so it cannot move underneath an operator. Adding and reordering require an editor role or higher; an assigned facilitator can still open their own planned Run.

An Activity is the mutable, workspace-owned head that a Run plays. It holds the ordered content items plus its rules of play and visual choices: Session settings that are either Activity-local custom settings or a saved Format, a live Theme reference, and an optional resolved Brand Kit snapshot.

One Activity can be played by many Runs. Its Run history stays attached to the Activity and finished Runs feed Activity-level trends, while each Run keeps the exact version it played.

Editing an Activity changes the head for future Runs. Operating a Run happens in the Host Console against the Run’s pinned version, so a live room never picks up edits made after it started. An Activity created from a Content Template records that template as provenance.

Archiving hides an Activity from new use while its Runs keep resolving. Archival is blocked while a planned or open Run still depends on the mutable head without a pinned version.

A version is cut lazily when a Run pins an Activity revision, normally when the Run starts. The snapshot embeds the name, description, content, and the fully resolved configuration: the effective custom settings or saved Format settings, plus resolved Theme values and branding. A version never keeps a live Theme reference.

An unchanged head revision with an unchanged Theme reuses the existing version instead of cutting a new one. A Run can also be pre-locked to a specific version ahead of time, which lets the Activity be archived without affecting that Run.

A Run that edited its run of show while open is marked as diverged: it still pins a version for provenance but keeps its own local composition. Once pinned, later Activity edits do not affect the live Run.

Run versions preserve played evidence, not a complete authoring history. An Activity can be saved many times without being played, and one authoring revision can produce more than one version after a Theme change, so versions cannot be used to restore earlier drafts.

Content items are the authored building blocks of an Activity: questions, slides, spinner wheels, prize draws, and run-of-show segments such as Q&A spotlight beats and timed activities for breaks and exercises. Every item has one position in the sequence and exactly one payload kind.

Each kind owns its own payload. Questions carry a question type with its answer structure; slides and the passive segments carry rich-text slide content; spinner wheels choose entries manually, from the roster, or from teams; prize draws define the prize and who is eligible.

A content item is not a round. When a Run plays an item live, the item becomes a round with its own phases and results. The authored item stays in the Activity; the round exists only in that Run. An Activity holds up to 50 content items.

Question types are behaviors of a question content item, not lifecycle states. The same round phases apply to every question; the type decides what players see, how they respond, and what a correct answer means.

Scored types award points. Full-credit types such as multiple choice, true or false, image select, audio, and image unblur award full points plus a speed bonus; type-in adds a first-correct bonus; partial-credit types such as estimation, numeric range, ordering, matching pairs, multi-select, map pin, and image pin can award part of the points while still recording the answer as not fully correct.

Unscored types collect responses without a correct answer: polls, priority ranking, point allocation, open-ended text, word clouds, scales, 2x2 grids, canvas drawings, and clickable images. Brainstorm collects ideas and votes and awards a flat bonus to top-voted authors only when the host enables points.

Validation is the source of allowed behavior. Each type has a validator that checks its answer structure, option counts, and limits before a Run can start, and an elimination Run must contain at least one scoring question.

A Format packages pacing, game, and scoring settings: the game mode, time per question, question preview, answer-chart reveal, leaderboard mode, scoring mode and streak bonus, power-ups, eliminated engagement, late-audience participation, Q&A, and message wall settings. It also declares which content kinds it permits.

Discera ships built-in Formats such as Offsite Energizer, Sales Kickoff, Onboarding Cohort, Awards Night, Company Trivia Social, Professional Participation, and Professional Light Competition. Workspace Formats are created in your workspace, from scratch or by saving an Activity’s current settings.

An Activity either uses custom settings of its own or attaches a saved Format by identity. In the Format library, you can edit the scoring, answer reveal, and leaderboard rules of an editable Format. Review the linked Activity and Run impact before saving: Activity heads without custom settings inherit the new rules, while saved Activity versions and Runs keep their rules. Once a Format is captured in an Activity version or locked by a host, use Customize a copy to change its rules. Archiving or deleting an Activity never changes its Format.

After choosing a Format, you can customize its settings for this Activity without changing the saved Format. The Activity keeps its Format association and saves its customized settings separately; later changes to the Format’s defaults do not replace those settings. The Format’s allowed content kinds and Professional presentation requirements still apply. Choosing Use custom settings keeps the current settings and removes the Format association.

A Format is not a Theme. Formats decide how the game is played; Themes and Brand Kits decide how it looks.

Built-in Themes are shipped, ready-to-use palettes. Workspace Themes are created in the selected workspace, with a checked focus treatment so keyboard focus stays visible against the primary, destructive, and surface colors.

Activity heads and Brand Kits keep a live reference to a Theme, so editing a Workspace Theme changes what future Runs will resolve. Activity versions, Runs, and Content Templates keep immutable resolved snapshots, so changing a Theme never rewrites an existing snapshot.

Archiving a Theme hides it from new Activity and Brand Kit selection without deleting it or breaking existing references. A Theme is the visual foundation a Brand Kit builds on.

A Brand Kit combines a Workspace Theme reference with one curated typography choice, optional event and host-company logos, and at most one attribution-only sponsor. It has no call-to-action or sponsor link.

Brand Kits apply to Activities, Events, and Runs. An Event stores the kit as a planning default; each new planned Run, Activity, and Activity version resolves the kit into an immutable snapshot. Reapplying the latest values to a Run is an explicit action available only while the Run is planned.

The lifecycle is archive-first. Archiving a kit invalidates its share links and hides it from new assignment while existing Events and snapshots keep resolving; permanent deletion requires an archived kit with no remaining references. Changing a kit never rewrites history.

Contrast checks on the preview surfaces are advisory and derived from the current Theme. A host’s confirmation is retained, but a flagged automatic result still takes visual precedence.

An Audience is a workspace library object. Each edit, including a rename, appends an immutable revision that carries the join fields players are asked for, an optional roster, the admission policy (open, host approval, or roster check-in) with an optional cap, and reporting segments.

An Event can name a default Audience; planned Runs inherit it or choose their own. When a Run opens it pins the current revision, so open, live, and finished Runs always resolve fields, segments, and admission from that exact revision even if the Audience is edited later. A Run without an Audience stays open to ordinary capacity with no join fields.

Roster names and emails never appear on player, presentation, sharing, or copied-asset surfaces, and share or transfer packages carry configuration only. Segments are reporting groups, never access control.

An Audience is not the people who attend, and it is not the late-audience gameplay role. Attendees become competitors or late audience only when they join a Run.

Each Item Bank item is a workspace-owned canonical snapshot of one content item. Items are discovered by name, tags, and full-text search, and inserted into an Activity as an independent deep copy. The copy never resolves the source live, so editing or deleting either side leaves the other untouched.

Provenance is retained. A copied item records its root bank item across copy-of-copy hops and the immediate item whose media it reuses, and a scored question can carry a performance identity that keeps its reporting history together across routine edits.

Items follow an archive-first lifecycle. Archiving hides an item from routine selection, duplicating can create a new active item from archived detail, and usage in Activities and Runs is tracked so hosts can see where an item was used.

An Item Bank item is one item. A Content Template is a multi-item starting point, and an Activity is the complete playable unit.

A Content Template is a saved, ordered sequence of questions and slides. Loading it into an empty draft applies immediately; loading it into a draft that already has content asks the host to Replace or Append. Neither mode changes the Activity’s title, description, Format, Theme, Brand Kit, or Session settings.

An Activity created from a template records the template as durable provenance. Share links grant read-only import as an independent copy in another workspace and never grant source editing or live synchronization.

Templates archive first. Archiving prevents new loads, duplicates, shares, transfers, and Run sources while existing Activities keep resolving, and permanent deletion requires an archived template with no Activity provenance in its workspace. Restoring never revives an invalidated share link.

A template is not an Item Bank item, which is one reusable item, and not a saved Activity, which is the complete playable unit with its own rules and styling.

A Run moves through planned, open, live, and finished, or is cancelled from planned or open. A planned Run exists without a joinable room and can reserve a printable join code early; joiners see a holding screen until it opens. Opening makes the code joinable and gathers the roster. Going live requires at least one player, at least one question, and a valid host credential.

Starting is a human decision. The host starts the Run from the lobby; only solo demo Runs start automatically. While live, the host advances rounds and can end the Run early, and anyone who joins after the start becomes late audience.

When a Run goes live it pins an Activity version, so later edits to the Activity never change the live room. A rehearsal is a normal Run under its own join code with a simulated participant, excluded from reports and activation evidence.

A finished Run keeps its final leaderboard and evidence and receives an expiry date from its retention policy. A Run belongs to its workspace through its Activity and may be attached to an Event or be ad hoc; one Activity can have many Runs.

Each content item in a Run becomes one round when it is played. Question rounds move through countdown, an optional preview, active, locked, and results; the host can pause any timed phase and resume from where it stopped.

Countdown is a fixed four-second branded intro. Preview shows the question without answering when the Format enables it. Active accepts answers until the timer ends or every alive competitor has answered. Locked closes answering, opens a short confidence window when confidence mode is on, and scores the round exactly once. Results reveal the answer, points, and any eliminations before the host advances.

Non-question rounds use specialized phases: slides skip preview and locking and go straight to results, brainstorm rounds run a submit step and then a vote step, and spinner wheels and prize draws resolve their outcome on the host’s cue.

In a team-mode Buzzer Round, the host opens the buzzer after showing the prompt. The first valid claim the server receives wins the right to answer; this is server receipt order, not a measure of reaction time. No device timestamp or latency adjustment changes that order, and a claim sent to a closed window gets a typed closed, late, or duplicate outcome. The host judges the spoken answer. An incorrect answer locks out the whole team for the rest of that round, including later reopenings; correcting the verdict lifts that lockout. The v1 outcome awards no points, and the host advances after the result is frozen.

A round is neither the Run nor the authored item. The Run lifecycle decides whether play is happening at all; the content item is what was authored; the round is the live instance with its timer, answers, and outcome.

A join code is six letters. Discera generates it randomly, and entry is forgiving: codes are trimmed and uppercased, the digits 0 and 1 are read as O and I, and separators are ignored. A planned Run can reserve its code early for printed material; the code becomes joinable when the Run opens.

Codes are unique among joinable Runs and looked up by exact value. Because finished Runs release their codes over time, lookup is time-aware and tells a player when a code belongs to a Run that has not opened yet, has finished, or has expired.

Admission is checked at join: the Run must be open or live, the player must not have been removed, capacity must remain, and the display name must be acceptable under the Run’s moderation and Audience settings. Players can also arrive by link or QR code.

A join code never grants control. Host actions use a separate host-control credential, crew use Run-scoped operator credentials, and the presentation screen uses its own display token.

Every participant gets an immutable role at join, decided only by the Run’s status. Joining while the Run is open makes you a competitor. Joining after the Run has gone live makes you late audience, and no client setting can change that. Under host approval, the role is decided when the host approves the request.

Lifecycle status is a separate dimension. A competitor is alive, then eliminated, then spectating once the elimination has been shown; late audience enters as spectating without any elimination history. Reconnecting with the same session or a recovery code preserves the role, score, and history; a matching display name or device never transfers eligibility.

Both cohorts can watch the Run and, when the host enables them, use Q&A, the message wall, structured predictions, and audience influence. Each cohort has its own explicit setting and is off by default.

Ghost answers, Ghost Standings, and comeback eligibility remain available only to eliminated competitors. Late-audience predictions can show personal correctness but award no ghost points and create no standing. There is no promotion from audience to competitor.

Team mode is a Format setting with a team count from two to eight and an assignment method. Automatic balancing places each joining competitor on the smallest team, while manual assignment lets the host place players in the lobby; unassigned players are balanced automatically when the Run starts. Only competitors are placed on teams.

Team standings appear only when team mode is on and the game mode has scoring. A team’s score is the sum of its contributing members’ scores, and a team stays alive while at least one member is alive.

Each member keeps an individual score, status, and answer history inside the team row, and the team’s MVP is its top contributing member. Team standings follow the same tie-break chain as players, applied to team totals.

The Format’s game mode is one of Highest Score, No Scoring, Sudden Death, Lives, or Elimination Phases. Highest Score ranks players by points to the end of the questions. No Scoring runs the same content with no points, leaderboards, eliminations, or winners. Sudden Death, Lives, and Elimination Phases are the elimination family.

Team mode and power-ups layer onto the game mode: team standings require scoring, and power-ups are filtered by mode, with none in No Scoring and no Shield in Highest Score.

The ending follows a fixed precedence. The host ending the Run comes first, then running out of questions. In elimination modes the Run also finishes when one competitor remains, or with no survivor when none remain; Highest Score and No Scoring continue to the last question instead.

Sudden Death eliminates a competitor on a wrong answer or timeout. Lives gives each competitor a configured number of lives and eliminates them when the last one is lost. Elimination Phases removes the lowest-scoring share of eligible competitors after each phase, ranked with the tie-break chain; a tie on the cutoff eliminates everyone on that placement, and at least one eligible survivor is always preserved.

Two question-level rules add survival conditions. A multi-select question can require a number of correct selections to survive, independently of partial-credit scoring, and an estimation question can use Highlander, threshold, or bottom-half survival. In Elimination Phases only the threshold rule is allowed.

Elimination is resolved when the round locks, never mid-round, and a Shield power-up can prevent one elimination. When every competitor is eliminated, a last-standing Run finishes with no survivor. Disconnected players are treated as not having answered.

Eliminated competitors keep their leaderboard evidence and move to spectating after the elimination is shown. When the host enables eliminated engagement they can submit ghost answers, appear in Ghost Standings, and be a comeback candidate, with at most one revival per Run. Late audience never has elimination history and never gets those options.

Full-credit answers earn 1,000 base points plus a speed bonus of up to 500 in speed mode, or a flat 1,000 in accuracy mode. Type-in questions add 200 for the first correct submission, partial-credit types award part of the points, and unscored types award nothing. A per-question point multiplier can scale a question’s value.

Configured awards layer on top. A streak bonus grows from the second consecutive correct answer, confidence mode lets a player boost or protect an answer during a short window after lock, and brainstorm can award a flat bonus to top-voted authors. Double Down doubles a fully correct answer and Sabotage halves a target’s speed bonus; other power-ups do not change points.

Team totals sum contributing members’ scores. Leaderboard visibility follows the Format: full standings between rounds, spotlight pages, or final only, where players and the presentation see rankings only once the Run finishes.

Hosts and producers can apply manual score adjustments with a required reason. Each adjustment must be a non-zero whole number that keeps the score within the supported range, is previewed with its rank impact, and is recorded as an immutable audit row; reversals append an inverse row rather than rewriting history. Earned points and corrections stay separate, and the attendee-visible correction total is tracked on its own.

Players tie-break in a fixed order: higher cumulative score, then faster average time on correct answers, then the earlier correct answer in the last completed round. A player with a correct answer in that round ranks above one without. If everything ties, the placement is shared and the next rank number is skipped.

Teams use the same chain on team aggregates: team score, then the team’s average correct-answer time, then the earliest last-round correct answer, with equal teams sharing a rank.

Only real evidence counts. Missing evidence sorts last rather than inventing a value, and the same chain drives Elimination Phases cutoffs, winner determination, and manual-adjustment rank previews.

The catalog is fixed: Shield prevents one elimination, Double Down doubles points for a correct answer, 50/50 removes two wrong options on choice questions, Time Freeze adds ten seconds to the round for everyone, Peek reveals the live answer distribution, and Sabotage halves the top player’s speed bonus.

The host enables power-ups in the Format and sets a count per power-up, up to six per player. Every competitor receives the same loadout at the start, can activate one power-up per round, and loses an activation on a timeout with no refund. Power-ups are off by default.

Availability follows the mode and question: none in No Scoring, no Shield in Highest Score, 50/50 and Peek only on choice questions, and nothing on unscored rounds. Peek activates only while the round is active; the others can also be used during countdown and preview, but not after answering.

Only Double Down and Sabotage change points. Time Freeze applies at most once per round, Sabotage never targets yourself and can stack across players, and eliminated competitors and late audience cannot use power-ups. Audience influence can gift Shield, Double Down, or 50/50 when the host enables it.

Q&A and the message wall are Run-level surfaces that the host enables in the Format; a Q&A run-of-show item only spotlights the existing queue on screen. Brainstorm is a question type played as a round, with a submit step, an optional vote step, and a flat bonus when the host awards points. Predictions and audience influence are engagement settings for eliminated competitors and late audience.

Moderation and rate limits apply to every channel. Submissions can require approval before appearing, an automated profanity filter holds matches for review, image attachments pass an automated safety gate, and a panic control hides all audience feeds at once while hosts and moderators keep full visibility. Players and the presentation see only approved content.

Each cohort has its own setting, off by default. Predictions close with the round’s submission window, and winner or next-elimination predictions exist only in modes where they make sense.

Audience influence is the one channel that can affect active play: votes during the round can gift Shield, Double Down, or 50/50 to a competitor, once per participant per round, and only when power-ups are enabled and the mode has scoring.

Crew-only surfaces: the Host Console runs the lobby and live control for a solo host; the control room adds production, staging, reveal pacing, and moderation, either as panels inside the Host Console or as a dedicated route for a claimed producer; the moderation console is a focused queue, blocked-name, and support view; the presenter stage shows cues, notes, and next-up with an opt-in clicker; the confidence monitor is a read-only stage view.

Audience-safe surfaces: the presentation screen is the projector or TV output with the join code, countdowns, answer progress, reveals, and podium. Players see personal results and rankings only after the presentation’s final reveal completes.

Solo hosts get every control inside the Host Console; a crew gets the same core through dedicated routes claimed with their own credentials. Presenter and confidence views read live Run state through a permission check and never infer access from the address bar.

The program monitor previews the intended output as a read-only 16:9 view. Discera never claims a display is connected or offline because no display telemetry exists, and a panic-hide control sits on every operator surface.

A host adds crew with four presets. Producer runs the show with delegated gameplay controls; Support handles player assistance and moderation queues; Presenter can advance and pause from the stage; Confidence Monitor is read-only. A moderator is simply the Support preset.

Invitations are links that expire 24 hours after creation if unclaimed, with up to 16 crew sessions per Run. Presenter claims require a display label and explicit confirmation because that role can advance play. Only writable host credentials can create, inspect, and revoke crew access; a producer cannot invite more crew.

Every delegated action is attributed in the control-room action log, and taking control is an explicit, logged handoff rather than a race. Crew access is Run-scoped and least-privilege: it never grants host lifecycle actions, templates, exports, or editor access.

Preparation and live actions stay separate. Editors and assigned facilitators can open a planned Event Run; starting, ending, cancelling, and recovering a Run remain host-only.

The ladder is owner, admin, editor, viewer. Owners hold every permission, admins manage editors and viewers, editors create and edit content, and viewers read. Ownership transfer is an owner-only, atomic action.

Facilitator capability is independent of the ladder. It can let a member open an eligible Activity into a lobby, and an Event Run can require exact assignment: an assigned viewer needs both the capability and the assignment to open that Run.

Organization roles sit above workspaces and govern organization administration. They do not rewrite workspace roles or grant workspace membership.

None of these grant a live credential or the active-driver lease. Going live, running the show, and recovering a room require a host-control credential or a Run-scoped crew session.

Three Run-scoped credential families exist, all stored only as hashes: the host-control credential that the host’s browser holds in a sealed cookie, Run-scoped crew credentials issued through invitations, and the presentation display token. The host credential expires 24 hours after issue and is extended only by rotation or a successful recovery.

Every live mutation checks a capability. The host credential holds every capability; crew presets hold the capabilities of their job, so a producer can advance, pause, pace reveals, and run spinners and raffles, while a presenter can only advance and pause active content.

Show-running actions also require the active-driver lease. Exactly one driver holds it; taking control is an explicit, logged handoff; losing or handing off the lease ends the previous driver’s authority; and the lease returns to the host when the driver disconnects. Calls from a stale driver are ignored rather than applied twice.

Join codes, workspace roles, and access to a read-only surface are never enough. Starting, ending, cancelling, and recovering a Run remain host-only regardless of who holds the lease.

Hosts see game-wide insight cards such as the hardest question, the fastest player, and participation trends, plus up to three recommendations for the next Run. Competitors see personal highlights such as their best round and longest streak. Team Runs add team standings. Cards appear only when the data supports them.

Cohorts are summarized separately: eliminated competitors’ ghost answers and Ghost Standings, and late-audience predictions and influence votes. A late-audience personal recap shows only prediction and influence counts and never shows score, place, elimination, winner, or comeback language.

Recaps degrade gracefully when data is sparse and never invent values. Highlights are Run-local callouts, not badges or achievements.

The recap and the retained report share one metric family. The recap is the audience-shaped view; the retained report is the workspace-authorized record.

Two kinds of sharing exist. Library share links let an owner or admin share a Content Template, Format, Theme, Brand Kit, or Audience for preview and import as an independent copy in another workspace. Links expire after 30 days, can be revoked, and never grant source editing or live sync.

A public recap snapshot is a host-approved, immutable summary of a finished Run: title, participant count, completed questions, and outcome, with winner or team names only when the host chooses to disclose them. Creating a new snapshot revokes the previous one, so one link per Run stays usable.

Links fail safely. A revoked recap link asks the recipient to contact the sender without explaining why, an expired Run’s link states that the recap is gone, and unusable library links all look the same to the bearer.

Sharing never transfers live control or workspace membership.

Any member of the owning workspace can open a Run’s report. It shows the Activity and version, the linked Event, lifecycle timestamps, and the real-participant context, then the recap, standings, question insights, join-field breakdowns, Q&A, and engagement cohorts when their source data exists.

Detail follows lifecycle. A finished Run gets a full report. A cancelled Run with at least one completed question gets a partial report limited to participation, completion, and timing, with no outcomes or winners. Rehearsals, unfinished Runs, and cancellations without a completed question show an explicit unavailable reason.

Exports include result worksheets and audit worksheets. Participant names are replaced with Run-local labels unless the host explicitly includes them for one download. Activity-level trends compare the latest Runs without exposing participant-level history.

Reports use workspace permissions with not-found semantics, and no player-facing route exposes them. The public recap is narrower than the host report.

Run and participant data are kept for an approved period of 1, 7, 30, 90, or 365 days after a Run finishes or is cancelled, with a default of 30 days. Other purposes have their own rules: generated exports keep a short server copy, identifiable analytics are limited to 30 days, and audit evidence is retained for one to seven years.

The effective policy resolves from the most specific choice: the Run or Event selection, then the workspace default, then the organization default, then the system default. Organizations can narrow the approved range, and invalid or out-of-range settings fail closed rather than being silently adjusted.

Legal holds suspend erasure. Participant erasure removes identifiers and responses, updates facts derived from surviving participants, and keeps a minimal receipt. Account or workspace deletion detaches or removes records according to the same purposes.

Retained facts are not indefinitely available content. Content-free tombstones and receipts remain as evidence after the underlying content is deleted.

When a Run finishes or is cancelled, its expiry date is stamped once from the resolved retention policy and does not change afterwards. From that moment the Run is unavailable to join, read, and recovery flows; the join code reports the Run as expired and later, after cleanup, as not found.

Daily cleanup deletes the expired Run with its rounds, players, answers, engagement data, and control-room history. The public recap link is replaced by a content-free tombstone so the link keeps returning a clear gone message instead of looking like a fabricated address.

Exports have their own download window, and library share links expire 30 days after creation. Failed storage deletions are retried, and separate processor backups are reconciled on their own verified schedule.

Expiry is not archiving. Archiving a library object is a reversible, read-only state that keeps existing references resolving; expiry is time-based deletion eligibility.