The demo workspace

The Generate demo project button creates a complete, self-contained project so you can explore every part of tripl in minutes — without connecting a warehouse or sending anything anywhere. It is a real project that exercises the real product pipeline over a local synthetic warehouse.

This page is the source of truth for what in the demo is synthetic, what is really executed, and what is intentionally unavailable.

What is synthetic (local, never a real connection)

• The warehouse. The demo's data source is a first-class synthetic source: a bounded, deterministic, in-memory dataset (an events table and an orders table). It has no network or filesystem access and is never a real ClickHouse / PostgreSQL / BigQuery connection. It is clearly badged as local synthetic data throughout the UI and can never be selected by a real project or edited into real credentials. Its display name and timeout can be edited without changing the locked connection settings.
• The seed content. Events, fields, meta fields, properties, relations, an event‑type owner, a small branch/revision/comment journey, a Figma spec embed, and the metrics catalog are all generated by a versioned recipe and are reproducible for a fixed clock and seed.
• The history you land on. A brand-new project would otherwise be an empty shell, so the recipe also backfills the past it presents: earlier scan runs, volume and metric series, the signals on them, and one recorded local alert delivery. That history is written by the recipe rather than replayed from real runs; the scans and collections you start are real (next section). It also holds one planned event, Spring promo (planned), over the spike on the first catalog metric: that chart shades the window and draws the spike muted, and it raises no alert. And three weekly sends of a Weekly promo email lift Paywall View at the same hour, each marked expected, so the Annotations page suggests planning the next ones.

What is really executed (the same code paths as a real project)

None of the following is faked — it runs the normal services and workers over the synthetic source:

• Scans (Govern › Scans, route /p/<slug>/scans) — Preview, Run now, and Replay run the real scan pipeline against the synthetic events table and reconcile against the authored plan.

• Metric collection — SQL, event‑composition, fact‑single and fact‑ratio metrics are collected by the real collectors (including batched fact scans); unsupported SQL returns an honest capability error rather than a fabricated value.

• Anomaly detection & drift — anomalies are produced by the real detector and distribution drift by the real PSI computation over the stored series.

• Reconciliation & coverage — coverage reconciles with scanned volume, and shadow / dead‑event candidates are coherent with the data. The planted dead event, Subscription Cancelled, has no volume after it was last seen 45 days ago — not in the seeded history, not in the synthetic warehouse — so running a scan or collection does not bring it back to life.

• A continuous runtime clock — a bounded, idempotent background tick keeps an active demo fresh over time (new buckets, jobs and signals), with retention caps so it never grows without bound. The runtime adds ordinary traffic only, so the seeded Injected demo spike chart marker is removed together with the anomaly it explains once both age past the retention window. The synthetic warehouse serves that spike hour too, and the demo scores its newest hour with no ingestion-settling delay (the synthetic source delivers every hour complete), so the scheduled collection that re-reads the hour detects the same spike again rather than erasing it. A demo nobody has opened for six hours pauses, and resumes on your next visit; the scheduled scan collection — the event‑volume series and the breakdown and drift work that hangs off it — pauses with it, on the same rule, because collecting while the tick is stopped would rewrite the demo's own history with the sparse rows the synthetic warehouse keeps outside its newest hours. On resume, the scheduled collection waits for the tick to backfill the paused hours first (normally within a minute), for the same reason. tripl doctor --include-demo does not report a demo's idle collection as stale. The metrics catalog is dispatched by a second scheduler that has no such rule, so a paused demo does not stop collecting altogether: its three interval-carrying catalog metrics — Active Sessions, Revenue (completed) and Average order value, all daily — keep being collected on schedule. (Purchase conversion stops too, but only as a consequence, not by the pause rule: it re-derives from the event metrics the stopped tick is no longer appending, so it runs out of new buckets to compose.) An operator can turn this tick off with DEMO_RUNTIME_ENABLED=false; a demo then keeps the data it already has. With the tick off, nothing backfills paused hours, so the scheduled collection does not wait for a backfill: while the demo is in use it keeps running every six hours and appends the new buckets itself.

• The audit log — the actions you take in the demo (edits, collections, branch operations, alerting changes) go through the same audited service paths as a real project and show up in Govern → Audit log. The recipe writes the seeded plan directly rather than through those paths, so it also backfills a matching trail: one entry per authored event, event type, field, meta field, property, scan, alert destination and rule, attributed to whoever generated the demo and back‑dated so the log reads as a build‑up. Those entries are marked demo_seed in their payload. Connecting the warehouse is recorded too, but a data source belongs to the workspace rather than to one project, so — exactly like a real one — that entry carries no project and this tab does not list it.

  The event entries are dated from the events themselves, so the trail agrees with the catalog rather than talking over it: a creation carries the event's own first‑seen date, and the edits behind the demo's shipped, archived and deprecated events carry the instant their event history records — the two surfaces describe the same edits from their two angles. Nothing was ever bulk‑edited or deleted in the recipe, so those filters start empty and mean it; do one yourself and watch the row appear.

• Semantic search — the demo bundles precomputed embedding vectors for its own content and a few suggested queries (try purchase funnel or money back in the command palette), so smart search ranks by meaning and marks semantic matches even on instances with no embedding provider configured. Each vector is indexed both by its exact text and by the entity it describes, so a scan that rewrites a document's details (observed values replacing a ${variable} template, say) keeps its precomputed vector instead of dropping out of semantic search. No API key is used and no text leaves the instance; the vectors ship with the release. Outside the demo project, semantic ranking still requires an embedding provider (AI and search configuration).

What is preview‑only / local‑simulated

• Alerting. The demo ships a local demo_sink destination, plus one visibly disabled Slack example that carries no credentials. Rules evaluate real seeded signals and render real messages, and rules, the replay simulator, deliveries, and the Inbox are all explorable — but delivery is recorded locally and simulated. Nothing is ever sent to Slack, Telegram, email, a webhook, Jira, Linear, PagerDuty, or Microsoft Teams, and the UI labels these as local simulated deliveries (never a real send success). A demo project is zero‑egress by construction: the API refuses to create any destination on it other than the local sink, so a demo can never be pointed at a real channel — connect Slack, Telegram, a webhook, email, Jira, Linear, PagerDuty, or Microsoft Teams from a real project instead. The local sink itself cannot fail, so the recipe seeds one failed earlier attempt at the same incident: the failed‑delivery state and the Retry action are reachable from the Delivery log table, and retrying it re‑dispatches down the normal path and succeeds.
• Implementation tickets and AI features are surfaced with a clear next step rather than performing an external action.

What is intentionally unavailable

• External sends of any kind from demo data.
• Arbitrary unsupported SQL against the synthetic source — it supports the demo's shapes and returns a clear capability error otherwise, never a fabricated result.
• Attaching the synthetic source to a real project, or converting it into a real connection.

Finding your way around

The demo offers two guides, and they do different jobs.

• The product tour (the Quick overview stepper in the Tour & chapters dialog — Browse chapters on the welcome panel) walks the surfaces: Events, Scans, Overview, Metrics and fact tables, Alert rules, Anomalies, Coverage, Reconciliation, Branches and the alert preview, and ends by opening Search by meaning (the command palette) for you. Opening a step's surface advances the tour and it remembers where you were, so it can be followed across navigations instead of restarting every time. Open <surface> leaves the tour docked as a small card on that page — Tour · step N of 11, the page's name, Next: <next page>, All steps to reopen the dialog, and Close the tour, which keeps your place. The card hides while a chapter is running. All surfaces at the bottom of the tour expands a direct index of every surface and metric building block.

• The coached chapters (Start: <chapter> on the welcome panel, or Hands-on chapters at the top of the Tour & chapters dialog) each make one thing happen end to end. The first, Run the live loop, is the core:

  1. Run a scan — from any scan's Run now.
  2. Watch it land — the run completes and shows what it changed.
  3. Collect a metric — from Collect now on any metric.
  4. See the chart move — open that metric and see the series your collection recomputed (a daily metric gains a new point only once a day has closed).

  The other chapters walk one area apiece: Edit an event (on Trial Started, replace the current Product ID value with prod_monthly; the guide advances automatically, then asks you to type $, select ${product_id}, and save), Properties & value drift, Review a branch (up to the merge preview — merging stays your call), Reconcile the plan, Route an alert (against the local demo sink), and Explore the rest.

  A strip joined to the bottom of the demo banner — one bar, not two cards — tracks which chapter and step you are on and links to where the next action lives (the link hides when you are already on that page); a callout points at — and visibly rings — the exact button or input that performs it. Callouts use an opaque raised surface anchored beside the control they ring, and flip to stay inside the viewport. A control inside a data table has no free side — every direction the callout could open on is more table — so those callouts keep the ring on the control and dock the card to the edge of the window instead (the bottom, or the top when the control is in the lower half, on the control's side of the window; full width on a phone), and the rows stay readable. A docked card collapses to its step line with its chevron. The ring is clipped to what can be seen of the control, so it never floats over the page when the control scrolls out of a table. On a phone the coach card always docks at the bottom of the screen. Screen readers hear the step's instruction as the control's description. Hide hints — on the callout, or in the strip — quiets the callouts for the rest of the browser session on that project; Show hints in the strip brings them back. Both are demo-only and never appear in a real project.

  The chapters follow your actions, not the demo's. The runtime clock is producing real scans and collections of its own in the background, so a step advances only when the run or collection you started settles — a background run never ticks it forward. A run that fails, or that a reset wipes out, sends you back to the action with an explanation rather than leaving you waiting. The current Scans page also follows that exact run to its terminal status, even if a realtime update is missed, so completing the step never requires a reload. Progress is remembered per project (in your browser), so reloading mid-scan resumes the watch, and two tabs on the same demo keep each other's progress. A viewer, who cannot run scans or edit, sees "This step needs edit access…" in place of the action. On your first visit to the Overview the welcome panel stands in for the strip; the strip appears there once you start a chapter or put the panel away.

  Dismiss it at any point — including after finishing. The welcome panel is a single row, so the Overview leads with the product rather than with onboarding: Start: <chapter> (or Continue: <chapter> once you have begun), Browse chapters, which opens the Tour & chapters dialog — Hands-on chapters first, then the Quick overview stepper — and Create a real project. Dismissing the panel outright (the ✕) hides it for that project and offers Undo for a few seconds. After that, the demo bar's Tour & chapters button — present on every demo surface, for everyone — opens the same dialog, and the tour offers Show the welcome panel on Overview while the panel is hidden.

Lifecycle

• Create — provisioning is atomic: you either get a fully‑ready demo or a clean failure, which never leaves a half‑built project in your workspace. The request only reserves the workspace; a background worker seeds it, and the dialog waits until the workspace reads ready. That keeps the app responsive for everyone while many demos are created at once — they queue on the worker instead. An instance that keeps a pool of demos seeded ahead of time hands you one of those at once. It takes about 10 seconds on an idle server; the creation dialog narrates the expected phases (the server reports only the final result, not the stage it is on), says so when a create runs well past that, and stops waiting after 90 seconds. A failure says what is actually known: the server's own failure was rolled back and can be retried; a demo limit or a refusal says why and offers no retry; a lost connection or a timeout may still have created the demo, so the dialog offers no Try again — check the projects list first.
• Cancel — closing the creation dialog, pressing Escape, or clicking Cancel asks the server to abandon the provision, not just the browser to stop listening. If it is still seeding, the workspace is discarded and nothing is added to your projects or left behind in the audit log. If the demo finished just before the cancel arrived, the dialog says it is in your list — delete it from its banner's Manage demo menu if you do not want it. If the server had nothing left to cancel at all, the dialog says only that.
• How many — you can hold up to three demo workspaces at a time. At three, Generate demo project is disabled with the reason beside it: reset or delete one first from its banner's Manage demo menu. Beyond the first, generating another asks for confirmation and points at Reset; each extra demo is named Demo Project 2, Demo Project 3, … so they are distinguishable in the workspace list. A new demo takes the lowest name you are not already using, so after deleting Demo Project the next one is named Demo Project again rather than repeating a name you still have.
• Reset — chosen from the banner's Manage demo menu; re‑seeds the demo in place under the same URL, preserving ownership and its name. Reset re‑runs the current recipe, so it is also how you refresh a demo built from an older one. It re‑seeds everything in one transaction and takes about as long as a create; a progress dialog narrates the wait. If the reset has not answered after 90 seconds the page stops waiting and says the server may still be re‑seeding. It leaves for the Overview and drops the cached data and branch selection at once, then keeps checking for a few minutes: when the re‑seeded demo appears it finishes the reset as usual (fresh chapter progress, welcome panel back). Reset and Delete stay off in the Manage demo menu while it checks.
• Delete — chosen from the banner's Manage demo menu; removes the demo and its owned synthetic warehouse and leaves every real workspace source untouched. The creator or an owner can delete it. A demo is visible only to its creator (and the organization's owners and admins) unless they add members in Settings → Project → Access; a reset keeps those members. The tour position, chapter progress and welcome/hint choices your browser kept for it are cleared too — and the workspace page clears them for any demo that was deleted elsewhere, the next time it lists your projects.
• Recipe version. Each demo records the recipe version it was built from, shown on the demo banner.
• Failed shells. A demo whose seed failed leaves a hidden, non-listable project row behind as a diagnostic marker. Those are reclaimed automatically: the next demo creation on the instance deletes any that are more than a week old.

Turning the demo off for a deployment

Two operator switches control the feature, both documented in the Configuration reference:

• DEMO_ENABLED=false turns demo provisioning off. That blocks Create and Reset — a reset re-seeds a demo from scratch, so it provisions one too — and both answer 403 Demo provisioning is disabled. Delete deliberately stays available, so a workspace can never be stuck with a demo it cannot remove.
• DEMO_RUNTIME_ENABLED=false stops the background tick that keeps an existing demo fresh. The demo stays fully usable with the data it already has.

Neither flag affects real projects.