Automated quality gate
Five checks before a recipe is published
Complete recipe contract
The audit requires a question, event schema, SQL, sample result, visualization, explanation, edge cases, dashboard guidance, alert guidance, and related reading.
Read-only statement policy
Queries must start with SELECT or WITH. The audit rejects DDL and write keywords such as CREATE, INSERT, UPDATE, DELETE, DROP, ALTER, and MERGE.
Typed DataFusion execution
Each schema becomes an empty Apache Arrow record batch. The query is planned and executed with Apache DataFusion 45.2.0, catching invalid columns, types, functions, and syntax.
Reproducible browser fixtures
30 cross-category recipes also execute their complete synthetic input with DuckDB 1.3.2 and compare every expected result value within displayed precision.
Rendered-page integrity
The site audit renders every recipe and checks its status, canonical URL, title, description, H1, structured data, and internal links.
What the execution check proves
The audit constructs every documented table from the field names and Arrow types shown on the recipe page. It registers an empty batch in a fresh DataFusion session, runs the exact published SQL, and fails if the engine rejects the plan or execution. This catches misspelled fields, incompatible operations, unsupported functions, ambiguous columns, malformed intervals, and many return-type mistakes without requiring production data.
The pinned version is intentional. SQL engines evolve, so a query is not labeled compatible merely because a similar dialect accepts it. When the application upgrades DataFusion, the full collection is rerun before the documented version changes.
Safe to copy is not safe to assume
The query cannot know your definition of an active account, recovered payment, permanent webhook failure, or acceptable latency. Each recipe names those choices so reviewers can change them before a dashboard or alert becomes authoritative.
Human review
What still needs judgment
An empty typed table proves that a query plans and executes; it does not prove that a business definition is correct.
Displayed rows and charts are deterministic synthetic examples. They show the output shape and intended interpretation, not a benchmark or customer result.
Thresholds, minimum volumes, time windows, identity rules, currencies, and terminal statuses must be adapted to the event contract that owns them.
Late events, duplicated provider deliveries, incomplete newest buckets, and schema changes can alter real results even when the SQL is valid.
Public fixture contract
Every recipe publishes a JSON bundle with its typed schema, illustrative input rows, exact SQL, deterministic expected output, engine version, and review notes. A CSV exposes the same displayed result, while a static SVG makes the example chart indexable and reusable. The compact input demonstrates field names and JSON types; it is deliberately not represented as a complete generator for the aggregate result.
The 30 reproducible recipes go further: their complete synthetic rows execute in the browser SQL playground and are checked against the expected values. Other compact inputs remain schema demonstrations, preventing a tiny teaching fixture from being mistaken for a statistical validation set.
The connected SQL Lab uses a separate versioned, synthetic SaaS dataset so learners can practice joins and multi-stage business definitions without confusing the lesson data with production benchmarks.
Primary engine references
Apache publishes the authoritative SQL syntax, function, type, and upgrade documentation. The live reference may describe a newer release than Telemetry's pinned test target, so compatibility claims on recipe pages continue to name the exact audited version.
Validate a recipe on your own event contract
Match field names and types, send a small synthetic fixture that covers success and failure paths, inspect intermediate CTEs, compare totals to known inputs, and document the final business definition beside the saved query.