Data services / Built for the training run
Better models start with better data.
Open datasets you can inspect. Custom corpora built for your task. A validation pipeline that shows you what made the cut, and why.
Generation, validation, and the evidence to evaluate both.
10B+
synthetic code tokens released openly
Four containerized checks between generation and release. The validation harness ships with the data, so the verdicts can be reproduced.
Three ways in
Start with the data you need.
Explore an existing release, commission missing coverage, or improve your own corpus. The right starting point depends on the behavior you want to teach.
Looking for licensed corpora or commercial options?Explore data pricing
Inside the code pipeline
Plausible is a start.
Tested is the standard.
For our synthetic-code release, every sample passes four stages. The checks run in containers without a model judging the result, making each verdict reproducible.
These stages validate code. Custom datasets use checks suited to their domain and the task you want to measure.
- 01
Parse
Is it valid code?Reject malformed generations before they enter the pipeline. Samples must have valid syntax to proceed.
A parse verdict - 02
Compile
Does it build?Check the sample with its language's real toolchain. A plausible-looking answer is not enough to pass.
A toolchain result - 03
Execute
Does it pass its tests?Run the code against generated tests. Samples that fail the tested behavior are excluded from the release.
An execution result - 04
Mutate
Do the tests catch errors?Challenge the tests with changed code to catch suites that pass without proving anything useful.
A mutation-check result
- of raw generations were rejected in the published code pipeline. The release includes the samples that passed, together with the checks used to select them.
- ~40%
What ships with the release
The data.
The checks.
The full picture.
Token counts tell you how much data you have. Provenance, quality reports, and reproducible checks help you decide what to do with it.
- 01
Data with context
The dataset card and per-sample provenance tell you what went into the corpus. Pipeline verdicts make the filtering decisions inspectable.
Understand the source and selection criteria.
- 02
Checks you can rerun
The validation harness ships alongside the data, with the containers used for the checks. Re-verify a slice or extend the pipeline for your work.
Reproduce the verdict, then adapt the method.
- 03
Quality beyond one score
Per-language and per-slice breakdowns expose differences that an aggregate acceptance rate hides. Use those reports to choose a relevant training mix.
Choose data for your task, not just its size.
The open collection
Inspect. Evaluate. Build.
Each release ships with its dataset card, its checks, and the research behind it, so you can find the right starting point for your run.
Built around your task
Turn a data gap into a clear brief.
Start with what your model needs to do better. We can scope generation and validation around those goals, with a handoff that fits the training run.
Step 01
Define the task
Share the behavior you want to improve, the model you plan to train, and examples of where it falls short.
Step 02
Agree on the checks
Set the domain coverage, evaluation targets, and validation approach before scaling generation.
Step 03
Review the handoff
Align on the corpus, harness, and validation evals you need to bring the data into your training workflow.
Before you train
A few useful details.
Understand the data, choose the right checks, and measure the result against your task.
How do open releases differ from custom data?
Open releases are published research artifacts you can inspect and evaluate against your task. A custom engagement starts with your domain, model, and evaluation targets, then scopes generation and validation around them. Check each release's dataset card for its terms and intended use; custom scope and terms are agreed with the team.
Can I use the pipeline with data I already have?
Yes. Bring-your-own-data work can include deduplication, decontamination checks, and per-sample quality scoring. Synthetic augmentation can be discussed if your corpus needs additional coverage. Bring a representative sample and your evaluation goals to scope the right checks.
Does every dataset use parse, compile, execute, and mutate?
Those four stages describe our published synthetic-code validation pipeline. Other domains need checks appropriate to their outputs and tasks. For a commissioned dataset, the validation approach is part of the scope, rather than assuming a code compiler can validate every kind of data.
What does passing validation tell me?
A passing sample satisfies the checks that were run. The quality breakdowns help you select relevant slices, and the harness lets you inspect or extend the checks. To understand the effect on your model, measure the resulting training run against your own held-out evaluations.
What should I prepare for a custom dataset discussion?
A short description of the task, target model and size, example inputs and outputs, known failure cases, and evaluation criteria. If you already have data, describe its format, approximate volume, and any handling constraints. These details help the team scope coverage, checks, delivery, and pricing.