Synthia: KPI-Aware Synthetic Dataset Agent

• 

  Vertex AI generation plan grounded in DataHub context, with deterministic targets from 11,830 DEV rows to 21,072 synthetic rows.

• 

  BigQuery proof: source and _synth datasets side by side, with materialized tables and KPI comparison results.

• 

  Observed KPI results showing original versus augmented synthetic groups across all five KPI queries.

• 

  DataHub governed evidence document with KPI coverage, generated table targets, findings, and reusable blueprint.

Inspiration

I built Synthia after seeing a practical problem: a DEV dataset already existed, but it still was not good enough for meaningful KPI testing by an Insights team.

The source contained 11,830 rows, so the problem was not “no data.” The problem was low cardinality, missing business groups, NULL values in KPI-relevant fields, and weak coverage for the exact KPI queries analysts needed to validate. Dashboards, joins, filters, ratios, and edge cases could not be tested reliably.

That is when the idea for Synthia was born: move analytical testing earlier, before production data arrives.

What it does

Synthia turns weak development data into a governed, KPI-ready augmented synthetic dataset.

The analyst selects a BigQuery dataset discovered through DataHub and provides the KPI SQL that needs to be tested. Synthia reads schemas, profiles, ownership, governance metadata, and PK/FK relationships through DataHub and the Agent Context Kit.

Vertex AI interprets the KPI intent and proposes missing categories, business scenarios, measure behaviour, and edge cases. Vertex AI handles semantic reasoning, while deterministic Python controls final row counts, quotas, generation order, validation, and safety limits.

Synthia measures readiness in BigQuery, dry-runs the compiled SQL, and generates a separate, schema-compatible _synth dataset from scratch. The complete augmented synthetic dataset is materialized directly in BigQuery, while the original DEV source remains untouched.

After successful generation, Synthia automatically writes evidence back to DataHub: schemas, properties, tags, lineage, selected data-quality findings, KPI coverage, and an Agent Context Kit Context document containing the KPI SQL contract, generation targets, and a reusable flat-table blueprint.

How I built it

The workflow is:

discover → analyze readiness → create a validated generation plan → generate augmented synthetic data → publish the _synth dataset to BigQuery → validate KPI outcomes → write governed evidence back to DataHub

The main components are:

• DataHub graph APIs for schemas, profiles, ownership, governance, and PK/FK relationships
• Agent Context Kit for agent-facing context
• Vertex AI for semantic KPI reasoning
• Python for deterministic sizing, quotas, ordering, validation, and guardrails
• BigQuery for readiness measurements, SQL dry-runs, and _synth materialization
• DataHub writeback for lineage, tags, findings, KPI coverage, and reusable evidence

The hardest part

The hardest part was finding the right boundary between AI reasoning and deterministic control.

Vertex AI is useful for understanding KPI intent and suggesting missing scenarios, but it should not decide final row counts or whether a generation plan is safe.

So Synthia follows a strict rule:

AI proposes; Python controls.

Python validates the proposals, calculates exact quotas, preserves PK/FK integrity, generates parent tables before dependent tables, and enforces execution limits.

Another challenge was increasing cardinality without creating arbitrary data. Generated values had to remain grounded in measured source profiles while covering the business groups required by the KPI contract.

Results

In the brokerage demo:

• 11,830 source DEV rows were analyzed
• 7 related BigQuery _synth tables were materialized
• 21,072 augmented synthetic rows were generated
• 5/5 KPI contracts passed deterministic plan validation
• 7 DataHub schema registrations were created
• 7 source-to-synthetic lineage links were registered
• DataHub writeback completed automatically
• The original DEV dataset remained unchanged

Safety boundaries

Synthia never modifies the source dataset.

The target must be separate and end in _synth. Parent tables are generated before dependent tables. KPI-required columns and generated join keys target zero missing values, while other columns may retain NULLs.

Python owns the final quotas, enforces a default one-million-row ceiling, and requires generated SQL to pass a BigQuery dry-run before execution. Synthetic assets are tagged so they cannot be reused recursively as new source data.

What I learned

The biggest lesson was that DataHub can be more than a catalog. It can act as the trusted context and governance layer for an agent that performs real data work.

The second lesson was architectural: semantic reasoning and execution control should not be mixed. Keeping them separate made Synthia more explainable, testable, and safe.

The third lesson was that generating a synthetic dataset with referential integrity, increased cardinality, and selected distributions grounded in measured source profiles is much harder than simply generating random data.

Built With

• agent-context-kit
• bigquery
• datahub
• datahub-graph-api
• google-cloud
• google-gen-ai-sdk
• metadata
• pydantic
• python
• sql
• sqlglot
• vertex-ai