Governed datasets

Turn data definitions into versioned assets with explicit lineage.

Dataset separates exploratory SQL from a reusable data contract. Its stable identity, immutable versions and semantic metadata create a controlled foundation for reports without hiding the source lineage.

Dataset separates exploratory SQL from a reusable data contract. Its stable identity, immutable versions and semantic metadata create a controlled foundation for reports without hiding the source lineage.
A Dataset is a contract, not a renamed query result.

Dataset connects source and query lineage, normalized SQL, column and semantic metadata, lifecycle state and immutable DatasetVersions. SavedQuery remains editable SQL; Report describes analytical intent.

Version means exact contract state.

Changing Dataset-owned SQL, joins, source, schema, columns or column metadata creates a new DatasetVersion. Analytics metrics, RLS and report permissions remain separate contracts. Existing ReportVersions stay pinned until a user validates the new DatasetVersion and saves a new ReportVersion.

A virtual version does not automatically freeze rows.

When a DatasetVersion stores a live SQL contract, later runs can read newer source rows while using the same definition. Exact historical result reconstruction requires the run hash and retained artifact or an explicit materialized snapshot.

Comparison shows recorded change, not invented impact.

Users can compare normalized SQL, columns, types and known lineage metadata. The platform does not claim universal downstream business impact analysis for relationships that were never recorded.

Dataset and Analytics keep separate responsibilities.

Dataset owns the stable data asset and versions. Analytics owns metrics, RLS, resource permissions, Query Context and report execution. The distinction keeps governance boundaries reviewable.

A Dataset is a contract, not a renamed query result.

Dataset connects source and query lineage, normalized SQL, column and semantic metadata, lifecycle state and immutable DatasetVersions. SavedQuery remains editable SQL; Report describes analytical intent.

A Dataset can originate from SQL Console execution, SavedQuery, a physical table or a controlled transformation.

DatasetColumn records known schema and profile metadata for the exact version.

SQL Console promotion aligns the canonical Dataset with the Analytics semantic projection without merging their ownership boundaries.

Version means exact contract state.

Changing Dataset-owned SQL, joins, source, schema, columns or column metadata creates a new DatasetVersion. Analytics metrics, RLS and report permissions remain separate contracts. Existing ReportVersions stay pinned until a user validates the new DatasetVersion and saves a new ReportVersion.

Report v4 → Dataset v2 · Report v5 → Dataset v2 · Report v6 → Dataset v3

A virtual version does not automatically freeze rows.

When a DatasetVersion stores a live SQL contract, later runs can read newer source rows while using the same definition. Exact historical result reconstruction requires the run hash and retained artifact or an explicit materialized snapshot.

Comparison shows recorded change, not invented impact.

Users can compare normalized SQL, columns, types and known lineage metadata. The platform does not claim universal downstream business impact analysis for relationships that were never recorded.

Exact left/right version identity and SHA-256 SQL contract

Line-aware SQL comparison with insertions and removals

Column, type, nullable and known metadata changes

Explicit unchanged, changed, added, removed and unavailable states

Dataset and Analytics keep separate responsibilities.

Dataset owns the stable data asset and versions. Analytics owns metrics, RLS, resource permissions, Query Context and report execution. The distinction keeps governance boundaries reviewable.

Evolution is an explicit acceptance decision.

A new DatasetVersion does not silently move existing reports. The user compares the contract, validates dimensions and metrics, previews the generated query, then saves a new ReportVersion bound to the accepted DatasetVersion. Older ReportVersions and runs retain their original bindings.

  1. Compare Dataset v2 with v3.

  2. Confirm the changed SQL, columns and types.

  3. Open the report draft against Dataset v3.

  4. Validate metadata and compile read-only SQL.

  5. Preview under current permission and RLS context.

  6. Save Report v6 → Dataset v3 only after acceptance.

Next step

Start with the flow that cannot afford ambiguity.

Bring the systems, owners, rules, delivery obligations and evidence requirements that matter.

Discuss a critical flow