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.
• The seed content. Events, fields, meta fields, variables, 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).

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.

• 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. Inactive demos pause and resume on your next visit. An operator can turn this tick off with DEMO_RUNTIME_ENABLED=false; a demo then keeps the data it already has.

• 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, variable, 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, or Linear, 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, or Linear 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 (Take the tour on the welcome panel) walks the surfaces: Events, Scans, Live activity, Metrics and fact tables, Monitors, Anomalies, Coverage, Reconciliation, Branches and the alert preview. 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.

• The coached chapters (Coached chapters on the welcome panel, or Try it hands-on from the tour) 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 find the point your collection added.

  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), Variables & 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 below the demo banner tracks which chapter and step you are on and links to where the next action lives; 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 bottom‑right of the window instead, and the rows stay readable. 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.

  Dismiss it at any point — including after finishing. The welcome panel that carries the tour and the chapter picker opens collapsed, as a single row with a Show me around expander, so the Overview leads with the product rather than with onboarding; expanding it is not remembered between visits. Dismissing the panel outright (the ✕) hides it for that project, and the demo bar's Tour & chapters button — present on every demo surface, for everyone — brings it back and reopens the tour.

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. It takes about 10–15 seconds; the creation dialog narrates the expected phases (the server reports only the final result, not the stage it is on) and shows any failure.
• 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. If the seed had already finished, the dialog says so plainly and the demo appears in your list — delete it from its banner if you do not want it.
• How many — you can hold up to three demo workspaces at a time. 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.
• Reset — re‑seed 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.
• Delete — removes the demo and its owned synthetic warehouse and leaves every real workspace source untouched. The creator or an owner can delete it.
• 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.