Trust Lite

Security review packet

A compact description of how Discera is built, what data moves where, how long it is kept, who processes it, and what Discera does not offer yet. Written so a pilot buyer can forward it to their IT or security reviewer.

How to read this packet

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

This packet describes Trust Lite: the posture Discera supports for corporate pilots. It is not an enterprise compliance package and does not stand in for a certification report, an audit, or a legal security appendix.
This packet distinguishes implemented controls, documented setup guidance, and verified production operation. Where a control does not exist or production operation has not been verified, this packet says so rather than presenting an intention as an operating fact.
The public privacy page remains the policy source of truth. This packet explains the implementation boundaries a security reviewer needs in order to assess a pilot.

Architecture

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Discera is a web app backed by a hosted realtime database, with sign-in, diagnostics, and optional AI features supplied by named third parties. Nothing below is required reading order; a reviewer can start at whichever row their checklist covers.

Discera architecture components and their boundaries
Component	Role	Data handled	Boundary
Discera web app	Serves the public pages, host authoring, player, presentation, and moderation surfaces, and runs the same-origin server routes that carry privileged host operations.	Request metadata such as IP address, user agent, route, headers, and timing. Holds sealed host credentials server-side for privileged calls.	Hosted on Vercel. Privileged host operations are the ones routed through this origin, and the raw host control secret is never returned to the browser by those flows.
Discera backend and database	Stores and serves live game state, host accounts, uploaded assets, and moderation records, and runs the scheduled jobs that delete expired data.	Game content, player nicknames, answers, audience posts, moderation decisions, uploaded media, host account records, and hashed host credentials.	Hosted on Convex. Host control, recovery secret, and paper recovery code values are stored only as hashes, so the stored form cannot be replayed as a credential.
Host sign-in	Authenticates host accounts. Players never authenticate and never create an account.	Host email, name when available, authentication identifiers, and login session metadata.	Auth0 is the only configured account provider. Deleting a Discera account does not delete the Auth0-side identity; that removal is handled by an operator on request.
Diagnostics and analytics	Receives operational error diagnostics for the documented live-event support and alerting model, plus consent-gated product analytics and session replay.	Errors, canonical route templates, request context, pseudonymous identifiers, and consented product events and replay.	PostHog plus retained first-party Convex commercial attribution. Diagnostics are always on when configured; product analytics and session replay run only after a visitor accepts analytics, and the retained commercial attribution was likewise created only after that consent. Raw game codes, internal game identifiers, and gameplay session identifiers are excluded or redacted from PostHog; direct commercial Event/Workspace/Run/Activity provenance stays first-party and excludes participant identity and content.
AI authoring	Drafts quiz questions, answer options, and non-question segment content when a host explicitly asks for it.	The host prompt and authoring context for the requested feature, plus optional uploaded source PDF content.	OpenAI. Optional. A pilot deployment can be configured so no AI-backed call is made at all and the related controls are omitted from the product.
Brand theme extraction	Returns brand colors, title metadata, and logo candidates for a submitted company website.	The domain extracted from the submitted public company website, and the returned brand metadata.	Context.dev. Optional, and covered by the same no-AI pilot switch as AI authoring.
Maps and embedded media	Serves place search and map tiles for map-pin questions, and video embeds for slides that use them.	Place search text, map tile requests, and browser requests for the authored embed URL.	Nominatim/OpenStreetMap, CARTO, YouTube, and Vimeo. Triggered only when a map or an embedded video is actually rendered.

Trust boundaries

A host browser never receives the raw secret that authorizes writes to a live game. Privileged host operations go through same-origin server routes, which hold the secret in a sealed cookie that page scripts cannot read, that browsers do not attach to cross-site form posts or embedded requests, and that is unsealed only on the server.
Browsers also hold a direct realtime connection to the backend for live game data, which is what makes the event update instantly on every screen. Privileged host operations are the ones that deliberately do not use it, and go through the app server instead.
The backend stores the host control token, the host recovery secret, and the paper recovery code only as hashes. A database copy is therefore not usable as a credential.
Being signed in as the account owner is not the same as holding live write control. An owner can read their own host console, but host writes additionally require an active host control credential.
Player browsers hold no account and no host credential. Their reads are scoped to the game they joined, and pending or rejected audience content is excluded from those reads entirely rather than hidden in the client.
Moderator browsers hold a separate game-scoped credential that reaches moderation and Q&A surfaces only. It grants no host lifecycle, template, export, or editor access.

Identity, sessions, and the token boundary

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Discera separates three things that are often collapsed into one: who you are, which browser you are on, and whether you may currently write to a running event.

A host signs in through Auth0. The backend trusts the resulting identity and maps it to a Discera account record, which anchors saved templates, custom themes, account export, and account deletion.
Every browser also carries a per-browser session identity. For players this is the whole of their identity: there is no account, no password, and no profile that follows them between events.
Live host control is a separate, game-scoped credential issued when the game is created. It is what actually authorizes host writes, and it can be rotated without touching the account.
Because the two are separate, losing a browser does not lose the game, and having an account does not silently grant control of someone else's event.

Host control, recovery, and moderator delegation

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

A live event cannot afford to be locked out, and it cannot afford to hand a helper the keys to everything. These are the paths that exist.

Recovering host control

Transfer link: a host opens a link carrying the recovery secret, which rotates a fresh host credential into that browser.
Signed-in owner: the owner of an account-backed game recovers control without any secret, because the backend can verify the account against the game.
Paper recovery code: a single-use code issued at game creation covers the lost-device case. It is burned on use, writes an audit record, and rotates fresh credentials.
Every recovery path rotates the credential and advances a version counter, so previously issued host credentials stop working.

Delegating to a moderator

Moderator access is granted per game through an invite, not by sharing host credentials.
An invite binds to the first browser that claims it; a second browser is rejected. Unclaimed invites expire 24 hours after they are created, which is enough for day-before event preparation without leaving a standing door open.
A claimed moderator session stays valid until it is revoked. A game supports up to 16 active moderator sessions.
Moderators provide a self-chosen display label when they claim an invite, and that label is copied onto every moderation record they produce, so the audit trail still attributes the action after the session is revoked or relabeled.
A host can revoke one leaked invite individually or revoke every active session at once.

Data flows

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Each flow below states what leaves the browser, where it is processed, who can read it, and how long it stays.

Player join

Trigger: A participant enters a game code or opens a join link. No account is created and no sign-in is required.
What moves: The browser sends the chosen nickname, avatar selection, and a per-browser session identity to the backend. Display names are checked against the blocked-name rules before the participant is admitted.
Who can read it: The host, any moderators for that game, and other participants where the live experience shows player names.
Retention: Stored with the game and removed by the finished-game cleanup described in the retention section.

Live gameplay

Trigger: The host runs the event and participants answer from their own devices.
What moves: Answers, scores, and round state move between participant, host, and presentation surfaces over the live backend connection. Running the event reaches only the app and its backend; the AI and enrichment processors are not involved in gameplay.
Who can read it: Scoped to the game. Host and presentation surfaces see what the format exposes; participants see their own submission plus whatever the format publishes to the room.
Retention: Stored with the game and removed by finished-game cleanup.

Moderation

Trigger: A participant submits free text on a surface where review is enabled, or an automated term check holds a submission.
What moves: The submission is stored as pending and enters the review queue instead of being displayed. An optional automated term check can hold content for review; it records that it acted without writing the matched term into the audit record.
Who can read it: Pending and rejected content is excluded from participant and presentation reads. Host and moderator review surfaces keep it visible so a decision can be made or reversed.
Retention: Every decision writes a moderation record that is included in the finished-game host export, and is removed with the game.

Account export and deletion

Trigger: A signed-in host requests an export or a deletion.
What moves: Export returns a machine-readable file covering account profile fields, saved templates, custom themes, upload references, and retained game metadata. Deletion removes the account record, its sign-in rows and sessions, saved templates, custom themes, entitlements, and uploads that nothing else references.
Who can read it: The signed-in account holder.
Retention: Games the host created are detached from the deleted account and then follow normal game retention. Removal of the Auth0-side identity is handled by an operator on request. For signed-in hosts who accepted analytics, deleting the local Discera account does not automatically remove the PostHog person profile or consented product-event history linked to the account. Any consented session replays are retained separately and are not removed by local account deletion. PostHog analytics and session replays are typically retained for up to 12 months. Email privacy@consensus.dk to request operator-handled removal of the PostHog person profile, associated events, and session replays.

Diagnostics and analytics

Trigger: Diagnostics run whenever the app loads and diagnostics are configured. Product analytics and session replay run only after a visitor accepts analytics.
What moves: Diagnostics send errors, canonical route templates, and request context. Game routes are reduced to templates, and raw game codes, internal game identifiers, and gameplay session identifiers are excluded or redacted from PostHog. Historical commercial-prompt attribution keeps direct Event/Workspace/Run/Activity provenance only in first-party Convex storage, without participant identity or content.
Who can read it: The Discera engineering team, through the diagnostics provider. Diagnostics are used to keep live events working, not for advertising.
Retention: Diagnostics are typically kept for up to 90 days; consented analytics and session replay for up to 12 months.

AI authoring

Trigger: A host explicitly asks Discera to generate quiz content, answer options, or non-question segment content, or to build a theme from a company website.
What moves: Only the material needed for that request is sent to the relevant processor. The subprocessor section below lists exactly what each feature sends.
Who can read it: The requesting host and the relevant processor.
Retention: Generated drafts follow the game or template the host saves them into. Processor-side retention follows that processor's terms.

Retention matrix

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

This is the same inventory published on the privacy page, reproduced here so the packet is self-contained.

Discera retention and data inventory
Area	Data included	Scope	Retention and cleanup	Notes
Browser storage and cookies	Analytics consent, PostHog browser/session identifiers, host credentials, host-transfer and recovery flags, create drafts, preview data, join preferences, and sound or pacing preferences.	User/browser-scoped localStorage, sessionStorage, cookies, or history.state. These are not server account records.	sessionStorage and history.state entries last for the tab or browser session. localStorage lasts until the user clears it. The analytics consent cookie expires after 1 year.	Account deletion does not reach data stored only in the user's browser; users can clear site data locally at any time.
Run and participant data	Run metadata, immutable Activity snapshot, content items, rounds, round timing, players, nicknames, host-configured join details such as department or table, answers, scores, Q&A, message wall posts, brainstorm ideas and votes, moderation events, control-room state/events, operator sessions, display-name overrides, and blocked join attempts.	Server-retained Convex data scoped to the Run.	Retained while the Run is active. When the Run finishes or is cancelled, Discera sets an expiry from an approved 1, 7, 30, 90, or 365-day attached Event override, then the workspace and organization defaults, then the 30-day system fallback. Lower-level values must remain inside organization constraints. Expired Runs become unavailable, and daily cleanup removes the Run row plus cleanup-covered live-Run records such as rounds, players, answers, Q&A, message-wall, brainstorm, moderation, control-room, operator, display-name, blocked-join, score, and storage-reference rows.	Hosts and players can see Run data where the live experience requires it. Feature-specific audit and operational records follow their owning cleanup paths.
Audience rosters and participant data-rights records	Host-entered participant display names and email addresses, historical links to Run players, verified export/erasure workflow state, hosted-recap redaction evidence, external Teams follow-up outcomes, legal holds, and privacy-safe audit receipts.	Workspace-scoped Convex data. Roster PII is available only to authorized signed-in editors/controllers and a current host for the matching Audience-bound Run; it is never shown to participants or included in sharing, copy, move, presentation, or analytics payloads.	Roster entries remain until archived or erased by a verified participant request. Link snapshots remain for Run history until Run cleanup or participant erasure strips their identifying fields. Pending requests temporarily retain the normalized address and verification evidence. If erasure processing fails but can recover, Discera retains the normalized address and minimal phase/cursor identifiers needed for automatic retry while scrubbing verification evidence immediately. Completion or exhausted recovery removes that transient context and retains only a hashed idempotency key, request kind/status, timestamps, affected count, hosted-recap counts, external-copy outcomes, and non-identifying audit receipts. Active legal holds suspend erasure and release resumes it.	Workspace owners/admins or organization owners/admins handle verified access, portable JSON/CSV export, erasure, and holds. Erasure removes covered active identifiers, metadata, responses, uploads, standings, embedded references, and identity-linked names in hosted recap links. The retained receipt and any aggregates do not identify the participant. Recipient-controlled Teams cards use a receipted owner follow-up when existing permissions cannot remove them; processor backups follow separately disclosed windows.
Portable workspace exports	Revision-pinned ZIP packages with JSON, CSV tables, integrity checksums, explicit omissions, and durable controller-visible job receipts.	Discera-held package storage and download handles remain under Discera control. Once downloaded, a controller-held copy is outside Discera control.	Discera normally retains a generated package for up to seven days. Participant erasure invalidates every earlier queued, running, complete, or incomplete export that could contain the participant before completion, deletes any Discera-held package, and revokes its download handle. The non-content job receipt remains. A later export is generated from post-erasure canonical state.	Controllers must store downloaded copies securely and retain or delete them under their own policy. Participant erasure cannot recall a file already saved outside Discera.
Uploaded Activity and Run assets	Question media, slide media, audio, canvas images, player avatars, answer thumbnails, generated assets, and source files registered to an Activity, Run, or content item.	Convex storage objects plus storage-reference rows owned by the Activity, Run, content item, round, or related runtime record.	Follows the owning Run through its resolved retention window, then is removed by expired-Run cleanup when no other owner references the storage object.	Shared or reused storage is deleted only after Discera confirms no saved owner still references it.
Draft or abandoned uploads	Source PDFs, generated theme logos, images, audio, and canvas media uploaded while drafting but not saved into an Activity, template, theme, or account-owned asset.	Short-lived upload-capability rows containing the session scope, purpose, token hash, lifecycle status, and timestamps; Convex uploaded-file rows; storage objects; and bounded cleanup diagnostics. Capability rows retain a token hash rather than the client-held token.	Upload capabilities expire after ten minutes. A bound capability can be extended in five-minute increments while deletion and durable cleanup-job persistence both fail. Unadopted draft uploads are retained for at least 24 hours; after that, daily cleanup removes them when no saved owner references the storage object.	If a draft upload is saved or adopted, it follows the saved owner and validated ownership removes matching cleanup diagnostics. Failed best-effort deletes can be retried by cleanup jobs. Terminal cleanup diagnostics omit caller-linked context and are removed at an eligible reconciliation sweep after the object is deleted or confirmed absent, gains a durable owner reference, or is superseded by newer uploaded-file ownership metadata.
Host account data and saved assets	User profile fields, local Convex auth rows/sessions, entitlements, saved Activities and templates, custom themes, theme/template upload references, account-linked upload metadata, pending workspace invitations addressed to the verified account email, invitation creator references, and commercial-prompt cooldown state. Account export includes its documented account-owned records and retained Run metadata, but excludes commercial-prompt cooldown and attribution rows.	Convex account tables and account-owned storage references.	Retained until the host deletes the account or asks Discera to remove it. Local deletion removes the account row, linked auth/session rows, saved templates, custom themes, entitlements, commercial-prompt cooldown and attribution rows, unreferenced account uploads, and pending invitations addressed to the normalized verified identity email. Invitation audit email and ID fields are redacted first. Invitations created by the account remain usable with their creator reference removed.	Runs created by the host are detached from the deleted account and stay only until their normal Run-retention expiry. A content-free deletion receipt remains unfinished until the bounded invitation cleanup completes; it never stores the email address.
PowerPoint deck connections	SHA-256 fingerprints derived locally from compressed deck bytes, opaque deck-link IDs, workspace relationships, retry request IDs, revision state, and lifecycle audit events. Deck bytes, slide content, titles, and filenames are not uploaded. Static slides written locally into a presentation can include source titles, the source Theme’s colors and uploaded logo, an active join code/link, winner display names, or participation totals, plus hidden provenance tags holding opaque source and generation-event IDs, the source and asset kinds, a source revision, a generation timestamp, and the Discera asset version.	Convex link/audit tables, PowerPoint settings, and saved copies.	Personal-workspace links and events are removed through bounded background cleanup after account deletion. Team-workspace links and audit evidence remain with the team; deleted creator and actor identifiers are anonymized. Discera retention and account deletion cannot remove static slides from presentations or copies saved and shared by the host.	Access-denial evidence, including denied static-slide generation, is retained as internal workspace security evidence and is not included in the probing account’s self-service export.
Workspace offboarding	Workspace-owned Activities, templates, Runs and participant/runtime rows, memberships, invitations, share links, edit leases, exports, PowerPoint links, and workspace audit detail.	The selected personal or team workspace in the regional Discera application database and storage. Independently copied assets in another workspace are destination-owned and survive.	A confirmed deletion makes the workspace unavailable immediately, cancels planned Runs, and targets verified product-visible cleanup within 24 hours. A minimal no-content receipt is retained for one year. There is no grace period or recovery window.	Open/live Runs and active supported legal holds block confirmation. Export is offered but failure or non-download does not delay deletion. Product completion and processor-backup deletion are separate states; backup verification follows provider operations and evidence.
Auth0 identity	Provider-side identity, Auth0 login/session metadata, and upstream identity-provider session data where applicable.	Auth0 and any upstream identity provider systems.	Manual deletion boundary: deleting the local Discera account does not automatically delete the Auth0-side identity. Email privacy@consensus.dk for operator-handled Auth0 identity deletion.	Retention follows Auth0 and upstream identity-provider configuration and processor terms.
Diagnostics and analytics	Essential error and canonical route diagnostics, memory-only pseudonymous diagnostics identifiers, request identifiers, optional PostHog product events without internal Run or gameplay-session identifiers, bounded sanitized failure details, consented session replay, signed-in account attribution, historical first-party commercial-prompt attribution with account and Event/Workspace/Run/Activity/version provenance, and public FAQ questions, generated manual answers, and cited manual concept keys. Historical commercial attribution contains aggregate content counts and feature-use flags, never participant identity or participant content.	App telemetry, Convex attribution, and configured PostHog.	Essential diagnostics are typically retained for up to 90 days. Consent-gated PostHog analytics and session replay are typically retained for up to 12 months. First-party commercial attribution is deleted with its retained Run or local host account, whichever occurs first. Public FAQ question records are eligible for deletion 90 days after they are asked and are removed by the next successful daily cleanup; OpenAI, Vercel, and other provider or log retention follows their separate terms.	Essential diagnostics are used to keep live Runs reliable. Optional analytics and session replay run only after analytics consent. For signed-in hosts who accepted analytics, deleting the local Discera account does not automatically remove the PostHog person profile or consented product-event history linked to the account. Any consented session replays are retained separately and are not removed by local account deletion. PostHog analytics and session replays are typically retained for up to 12 months. Email privacy@consensus.dk to request operator-handled removal of the PostHog person profile, associated events, and session replays. Public FAQ question records have no structured account or workspace reference, but free text can identify the visitor. Retained first-party commercial attribution was likewise created only after analytics consent; no new attribution is written. Direct Run provenance stays first-party and is not sent in typed PostHog events.
Security and abuse-control records	Pseudonymous AI authoring caller keys, rate-limit counters, violation history, and temporary lockout state.	Server-retained Convex rate-limit data.	Rows become eligible for cleanup after one hour without an update. Cleanup runs daily, so a row can remain for up to about 25 hours after its last update.	The AI caller key is derived from the client address and changes at each UTC day boundary; Convex does not receive or store the raw address.
External processors	Vercel, Convex, Auth0, PostHog, Stripe, Microsoft Teams Workflow, OpenAI, Context.dev, Nominatim/OpenStreetMap, CARTO, YouTube, and Vimeo.	Third-party processor systems used for infrastructure, authentication, diagnostics/analytics, commerce, host-configured workflow delivery, AI/enrichment, maps, and embedded media.	Retention follows each processor's terms, configuration, and feature-specific setup. The Stripe-side customer record and retained commerce evidence survive local account deletion under the commerce retention lifecycle. Cards already delivered to Microsoft Teams are recipient-controlled; when existing permissions cannot remove an affected recap card, Discera records an owner follow-up requirement.	Discera does not promise data residency, vendor no-retention, DPA coverage, SOC 2, ISO, or similar enterprise commitments unless those terms are separately documented.

Subprocessors and AI data use

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

These are the processors that current production-relevant flows can reach, what each is used for, and whether the use is always on, feature-triggered, or consent-gated.

Discera does not claim vendor no-training terms, no-retention terms, DPA coverage, SOC 2, ISO certification, or other enterprise processing commitments here unless those terms are separately documented and evidenced for the current account and vendor setup.

Required infrastructure and account services

These processors support hosting, storage, authentication, and live Run operation.

Required infrastructure and account services processor disclosure
Processor	Purpose	Data categories	Use
Vercel	Hosts the Next.js app, serves public pages and app routes, and runs server-side route handlers.	HTTP request metadata such as IP address, user agent, route, headers, and request timing for app traffic.	Always-on infrastructure when the app is used.
Cloudflare Turnstile	Protects the public playable-demo launcher from automated Run creation.	Browser and request signals needed to distinguish legitimate visitors from automated traffic, including IP address, user agent, challenge outcome, request hostname, and timing metadata. Demo form content is not sent to Turnstile.	Feature-triggered when the public /demo launcher is opened and a visitor starts a demo.
Convex	Stores and processes Activity definitions, live Run state, uploaded assets, account-linked host data, sessions, and backend function activity.	Host account identifiers, Activity content, Run state, player nicknames, answers, uploaded media or source PDFs, custom themes, browser session IDs, hashed host credentials, pseudonymous AI abuse-control rate-limit keys, and PowerPoint deck fingerprints, opaque link identifiers, workspace relationships, and lifecycle audit events.	Always-on infrastructure for Activity, Run, and account features.
Auth0	Provides sign-in for host accounts through Convex Auth.	Signed-in host identity data such as email, name when available, authentication identifiers, and login/session metadata.	Feature-triggered when a host signs in or signs out.

Diagnostics and analytics

Diagnostics help keep live Runs reliable. Product analytics and session replay are separate and require analytics consent.

Diagnostics and analytics processor disclosure
Processor	Purpose	Data categories	Use
PostHog	Receives operational diagnostics, optional analytics events, and optional session replay.	Errors, canonical route templates, memory-only pseudonymous PostHog and browser-session identities, request context, optional usage events without internal Run IDs, raw join codes, or gameplay session IDs, bounded sanitized failure details, persisted analytics identifiers, session replay data when consented, and signed-in account attribution when analytics are accepted.	Always-on diagnostics when configured; analytics and session replay are consent-gated.

Optional commerce and workflow integrations

These processors receive data only when a host uses paid commerce, its resulting billing lifecycle is processed, or a host tests, configures, and sends to a workflow destination.

Optional commerce and workflow integrations processor disclosure
Processor	Purpose	Data categories	Use
Stripe	Processes Host Pro subscriptions and Event Pass purchases, including hosted checkout when available, billing management, payment lifecycle, refunds, disputes, and reconciliation.	Host billing identity such as account email and name, payment and billing information entered directly into Stripe-hosted Checkout, Stripe customer references, subscription and purchase state, checkout attempts, invoice and payment status, product and price references, and Discera reconciliation metadata. Raw payment credentials entered in Stripe-hosted Checkout are not received or stored by Discera.	Feature-triggered when a host starts or manages Host Pro or purchases an Event Pass, when those purchases are available. New checkout is currently suspended; existing checkout, purchase, subscription, cancellation, refund, reconciliation, and billing-portal records continue through their normal lifecycle. Deleting the Discera account detaches local identity and schedules a current subscription to cancel at the end of the paid period; the Stripe-side customer record and retained commerce evidence remain under the commerce retention lifecycle.
Microsoft (Teams Workflow)	Posts a connection-test card to a host-submitted Microsoft Teams Workflow destination, then posts host-approved join, start, and recap cards after the destination is configured.	Connection-test message, Run title, join code, scheduled timing, join and recap action URLs including the public recap access capability, recap participant and question counts, recap outcome, and participant or winning-team display names that the host approved for disclosure.	Feature-triggered when a host tests and configures a Teams Workflow destination or explicitly posts a Run card. Delivered cards are recipient-controlled, so account deletion cannot recall them; participant erasure records an owner follow-up when existing permissions cannot remove an affected recap card.

Optional AI and enrichment features

These processors receive data only when a host or public visitor uses the relevant AI or enrichment feature.

Optional AI and enrichment features processor disclosure
Processor	Purpose	Data categories	Use
OpenAI	Plans event structures from host briefs, generates draft quiz questions from host prompts or source material, drafts answer options for existing questions, drafts non-question segment slide content plus host-private MC notes, reviews authored event packages for workplace content risks, and answers public visitor questions from the product manual.	Quiz topic or host prompt, audience context, generation settings, requested question count and type mix, question text, question type, existing answer options, event goal, timebox, optional preset preference, source-material availability, segment kind/title/purpose/duration, audience size/type/notes, tone, company facts, generated draft quiz or segment content, authored event-package item titles and body text, host-private MC notes, optional uploaded source PDF bytes, host-selected imported PowerPoint slide text, speaker notes, order, section labels, fallback state, and import warning codes, plus public visitor questions, generated manual answers, and cited manual concept keys. Imported PowerPoint image bytes, storage identifiers, credentials, omitted audio/video, transitions, and animations are not sent by this feature.	Feature-triggered when AI event planning, quiz generation, answer-option generation, segment-content generation, event-package review, or a public visitor manual question is used.
Context.dev	Extracts brand colors and logo candidates from a submitted company website for theme generation.	Domain extracted from the submitted public HTTPS company website, plus resulting brand metadata such as colors, page title, and logo candidate URLs. Usable logo candidates may be fetched by Discera and rehosted in Convex storage for the draft theme.	Feature-triggered when website-based brand theme generation is used.
Nominatim / OpenStreetMap	Searches for places in map-pin question authoring.	Place search text sent through Discera's map geocode route, plus normal request metadata for the upstream search.	Feature-triggered when map place search is used.
OpenStreetMap and CARTO tile providers	Serve map tiles for map-pin question editing and gameplay.	Tile request metadata and map tile coordinates needed to render the map.	Feature-triggered when a map view is rendered.
YouTube	Serves slide video embeds from supported YouTube nocookie embed URLs.	Browser iframe/video request metadata and the authored YouTube embed URL when the slide is rendered.	Feature-triggered when a slide with a YouTube embed is rendered.
Vimeo	Serves slide video embeds from supported Vimeo player URLs.	Browser iframe/video request metadata and the authored Vimeo embed URL when the slide is rendered.	Feature-triggered when a slide with a Vimeo embed is rendered.

What each AI feature sends

OpenAI: AI quiz generation: Discera sends the host prompt or topic, audience context, requested count, difficulty, allowed question types, question-type mix, optional company facts, and one optional source: source PDF bytes, host-supplied source text (pasted text, meeting notes, or extracted public web page content), or the approved imported PowerPoint representation, so OpenAI can return draft quiz questions. The selected source is the primary factual source. The PowerPoint representation includes selected slide text, speaker notes, order, section labels, fallback state, and warning codes, but excludes image bytes, storage identifiers, credentials, and omitted media or animation content.; Only when a host asks Discera to generate quiz content.
OpenAI: AI answer-option generation: Discera sends the question text, question type, requested option count, and existing answer options so OpenAI can draft answer choices for that question.; Only when a host asks Discera to draft answer options.
OpenAI: AI event structure planning: Discera sends the event goal, tone, timebox, audience type, audience size, optional audience notes, optional company facts, optional preset preference, and whether source material exists so OpenAI can propose a run-of-show structure. When the host selects an imported PowerPoint Activity, Discera also sends its approved imported slide text, speaker notes, order, section labels, fallback state, and warning codes; image bytes, storage identifiers, credentials, and omitted media or animation content are excluded. Source PDFs and pasted source text are not sent in this planning request.; Only when a host asks Discera to plan the event.
OpenAI: AI segment content generation: Discera sends the event goal, tone, audience type, audience size, optional audience notes, planned segment kind, title, purpose, target duration, and optional company facts so OpenAI can draft one non-question segment slide plus host-private MC notes. When the host selects an imported PowerPoint Activity, Discera also sends its approved imported slide text, speaker notes, order, section labels, fallback state, and warning codes; image bytes, storage identifiers, credentials, and omitted media or animation content are excluded. Source PDFs and pasted source text are not sent for this request.; Only when a host asks Discera to draft non-question segment content.
OpenAI: AI event package review: Discera sends the event goal, tone, audience type, audience size, optional audience notes, optional company facts, and authored item kinds, titles, body text, question metadata, fact references, and host-private MC notes so OpenAI can identify tone or wording risks, risky free-text prompts, difficulty mismatches, and unsupported company claims. Discera does not automatically attach session IDs, source PDFs, player records, or cross-event records to this request. Text entered into the reviewed package is sent as authored, so hosts should omit sensitive or unrelated data.; Only when a host asks Discera to review an authored event package.
OpenAI: Public manual answers: Discera sends the visitor's free-text question and the code-owned product manual corpus so OpenAI can return a grounded answer. The question and generated answer are stored in Convex with cited manual concept keys for up to 90 days; visitors should not include personal or confidential information.; Only when a public visitor submits a question in the FAQ ask box.
Context.dev: Website-based brand theme extraction: Discera sends the domain extracted from the submitted public HTTPS company website so Context.dev can return brand colors, title metadata, and logo candidate URLs. When Discera uses a returned logo candidate, Discera fetches and rehosts that logo in Convex storage for the draft theme; no theme record is created until the host saves it.; Only when a host asks Discera to generate a theme from a website.

Running a pilot without AI processors

A pilot that cannot approve AI processors can run Discera without them. The deployment carries a switch that blocks AI-backed calls outright and omits the related authoring controls from the product.
The switch is authoritative even when provider credentials are still configured, so the answer to "can this pilot reach OpenAI?" does not depend on remembering to remove a key.
Manual question and slide authoring, spreadsheet import, saved templates, manual theme editing, rehearsal, hosting, participation, presentation, and results all remain available without AI processing.
This is a deployment-level pilot control rather than a per-customer policy setting.

Vulnerability reporting and dependency management

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Report suspected vulnerabilities privately to mab@consensus.dk. Mikkel Abildtoft monitors this address, and a reporter does not need repository access or a pilot agreement.
A report should describe the issue and its impact, how to reproduce it, the affected area, and any suggested remediation.
Discera is maintained on a best-effort basis. The team aims to acknowledge a report within a few business days and coordinates the fix and disclosure timeline privately with the reporter.
If you already have repository access, you may instead use the repository's private security advisory flow. Do not open a public issue or pull request for a vulnerability.
Dependency advisories are handled by an automated gate that runs on every change and again on a daily schedule, and that fails the build on high or critical advisories across every workspace and transitive dependency.
An automated updater opens remediation pull requests and preserves exact version pins.
An advisory is suppressed only through a dated allowlist entry carrying the advisory link, the justification, and a recheck date. Audit severity is never lowered to clear a failing gate.

Incident handling and support contacts

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

These statements distinguish what is in place today from verified production operation. The pilot support target, vulnerability route, and incident handling boundary are stated separately; where production operation has not been verified, this section says so rather than implying it.

The documented setup calls for Convex backend exceptions to reach the same PostHog project as app diagnostics. Production backend forwarding has not yet been verified.
The documented alerting model covers new and reopened issues, spikes on existing issues, and exception-volume trends on live-Run routes. Production configuration and notification delivery have not yet been verified.
The documented P0–P3 severity model is keyed to whether a live event is affected. It reserves the highest severity for repeated failures on live-event routes during an active customer session, or any backend failure that blocks host control, answer submission, round progression, or presentation playback.
The documented response priority is to stabilize the running event first and diagnose afterwards, and to record incident evidence before the alert is closed. This describes the intended response model; it does not confirm production execution or staffed coverage.
Host control tokens, recovery secrets, transfer links, and participant names are never pasted into incident records. Route templates, request identifiers, release versions, and sanitized stack traces are what incident handling uses.

Contacts

Security vulnerabilities go to mab@consensus.dk. Privacy, data-subject, and identity-deletion requests go to privacy@consensus.dk. Product and event questions go through pilot support guidance.

Pilot support commitment

For pilot support requests sent to mab@consensus.dk, we aim to acknowledge your request within two business days, during European business hours, Monday to Friday. This is a best-effort target, not a guaranteed response or resolution time.

For a scheduled pilot event, agree the named contact and a direct escalation channel before the event date. Discera does not provide automatic staffed event coverage.

No 24/7 coverage, on-call rotation, or paging service.
No public status page and no published uptime target.
No formal service-level commitment, support tiers, or service credits.
Escalation outside a pre-arranged event window is best-effort and may not be answered while the event is running.
Response targets are goals rather than contractual guarantees, and they exclude weekends and Danish public holidays.

See Pilot support guidance for the operational details used by event crews.

What Discera does not offer today

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

A pilot decision is easier when the gaps are stated plainly. Each row below is a capability Discera does not have, written so it can be copied straight into a review checklist.

Security certification: Consensus's existing SOC 2 report does not cover Discera and must not be treated as assurance over Discera. This packet is a description of implemented controls, not an audit report or penetration test report, and Discera is not ISO 27001 certified.
Data processing agreement: Discera does not offer a signed DPA or a legal security appendix today. The public privacy page and this packet are the current disclosures.
Enterprise identity: Discera does not support SAML federation or SCIM directory provisioning. Host sign-in is Auth0-backed, and there is no enterprise directory integration.
Service levels: Discera does not publish an SLA, an uptime commitment, or a guaranteed support response window.
Retention controls: Finished and cancelled Run retention resolves an approved 1, 7, 30, 90, or 365-day Event override, then its workspace and organization defaults, then a 30-day system fallback. Discera does not offer an enterprise-wide retention administration UI in Trust Lite.
Administration and reporting: There is no organization or workspace administration console, no cross-event admin reporting, and no tenant-wide audit export. Auditing is per game, through moderation records and the finished-game export.
Accessibility conformance: Discera does not claim WCAG conformance or publish a VPAT. The public accessibility page separates tested evidence from unverified conformance.
Processor commitments: Discera does not promise data residency, and does not claim vendor no-training or no-retention terms beyond each processor's public terms.

Public materials referenced by this packet

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Trust Lite

Security review packet

How to read this packet

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

This packet describes Trust Lite: the posture Discera supports for corporate pilots. It is not an enterprise compliance package and does not stand in for a certification report, an audit, or a legal security appendix.
This packet distinguishes implemented controls, documented setup guidance, and verified production operation. Where a control does not exist or production operation has not been verified, this packet says so rather than presenting an intention as an operating fact.
The public privacy page remains the policy source of truth. This packet explains the implementation boundaries a security reviewer needs in order to assess a pilot.

Architecture

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Discera architecture components and their boundaries
Component	Role	Data handled	Boundary
Discera web app	Serves the public pages, host authoring, player, presentation, and moderation surfaces, and runs the same-origin server routes that carry privileged host operations.	Request metadata such as IP address, user agent, route, headers, and timing. Holds sealed host credentials server-side for privileged calls.	Hosted on Vercel. Privileged host operations are the ones routed through this origin, and the raw host control secret is never returned to the browser by those flows.
Discera backend and database	Stores and serves live game state, host accounts, uploaded assets, and moderation records, and runs the scheduled jobs that delete expired data.	Game content, player nicknames, answers, audience posts, moderation decisions, uploaded media, host account records, and hashed host credentials.	Hosted on Convex. Host control, recovery secret, and paper recovery code values are stored only as hashes, so the stored form cannot be replayed as a credential.
Host sign-in	Authenticates host accounts. Players never authenticate and never create an account.	Host email, name when available, authentication identifiers, and login session metadata.	Auth0 is the only configured account provider. Deleting a Discera account does not delete the Auth0-side identity; that removal is handled by an operator on request.
Diagnostics and analytics	Receives operational error diagnostics for the documented live-event support and alerting model, plus consent-gated product analytics and session replay.	Errors, canonical route templates, request context, pseudonymous identifiers, and consented product events and replay.	PostHog plus retained first-party Convex commercial attribution. Diagnostics are always on when configured; product analytics and session replay run only after a visitor accepts analytics, and the retained commercial attribution was likewise created only after that consent. Raw game codes, internal game identifiers, and gameplay session identifiers are excluded or redacted from PostHog; direct commercial Event/Workspace/Run/Activity provenance stays first-party and excludes participant identity and content.
AI authoring	Drafts quiz questions, answer options, and non-question segment content when a host explicitly asks for it.	The host prompt and authoring context for the requested feature, plus optional uploaded source PDF content.	OpenAI. Optional. A pilot deployment can be configured so no AI-backed call is made at all and the related controls are omitted from the product.
Brand theme extraction	Returns brand colors, title metadata, and logo candidates for a submitted company website.	The domain extracted from the submitted public company website, and the returned brand metadata.	Context.dev. Optional, and covered by the same no-AI pilot switch as AI authoring.
Maps and embedded media	Serves place search and map tiles for map-pin questions, and video embeds for slides that use them.	Place search text, map tile requests, and browser requests for the authored embed URL.	Nominatim/OpenStreetMap, CARTO, YouTube, and Vimeo. Triggered only when a map or an embedded video is actually rendered.

Trust boundaries

A host browser never receives the raw secret that authorizes writes to a live game. Privileged host operations go through same-origin server routes, which hold the secret in a sealed cookie that page scripts cannot read, that browsers do not attach to cross-site form posts or embedded requests, and that is unsealed only on the server.
Browsers also hold a direct realtime connection to the backend for live game data, which is what makes the event update instantly on every screen. Privileged host operations are the ones that deliberately do not use it, and go through the app server instead.
The backend stores the host control token, the host recovery secret, and the paper recovery code only as hashes. A database copy is therefore not usable as a credential.
Being signed in as the account owner is not the same as holding live write control. An owner can read their own host console, but host writes additionally require an active host control credential.
Player browsers hold no account and no host credential. Their reads are scoped to the game they joined, and pending or rejected audience content is excluded from those reads entirely rather than hidden in the client.
Moderator browsers hold a separate game-scoped credential that reaches moderation and Q&A surfaces only. It grants no host lifecycle, template, export, or editor access.

Identity, sessions, and the token boundary

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Discera separates three things that are often collapsed into one: who you are, which browser you are on, and whether you may currently write to a running event.

A host signs in through Auth0. The backend trusts the resulting identity and maps it to a Discera account record, which anchors saved templates, custom themes, account export, and account deletion.
Every browser also carries a per-browser session identity. For players this is the whole of their identity: there is no account, no password, and no profile that follows them between events.
Live host control is a separate, game-scoped credential issued when the game is created. It is what actually authorizes host writes, and it can be rotated without touching the account.
Because the two are separate, losing a browser does not lose the game, and having an account does not silently grant control of someone else's event.

Host control, recovery, and moderator delegation

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

A live event cannot afford to be locked out, and it cannot afford to hand a helper the keys to everything. These are the paths that exist.

Recovering host control

Transfer link: a host opens a link carrying the recovery secret, which rotates a fresh host credential into that browser.
Signed-in owner: the owner of an account-backed game recovers control without any secret, because the backend can verify the account against the game.
Paper recovery code: a single-use code issued at game creation covers the lost-device case. It is burned on use, writes an audit record, and rotates fresh credentials.
Every recovery path rotates the credential and advances a version counter, so previously issued host credentials stop working.

Delegating to a moderator

Moderator access is granted per game through an invite, not by sharing host credentials.
An invite binds to the first browser that claims it; a second browser is rejected. Unclaimed invites expire 24 hours after they are created, which is enough for day-before event preparation without leaving a standing door open.
A claimed moderator session stays valid until it is revoked. A game supports up to 16 active moderator sessions.
Moderators provide a self-chosen display label when they claim an invite, and that label is copied onto every moderation record they produce, so the audit trail still attributes the action after the session is revoked or relabeled.
A host can revoke one leaked invite individually or revoke every active session at once.

Data flows

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Each flow below states what leaves the browser, where it is processed, who can read it, and how long it stays.

Player join

Trigger: A participant enters a game code or opens a join link. No account is created and no sign-in is required.
What moves: The browser sends the chosen nickname, avatar selection, and a per-browser session identity to the backend. Display names are checked against the blocked-name rules before the participant is admitted.
Who can read it: The host, any moderators for that game, and other participants where the live experience shows player names.
Retention: Stored with the game and removed by the finished-game cleanup described in the retention section.

Live gameplay

Trigger: The host runs the event and participants answer from their own devices.
What moves: Answers, scores, and round state move between participant, host, and presentation surfaces over the live backend connection. Running the event reaches only the app and its backend; the AI and enrichment processors are not involved in gameplay.
Who can read it: Scoped to the game. Host and presentation surfaces see what the format exposes; participants see their own submission plus whatever the format publishes to the room.
Retention: Stored with the game and removed by finished-game cleanup.

Moderation

Trigger: A participant submits free text on a surface where review is enabled, or an automated term check holds a submission.
What moves: The submission is stored as pending and enters the review queue instead of being displayed. An optional automated term check can hold content for review; it records that it acted without writing the matched term into the audit record.
Who can read it: Pending and rejected content is excluded from participant and presentation reads. Host and moderator review surfaces keep it visible so a decision can be made or reversed.
Retention: Every decision writes a moderation record that is included in the finished-game host export, and is removed with the game.

Account export and deletion

Trigger: A signed-in host requests an export or a deletion.
What moves: Export returns a machine-readable file covering account profile fields, saved templates, custom themes, upload references, and retained game metadata. Deletion removes the account record, its sign-in rows and sessions, saved templates, custom themes, entitlements, and uploads that nothing else references.
Who can read it: The signed-in account holder.
Retention: Games the host created are detached from the deleted account and then follow normal game retention. Removal of the Auth0-side identity is handled by an operator on request. For signed-in hosts who accepted analytics, deleting the local Discera account does not automatically remove the PostHog person profile or consented product-event history linked to the account. Any consented session replays are retained separately and are not removed by local account deletion. PostHog analytics and session replays are typically retained for up to 12 months. Email privacy@consensus.dk to request operator-handled removal of the PostHog person profile, associated events, and session replays.

Diagnostics and analytics

Trigger: Diagnostics run whenever the app loads and diagnostics are configured. Product analytics and session replay run only after a visitor accepts analytics.
What moves: Diagnostics send errors, canonical route templates, and request context. Game routes are reduced to templates, and raw game codes, internal game identifiers, and gameplay session identifiers are excluded or redacted from PostHog. Historical commercial-prompt attribution keeps direct Event/Workspace/Run/Activity provenance only in first-party Convex storage, without participant identity or content.
Who can read it: The Discera engineering team, through the diagnostics provider. Diagnostics are used to keep live events working, not for advertising.
Retention: Diagnostics are typically kept for up to 90 days; consented analytics and session replay for up to 12 months.

AI authoring

Trigger: A host explicitly asks Discera to generate quiz content, answer options, or non-question segment content, or to build a theme from a company website.
What moves: Only the material needed for that request is sent to the relevant processor. The subprocessor section below lists exactly what each feature sends.
Who can read it: The requesting host and the relevant processor.
Retention: Generated drafts follow the game or template the host saves them into. Processor-side retention follows that processor's terms.

Retention matrix

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

This is the same inventory published on the privacy page, reproduced here so the packet is self-contained.

Discera retention and data inventory
Area	Data included	Scope	Retention and cleanup	Notes
Browser storage and cookies	Analytics consent, PostHog browser/session identifiers, host credentials, host-transfer and recovery flags, create drafts, preview data, join preferences, and sound or pacing preferences.	User/browser-scoped localStorage, sessionStorage, cookies, or history.state. These are not server account records.	sessionStorage and history.state entries last for the tab or browser session. localStorage lasts until the user clears it. The analytics consent cookie expires after 1 year.	Account deletion does not reach data stored only in the user's browser; users can clear site data locally at any time.
Run and participant data	Run metadata, immutable Activity snapshot, content items, rounds, round timing, players, nicknames, host-configured join details such as department or table, answers, scores, Q&A, message wall posts, brainstorm ideas and votes, moderation events, control-room state/events, operator sessions, display-name overrides, and blocked join attempts.	Server-retained Convex data scoped to the Run.	Retained while the Run is active. When the Run finishes or is cancelled, Discera sets an expiry from an approved 1, 7, 30, 90, or 365-day attached Event override, then the workspace and organization defaults, then the 30-day system fallback. Lower-level values must remain inside organization constraints. Expired Runs become unavailable, and daily cleanup removes the Run row plus cleanup-covered live-Run records such as rounds, players, answers, Q&A, message-wall, brainstorm, moderation, control-room, operator, display-name, blocked-join, score, and storage-reference rows.	Hosts and players can see Run data where the live experience requires it. Feature-specific audit and operational records follow their owning cleanup paths.
Audience rosters and participant data-rights records	Host-entered participant display names and email addresses, historical links to Run players, verified export/erasure workflow state, hosted-recap redaction evidence, external Teams follow-up outcomes, legal holds, and privacy-safe audit receipts.	Workspace-scoped Convex data. Roster PII is available only to authorized signed-in editors/controllers and a current host for the matching Audience-bound Run; it is never shown to participants or included in sharing, copy, move, presentation, or analytics payloads.	Roster entries remain until archived or erased by a verified participant request. Link snapshots remain for Run history until Run cleanup or participant erasure strips their identifying fields. Pending requests temporarily retain the normalized address and verification evidence. If erasure processing fails but can recover, Discera retains the normalized address and minimal phase/cursor identifiers needed for automatic retry while scrubbing verification evidence immediately. Completion or exhausted recovery removes that transient context and retains only a hashed idempotency key, request kind/status, timestamps, affected count, hosted-recap counts, external-copy outcomes, and non-identifying audit receipts. Active legal holds suspend erasure and release resumes it.	Workspace owners/admins or organization owners/admins handle verified access, portable JSON/CSV export, erasure, and holds. Erasure removes covered active identifiers, metadata, responses, uploads, standings, embedded references, and identity-linked names in hosted recap links. The retained receipt and any aggregates do not identify the participant. Recipient-controlled Teams cards use a receipted owner follow-up when existing permissions cannot remove them; processor backups follow separately disclosed windows.
Portable workspace exports	Revision-pinned ZIP packages with JSON, CSV tables, integrity checksums, explicit omissions, and durable controller-visible job receipts.	Discera-held package storage and download handles remain under Discera control. Once downloaded, a controller-held copy is outside Discera control.	Discera normally retains a generated package for up to seven days. Participant erasure invalidates every earlier queued, running, complete, or incomplete export that could contain the participant before completion, deletes any Discera-held package, and revokes its download handle. The non-content job receipt remains. A later export is generated from post-erasure canonical state.	Controllers must store downloaded copies securely and retain or delete them under their own policy. Participant erasure cannot recall a file already saved outside Discera.
Uploaded Activity and Run assets	Question media, slide media, audio, canvas images, player avatars, answer thumbnails, generated assets, and source files registered to an Activity, Run, or content item.	Convex storage objects plus storage-reference rows owned by the Activity, Run, content item, round, or related runtime record.	Follows the owning Run through its resolved retention window, then is removed by expired-Run cleanup when no other owner references the storage object.	Shared or reused storage is deleted only after Discera confirms no saved owner still references it.
Draft or abandoned uploads	Source PDFs, generated theme logos, images, audio, and canvas media uploaded while drafting but not saved into an Activity, template, theme, or account-owned asset.	Short-lived upload-capability rows containing the session scope, purpose, token hash, lifecycle status, and timestamps; Convex uploaded-file rows; storage objects; and bounded cleanup diagnostics. Capability rows retain a token hash rather than the client-held token.	Upload capabilities expire after ten minutes. A bound capability can be extended in five-minute increments while deletion and durable cleanup-job persistence both fail. Unadopted draft uploads are retained for at least 24 hours; after that, daily cleanup removes them when no saved owner references the storage object.	If a draft upload is saved or adopted, it follows the saved owner and validated ownership removes matching cleanup diagnostics. Failed best-effort deletes can be retried by cleanup jobs. Terminal cleanup diagnostics omit caller-linked context and are removed at an eligible reconciliation sweep after the object is deleted or confirmed absent, gains a durable owner reference, or is superseded by newer uploaded-file ownership metadata.
Host account data and saved assets	User profile fields, local Convex auth rows/sessions, entitlements, saved Activities and templates, custom themes, theme/template upload references, account-linked upload metadata, pending workspace invitations addressed to the verified account email, invitation creator references, and commercial-prompt cooldown state. Account export includes its documented account-owned records and retained Run metadata, but excludes commercial-prompt cooldown and attribution rows.	Convex account tables and account-owned storage references.	Retained until the host deletes the account or asks Discera to remove it. Local deletion removes the account row, linked auth/session rows, saved templates, custom themes, entitlements, commercial-prompt cooldown and attribution rows, unreferenced account uploads, and pending invitations addressed to the normalized verified identity email. Invitation audit email and ID fields are redacted first. Invitations created by the account remain usable with their creator reference removed.	Runs created by the host are detached from the deleted account and stay only until their normal Run-retention expiry. A content-free deletion receipt remains unfinished until the bounded invitation cleanup completes; it never stores the email address.
PowerPoint deck connections	SHA-256 fingerprints derived locally from compressed deck bytes, opaque deck-link IDs, workspace relationships, retry request IDs, revision state, and lifecycle audit events. Deck bytes, slide content, titles, and filenames are not uploaded. Static slides written locally into a presentation can include source titles, the source Theme’s colors and uploaded logo, an active join code/link, winner display names, or participation totals, plus hidden provenance tags holding opaque source and generation-event IDs, the source and asset kinds, a source revision, a generation timestamp, and the Discera asset version.	Convex link/audit tables, PowerPoint settings, and saved copies.	Personal-workspace links and events are removed through bounded background cleanup after account deletion. Team-workspace links and audit evidence remain with the team; deleted creator and actor identifiers are anonymized. Discera retention and account deletion cannot remove static slides from presentations or copies saved and shared by the host.	Access-denial evidence, including denied static-slide generation, is retained as internal workspace security evidence and is not included in the probing account’s self-service export.
Workspace offboarding	Workspace-owned Activities, templates, Runs and participant/runtime rows, memberships, invitations, share links, edit leases, exports, PowerPoint links, and workspace audit detail.	The selected personal or team workspace in the regional Discera application database and storage. Independently copied assets in another workspace are destination-owned and survive.	A confirmed deletion makes the workspace unavailable immediately, cancels planned Runs, and targets verified product-visible cleanup within 24 hours. A minimal no-content receipt is retained for one year. There is no grace period or recovery window.	Open/live Runs and active supported legal holds block confirmation. Export is offered but failure or non-download does not delay deletion. Product completion and processor-backup deletion are separate states; backup verification follows provider operations and evidence.
Auth0 identity	Provider-side identity, Auth0 login/session metadata, and upstream identity-provider session data where applicable.	Auth0 and any upstream identity provider systems.	Manual deletion boundary: deleting the local Discera account does not automatically delete the Auth0-side identity. Email privacy@consensus.dk for operator-handled Auth0 identity deletion.	Retention follows Auth0 and upstream identity-provider configuration and processor terms.
Diagnostics and analytics	Essential error and canonical route diagnostics, memory-only pseudonymous diagnostics identifiers, request identifiers, optional PostHog product events without internal Run or gameplay-session identifiers, bounded sanitized failure details, consented session replay, signed-in account attribution, historical first-party commercial-prompt attribution with account and Event/Workspace/Run/Activity/version provenance, and public FAQ questions, generated manual answers, and cited manual concept keys. Historical commercial attribution contains aggregate content counts and feature-use flags, never participant identity or participant content.	App telemetry, Convex attribution, and configured PostHog.	Essential diagnostics are typically retained for up to 90 days. Consent-gated PostHog analytics and session replay are typically retained for up to 12 months. First-party commercial attribution is deleted with its retained Run or local host account, whichever occurs first. Public FAQ question records are eligible for deletion 90 days after they are asked and are removed by the next successful daily cleanup; OpenAI, Vercel, and other provider or log retention follows their separate terms.	Essential diagnostics are used to keep live Runs reliable. Optional analytics and session replay run only after analytics consent. For signed-in hosts who accepted analytics, deleting the local Discera account does not automatically remove the PostHog person profile or consented product-event history linked to the account. Any consented session replays are retained separately and are not removed by local account deletion. PostHog analytics and session replays are typically retained for up to 12 months. Email privacy@consensus.dk to request operator-handled removal of the PostHog person profile, associated events, and session replays. Public FAQ question records have no structured account or workspace reference, but free text can identify the visitor. Retained first-party commercial attribution was likewise created only after analytics consent; no new attribution is written. Direct Run provenance stays first-party and is not sent in typed PostHog events.
Security and abuse-control records	Pseudonymous AI authoring caller keys, rate-limit counters, violation history, and temporary lockout state.	Server-retained Convex rate-limit data.	Rows become eligible for cleanup after one hour without an update. Cleanup runs daily, so a row can remain for up to about 25 hours after its last update.	The AI caller key is derived from the client address and changes at each UTC day boundary; Convex does not receive or store the raw address.
External processors	Vercel, Convex, Auth0, PostHog, Stripe, Microsoft Teams Workflow, OpenAI, Context.dev, Nominatim/OpenStreetMap, CARTO, YouTube, and Vimeo.	Third-party processor systems used for infrastructure, authentication, diagnostics/analytics, commerce, host-configured workflow delivery, AI/enrichment, maps, and embedded media.	Retention follows each processor's terms, configuration, and feature-specific setup. The Stripe-side customer record and retained commerce evidence survive local account deletion under the commerce retention lifecycle. Cards already delivered to Microsoft Teams are recipient-controlled; when existing permissions cannot remove an affected recap card, Discera records an owner follow-up requirement.	Discera does not promise data residency, vendor no-retention, DPA coverage, SOC 2, ISO, or similar enterprise commitments unless those terms are separately documented.

Subprocessors and AI data use

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

These are the processors that current production-relevant flows can reach, what each is used for, and whether the use is always on, feature-triggered, or consent-gated.

Required infrastructure and account services

These processors support hosting, storage, authentication, and live Run operation.

Required infrastructure and account services processor disclosure
Processor	Purpose	Data categories	Use
Vercel	Hosts the Next.js app, serves public pages and app routes, and runs server-side route handlers.	HTTP request metadata such as IP address, user agent, route, headers, and request timing for app traffic.	Always-on infrastructure when the app is used.
Cloudflare Turnstile	Protects the public playable-demo launcher from automated Run creation.	Browser and request signals needed to distinguish legitimate visitors from automated traffic, including IP address, user agent, challenge outcome, request hostname, and timing metadata. Demo form content is not sent to Turnstile.	Feature-triggered when the public /demo launcher is opened and a visitor starts a demo.
Convex	Stores and processes Activity definitions, live Run state, uploaded assets, account-linked host data, sessions, and backend function activity.	Host account identifiers, Activity content, Run state, player nicknames, answers, uploaded media or source PDFs, custom themes, browser session IDs, hashed host credentials, pseudonymous AI abuse-control rate-limit keys, and PowerPoint deck fingerprints, opaque link identifiers, workspace relationships, and lifecycle audit events.	Always-on infrastructure for Activity, Run, and account features.
Auth0	Provides sign-in for host accounts through Convex Auth.	Signed-in host identity data such as email, name when available, authentication identifiers, and login/session metadata.	Feature-triggered when a host signs in or signs out.

Diagnostics and analytics

Diagnostics help keep live Runs reliable. Product analytics and session replay are separate and require analytics consent.

Diagnostics and analytics processor disclosure
Processor	Purpose	Data categories	Use
PostHog	Receives operational diagnostics, optional analytics events, and optional session replay.	Errors, canonical route templates, memory-only pseudonymous PostHog and browser-session identities, request context, optional usage events without internal Run IDs, raw join codes, or gameplay session IDs, bounded sanitized failure details, persisted analytics identifiers, session replay data when consented, and signed-in account attribution when analytics are accepted.	Always-on diagnostics when configured; analytics and session replay are consent-gated.

Optional commerce and workflow integrations

These processors receive data only when a host uses paid commerce, its resulting billing lifecycle is processed, or a host tests, configures, and sends to a workflow destination.

Optional commerce and workflow integrations processor disclosure
Processor	Purpose	Data categories	Use
Stripe	Processes Host Pro subscriptions and Event Pass purchases, including hosted checkout when available, billing management, payment lifecycle, refunds, disputes, and reconciliation.	Host billing identity such as account email and name, payment and billing information entered directly into Stripe-hosted Checkout, Stripe customer references, subscription and purchase state, checkout attempts, invoice and payment status, product and price references, and Discera reconciliation metadata. Raw payment credentials entered in Stripe-hosted Checkout are not received or stored by Discera.	Feature-triggered when a host starts or manages Host Pro or purchases an Event Pass, when those purchases are available. New checkout is currently suspended; existing checkout, purchase, subscription, cancellation, refund, reconciliation, and billing-portal records continue through their normal lifecycle. Deleting the Discera account detaches local identity and schedules a current subscription to cancel at the end of the paid period; the Stripe-side customer record and retained commerce evidence remain under the commerce retention lifecycle.
Microsoft (Teams Workflow)	Posts a connection-test card to a host-submitted Microsoft Teams Workflow destination, then posts host-approved join, start, and recap cards after the destination is configured.	Connection-test message, Run title, join code, scheduled timing, join and recap action URLs including the public recap access capability, recap participant and question counts, recap outcome, and participant or winning-team display names that the host approved for disclosure.	Feature-triggered when a host tests and configures a Teams Workflow destination or explicitly posts a Run card. Delivered cards are recipient-controlled, so account deletion cannot recall them; participant erasure records an owner follow-up when existing permissions cannot remove an affected recap card.

Optional AI and enrichment features

These processors receive data only when a host or public visitor uses the relevant AI or enrichment feature.

Optional AI and enrichment features processor disclosure
Processor	Purpose	Data categories	Use
OpenAI	Plans event structures from host briefs, generates draft quiz questions from host prompts or source material, drafts answer options for existing questions, drafts non-question segment slide content plus host-private MC notes, reviews authored event packages for workplace content risks, and answers public visitor questions from the product manual.	Quiz topic or host prompt, audience context, generation settings, requested question count and type mix, question text, question type, existing answer options, event goal, timebox, optional preset preference, source-material availability, segment kind/title/purpose/duration, audience size/type/notes, tone, company facts, generated draft quiz or segment content, authored event-package item titles and body text, host-private MC notes, optional uploaded source PDF bytes, host-selected imported PowerPoint slide text, speaker notes, order, section labels, fallback state, and import warning codes, plus public visitor questions, generated manual answers, and cited manual concept keys. Imported PowerPoint image bytes, storage identifiers, credentials, omitted audio/video, transitions, and animations are not sent by this feature.	Feature-triggered when AI event planning, quiz generation, answer-option generation, segment-content generation, event-package review, or a public visitor manual question is used.
Context.dev	Extracts brand colors and logo candidates from a submitted company website for theme generation.	Domain extracted from the submitted public HTTPS company website, plus resulting brand metadata such as colors, page title, and logo candidate URLs. Usable logo candidates may be fetched by Discera and rehosted in Convex storage for the draft theme.	Feature-triggered when website-based brand theme generation is used.
Nominatim / OpenStreetMap	Searches for places in map-pin question authoring.	Place search text sent through Discera's map geocode route, plus normal request metadata for the upstream search.	Feature-triggered when map place search is used.
OpenStreetMap and CARTO tile providers	Serve map tiles for map-pin question editing and gameplay.	Tile request metadata and map tile coordinates needed to render the map.	Feature-triggered when a map view is rendered.
YouTube	Serves slide video embeds from supported YouTube nocookie embed URLs.	Browser iframe/video request metadata and the authored YouTube embed URL when the slide is rendered.	Feature-triggered when a slide with a YouTube embed is rendered.
Vimeo	Serves slide video embeds from supported Vimeo player URLs.	Browser iframe/video request metadata and the authored Vimeo embed URL when the slide is rendered.	Feature-triggered when a slide with a Vimeo embed is rendered.

What each AI feature sends

OpenAI: AI quiz generation: Discera sends the host prompt or topic, audience context, requested count, difficulty, allowed question types, question-type mix, optional company facts, and one optional source: source PDF bytes, host-supplied source text (pasted text, meeting notes, or extracted public web page content), or the approved imported PowerPoint representation, so OpenAI can return draft quiz questions. The selected source is the primary factual source. The PowerPoint representation includes selected slide text, speaker notes, order, section labels, fallback state, and warning codes, but excludes image bytes, storage identifiers, credentials, and omitted media or animation content.; Only when a host asks Discera to generate quiz content.
OpenAI: AI answer-option generation: Discera sends the question text, question type, requested option count, and existing answer options so OpenAI can draft answer choices for that question.; Only when a host asks Discera to draft answer options.
OpenAI: AI event structure planning: Discera sends the event goal, tone, timebox, audience type, audience size, optional audience notes, optional company facts, optional preset preference, and whether source material exists so OpenAI can propose a run-of-show structure. When the host selects an imported PowerPoint Activity, Discera also sends its approved imported slide text, speaker notes, order, section labels, fallback state, and warning codes; image bytes, storage identifiers, credentials, and omitted media or animation content are excluded. Source PDFs and pasted source text are not sent in this planning request.; Only when a host asks Discera to plan the event.
OpenAI: AI segment content generation: Discera sends the event goal, tone, audience type, audience size, optional audience notes, planned segment kind, title, purpose, target duration, and optional company facts so OpenAI can draft one non-question segment slide plus host-private MC notes. When the host selects an imported PowerPoint Activity, Discera also sends its approved imported slide text, speaker notes, order, section labels, fallback state, and warning codes; image bytes, storage identifiers, credentials, and omitted media or animation content are excluded. Source PDFs and pasted source text are not sent for this request.; Only when a host asks Discera to draft non-question segment content.
OpenAI: AI event package review: Discera sends the event goal, tone, audience type, audience size, optional audience notes, optional company facts, and authored item kinds, titles, body text, question metadata, fact references, and host-private MC notes so OpenAI can identify tone or wording risks, risky free-text prompts, difficulty mismatches, and unsupported company claims. Discera does not automatically attach session IDs, source PDFs, player records, or cross-event records to this request. Text entered into the reviewed package is sent as authored, so hosts should omit sensitive or unrelated data.; Only when a host asks Discera to review an authored event package.
OpenAI: Public manual answers: Discera sends the visitor's free-text question and the code-owned product manual corpus so OpenAI can return a grounded answer. The question and generated answer are stored in Convex with cited manual concept keys for up to 90 days; visitors should not include personal or confidential information.; Only when a public visitor submits a question in the FAQ ask box.
Context.dev: Website-based brand theme extraction: Discera sends the domain extracted from the submitted public HTTPS company website so Context.dev can return brand colors, title metadata, and logo candidate URLs. When Discera uses a returned logo candidate, Discera fetches and rehosts that logo in Convex storage for the draft theme; no theme record is created until the host saves it.; Only when a host asks Discera to generate a theme from a website.

Running a pilot without AI processors

A pilot that cannot approve AI processors can run Discera without them. The deployment carries a switch that blocks AI-backed calls outright and omits the related authoring controls from the product.
The switch is authoritative even when provider credentials are still configured, so the answer to "can this pilot reach OpenAI?" does not depend on remembering to remove a key.
Manual question and slide authoring, spreadsheet import, saved templates, manual theme editing, rehearsal, hosting, participation, presentation, and results all remain available without AI processing.
This is a deployment-level pilot control rather than a per-customer policy setting.

Vulnerability reporting and dependency management

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

Report suspected vulnerabilities privately to mab@consensus.dk. Mikkel Abildtoft monitors this address, and a reporter does not need repository access or a pilot agreement.
A report should describe the issue and its impact, how to reproduce it, the affected area, and any suggested remediation.
Discera is maintained on a best-effort basis. The team aims to acknowledge a report within a few business days and coordinates the fix and disclosure timeline privately with the reporter.
If you already have repository access, you may instead use the repository's private security advisory flow. Do not open a public issue or pull request for a vulnerability.
Dependency advisories are handled by an automated gate that runs on every change and again on a daily schedule, and that fails the build on high or critical advisories across every workspace and transitive dependency.
An automated updater opens remediation pull requests and preserves exact version pins.
An advisory is suppressed only through a dated allowlist entry carrying the advisory link, the justification, and a recheck date. Audit severity is never lowered to clear a failing gate.

Incident handling and support contacts

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

The documented setup calls for Convex backend exceptions to reach the same PostHog project as app diagnostics. Production backend forwarding has not yet been verified.
The documented alerting model covers new and reopened issues, spikes on existing issues, and exception-volume trends on live-Run routes. Production configuration and notification delivery have not yet been verified.
The documented P0–P3 severity model is keyed to whether a live event is affected. It reserves the highest severity for repeated failures on live-event routes during an active customer session, or any backend failure that blocks host control, answer submission, round progression, or presentation playback.
The documented response priority is to stabilize the running event first and diagnose afterwards, and to record incident evidence before the alert is closed. This describes the intended response model; it does not confirm production execution or staffed coverage.
Host control tokens, recovery secrets, transfer links, and participant names are never pasted into incident records. Route templates, request identifiers, release versions, and sanitized stack traces are what incident handling uses.

Contacts

Security vulnerabilities go to mab@consensus.dk. Privacy, data-subject, and identity-deletion requests go to privacy@consensus.dk. Product and event questions go through pilot support guidance.

Pilot support commitment

For a scheduled pilot event, agree the named contact and a direct escalation channel before the event date. Discera does not provide automatic staffed event coverage.

No 24/7 coverage, on-call rotation, or paging service.
No public status page and no published uptime target.
No formal service-level commitment, support tiers, or service credits.
Escalation outside a pre-arranged event window is best-effort and may not be answered while the event is running.
Response targets are goals rather than contractual guarantees, and they exclude weekends and Danish public holidays.

See Pilot support guidance for the operational details used by event crews.

What Discera does not offer today

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.

A pilot decision is easier when the gaps are stated plainly. Each row below is a capability Discera does not have, written so it can be copied straight into a review checklist.

Security certification: Consensus's existing SOC 2 report does not cover Discera and must not be treated as assurance over Discera. This packet is a description of implemented controls, not an audit report or penetration test report, and Discera is not ISO 27001 certified.
Data processing agreement: Discera does not offer a signed DPA or a legal security appendix today. The public privacy page and this packet are the current disclosures.
Enterprise identity: Discera does not support SAML federation or SCIM directory provisioning. Host sign-in is Auth0-backed, and there is no enterprise directory integration.
Service levels: Discera does not publish an SLA, an uptime commitment, or a guaranteed support response window.
Retention controls: Finished and cancelled Run retention resolves an approved 1, 7, 30, 90, or 365-day Event override, then its workspace and organization defaults, then a 30-day system fallback. Discera does not offer an enterprise-wide retention administration UI in Trust Lite.
Administration and reporting: There is no organization or workspace administration console, no cross-event admin reporting, and no tenant-wide audit export. Auditing is per game, through moderation records and the finished-game export.
Accessibility conformance: Discera does not claim WCAG conformance or publish a VPAT. The public accessibility page separates tested evidence from unverified conformance.
Processor commitments: Discera does not promise data residency, and does not claim vendor no-training or no-retention terms beyond each processor's public terms.

Public materials referenced by this packet

Review owner: Mikkel Abildtoft. Last reviewed: September 9, 2026.