Synthetic Data
Turning a column schema into realistic dataset rows, without real production data
What synthetic data is
Synthetic data is a dataset’s rows generated from a schema you define, instead of rows you upload or bring in yourself. You describe the columns you want, their names, types, and constraints, and Future AGI generates rows that match.
Define this schema for a customer-support dataset:
| Column | Type | Constraints |
|---|---|---|
| customer_query | text | Value: a realistic customer support question |
| sentiment | text | Categorical values: positive, negative, neutral |
| priority | integer | Value: 1 (low) to 5 (urgent) |
Generation produces rows like:
| customer_query | sentiment | priority |
|---|---|---|
| I haven’t received my order and it’s been two weeks | negative | 4 |
| Can I change the shipping address on my recent order? | neutral | 2 |
| Your product is fantastic, just wanted to say thanks! | positive | 1 |
Each column has its own Property editor for exactly this: Min Length and Max Length on most column types, Value set to Categorical for a list of allowed values, plus custom properties for anything else. Those column properties, not the column’s description, are where allowed values and ranges live.
Warning
Column properties steer the generator toward matching rows, but they aren’t hard validation on the result. Skim the generated rows before you rely on them.
To generate your first synthetic dataset hands-on, follow the Generate synthetic data quickstart.
The generation config
Every synthetic dataset saves what you defined as the dataset’s own generation config:
- Columns: the schema you defined, with each column’s name, type, and description
- Row count: how many rows to generate
- Description: what the dataset as a whole should contain
- Objective: how you plan to use the dataset, so generation can match that goal
- Pattern: an example or format you want the generated rows to follow
- An optional Knowledge Base link
That’s what lets you reopen a synthetic dataset later, change a column or the row count, and regenerate without rebuilding the schema from scratch. Here’s how the config, the job, and the dataset’s rows and state fit together:
flowchart TD accTitle: How synthetic data generation fits together accDescr: A synthetic dataset holds its own generation config, its rows, and a state that shows Generating, Regenerating, or Failed. A generation job reads the config, optionally grounded by a connected Knowledge Base, fills in the dataset's rows, and drives its state. subgraph DATASET["Synthetic dataset"] CFG["Generation config"] ROWS["Rows"] STATE["State · Generating, Regenerating, or Failed"] end JOB["Generation job · runs in the background"] KB["Knowledge Base · optional"] CFG -->|read by| JOB JOB -->|fills| ROWS JOB -->|drives| STATE KB -.->|grounds| JOB
When a Knowledge Base is connected, generation grounds rows in its content instead of relying on the schema alone.
Editing vs regenerating
| Action | What happens |
|---|---|
| Edit the config and save | Adds the columns and rows you added, drops the columns you removed, drops rows if you lowered the row count, and leaves every other column’s data as it is |
| Regenerate | Rebuilds all rows and columns from the config (destructive, see the warning below) |
Warning
Regenerating wipes the dataset’s current rows and columns and rebuilds them fresh from the config. If you only meant to add a column or a few rows, edit and save instead.
The saved config is what makes either possible: you’re never redefining the schema by hand.
When to use synthetic data
Reach for synthetic data whenever real rows are unavailable, risky to use, or lopsided for what you’re testing:
- No real data yet: you’re building a new feature and don’t have production rows to test against
- Privacy limits: real data carries PII you can’t put in a test dataset
- Edge cases: you need scenarios that are rare in real traffic, like an angry customer or a multilingual query
- Scale: you need thousands of rows to stress-test a prompt or eval
- Skewed data: real data leans one way (mostly positive reviews) and you need a more balanced set
While it’s generating, and when it fails
Generation doesn’t happen instantly. Because it runs as a background job, a synthetic dataset sits in a Generating state (or Regenerating, if you kicked off a rerun) with a live progress bar while the job works, and a Configure Synthetic Data button that reopens the schema.
If the job errors out, the dataset shows a Failed state instead, with the same button to fix the configuration and try again. See Dataset FAQ & fixes for what to check first.
Keep exploring
Questions & Discussion