Skip to content
SynthGraph
Private research pilot

Know exactly what produced your model.

SynthGraph captures the provenance of synthetic-data experiments, connecting generation parameters, datasets, training runs, and evaluation results into a reproducible research history.

Request a DemoSee How It Works

Built for computer-vision researchers. Designed to work with the tools you already use.

  1. 01Generationgenerator, parameters, seed
  2. 02Dataset versionreferenced, not uploaded
  3. 03Training runconfiguration and inputs
  4. 04Evaluation resultmetrics tied to their source

Illustrative data. Shown to explain the provenance model, not a benchmark or customer result.

The problem

Synthetic-data experiments are easy to run. Hard to reconstruct.

A generation can take hours of compute. The configuration that produced it may live in a script, a notebook, a simulator, a local file, an experiment tracker, or someone’s memory.

Today

  1. 01Generatehours of compute
  2. 02Save config somewherescript · notebook · simulator UI
    link not recorded
  3. 03Train modelseparate machine, separate repo
  4. 04Log metrics elsewhereexperiment tracker
    link not recorded
  5. 05Compare spreadsheetshand-copied numbers
    link not recorded
  6. 06Months later“What exactly did we run?”

With SynthGraph

  1. 01Generationgenerator · parameters · seed
    recorded relationship
  2. 02DatasetVersionreferenced by exact version
    recorded relationship
  3. 03TrainingRunconfiguration · inputs
    recorded relationship
  4. 04EvaluationResultmetric, tied to its source

The same work, with the connections between steps written down at the moment they exist — rather than reconstructed from memory months later.

Capture once

Artefacts with no relationship

Code, assets, a generator, a dataset folder, a metrics dashboard, a page of notes. Each one exists. None of them points at the others.

  1. Scattered
  2. Structured
  3. Connected
  4. Reproducible

What it does

Capture once. Derive everything else.

Provenance is recorded at the point where the information still exists. Everything downstream — search, comparison, reproduction — reads from that same record.

  • 01

    Capture

    Record generation parameters, seeds, generator versions, asset references and code metadata at the moment the run happens.

  • 02

    Version

    Reference exact dataset and asset versions without moving the underlying data out of the storage it already lives in.

  • 03

    Connect

    Link generations, dataset versions, training runs and evaluation results into a single directed history.

  • 04

    Search

    Find experiments by project, generator, time, metadata or the parameters that actually matter to the question you are asking.

  • 05

    Compare

    Inspect the differences between two experiments — configuration, inputs and results side by side.

  • 06

    Reproduce

    Generate a reproduction manifest showing what is known, what is referenced externally, and what is missing.

Lineage

See the experiment, not just the metric.

A metric tells you what happened. Lineage helps you understand why.

  1. 01

    Generation

    The run that produced data: generator and version, parameters, seed, referenced asset versions, code version.

  2. 02

    DatasetVersion

    A specific version of a logical dataset, identified by reference and version rather than by folder name.

  3. 03

    TrainingRun

    The training configuration and the exact dataset versions it consumed.

  4. 04

    EvaluationResult

    The metric, attached to the run that produced it and, through it, to everything upstream.

Illustrative data. Shown to explain the provenance model, not a benchmark or customer result.

Integration

Keep your workflow. Add provenance.

SynthGraph does not ask researchers to move their work into another platform. The Python SDK sits inside the workflow they already have.

Tools you keep

  • Blendergenerator
  • Unitygenerator
  • Omniversegenerator
  • Custom Pythongenerator
  • PyTorchtraining
  • W&Btracking
  • Gitcode version
  • Storagedatasets

What the call becomes

  1. 01Python processyour script, notebook or job
  2. 02SynthGraph SDKtyped models, retries, idempotency
  3. 03HTTPS / JSONauthenticated request
  4. 04SynthGraph APIserver-side validation
  5. 05Provenance storagerecords, versions, relationships
sweep.py
from synthgraph import SynthGraphClient, Generator, Reproducibility client = SynthGraphClient(    api_key="...",) generation = client.generations.create(    experiment_id="experiment_123",    name="Rainy Scene Generation",    generator=Generator(        name="blender",        version="4.2.0",    ),    parameters={        "weather": "rain",        "occlusion": 0.30,        "camera_distance": 12,    },    reproducibility=Reproducibility(        seed=42,    ),)

The generator still runs where it always ran. What changes is that the parameters, the seed and the generator version are now written down next to the result they produced.

Storage

Your datasets stay where they already live.

SynthGraph primarily manages metadata, provenance and references. Large generated datasets can remain in the researcher’s filesystem, lab storage, or object storage.

SynthGraph stores

  • Metadata
  • Lineage relationships
  • Dataset and asset versions
  • References and checksums

You keep

  • Images and video
  • Rendered sequences
  • Full datasets
  • Whatever your storage already holds

The particles in these graphs represent recorded relationships between records — not the transfer of dataset bytes. Nothing in a provenance record requires the underlying data to move.

Dataset versioning

A dataset is not a single thing. It has history.

A logical dataset can evolve. SynthGraph records the exact DatasetVersion used by a generation, training run or evaluation, so historical lineage stays meaningful after the dataset moves on.

  • Generation Aproducedrain_dataset:v1
  • Generation Bproducedrain_dataset:v3
  • Training runconsumedrain_dataset:v1 + v3
  • Evaluationran againstrain_dataset:v3

Illustrative data. Shown to explain the provenance model, not a benchmark or customer result.

Asset versioning

The scene matters. So do the assets.

Generations can reference exact asset versions rather than merely recording an asset name. A run that used vehicle-model:v7 stays distinguishable from one that used v2, long after the file on disk has been replaced.

  • vehicle-model

    • v1
    • v2
    • v7referenced

  • forest-texture

    • v1
    • v4referenced

Geometry in this scene is generated procedurally from primitives. No third-party models or textures are used.

Comparison

Compare experiments by what changed.

Two experiments, aligned field by field. The differences are marked so the configuration change and the result change are visible together.

EXP-00142 vs EXP-00131

3 fields differ

Field-by-field comparison of two illustrative experiments
ParameterExperiment AExperiment B
GeneratorBlender 4.2Blender 4.2
Seed4242
Weatherrainrain
Occlusion0.300.45changed
Camera distance1212
Datasetrain_dataset:v7rain_dataset:v8changed
Asset: vehicle-modelv7v7
Epochs5050
mAP0.7240.748changed

A comparison shows which recorded fields differ and which results differ. It does not establish that one caused the other — two runs can differ in a parameter and a metric without the parameter being responsible. SynthGraph’s job is to make the differences inspectable; the inference stays with the researcher.

Illustrative data. Shown to explain the provenance model, not a benchmark or customer result.

Interface

Every experiment, with its history attached.

Projects hold experiments. An experiment holds the generations and training runs that belong to it, and the evaluation results they produced.

SynthGraphIllustrative UI preview

Recent experiments

Rainy Scene Generation

Generation

Generator
Blender 4.2.0
Seed
42
weather
rain
occlusion
0.30
camera_distance
12

Assets

vehicle-model
v7
forest-texture
v4

Dataset

Version
rain_dataset:v7
Reference
s3://research/rain-v7
Frames
24,000

Training

Model
YOLO
Framework
PyTorch
Epochs
50

Evaluation

mAP
0.724
Precision
0.78
Recall
0.69

Illustrative interface preview using demo data. Not a screenshot of a shipped application, and not a customer result.

Reproduction

Reproduction should start with evidence.

A reproduction manifest gathers the recorded configuration, code and version information, seeds, assets, dataset references and missing dependencies needed to reconstruct an experiment.

manifest.json
{  "generation": {    "generator": "blender",    "version": "4.2.0",    "seed": 42,    "parameters": {      "weather": "rain",      "occlusion": 0.30,      "camera_distance": 12    }  },  "assets": [    { "name": "vehicle-model", "version": "v7" },    { "name": "forest-texture", "version": "v4" }  ],  "dataset": {    "version": "v7",    "uri": "s3://research/rain-v7",    "checksum": "sha256:9c1f…e40b"  },  "code": {    "commit": "8f3a2b1",    "branch": "rain-sweep"  },  "missing": [    "external CUDA environment",    "GPU driver version"  ]}

What the manifest asserts

These are the recorded facts: this generator at this version, these parameters, this seed, these asset versions, this dataset reference, this commit.

What it does not assert

That re-running will produce identical output. Where a dependency was external or unrecorded, the manifest says so. SynthGraph makes the dependencies and the known provenance explicit — it does not guarantee exact reproduction.

Failures

Failed experiments are still evidence.

A generation that failed halfway through still tells you which parameters you have already tried and what happened when you did. Failed runs keep their provenance and stay part of the experiment history rather than disappearing from it.

  • GEN-004817status: failed

    renderer exited at frame 812

    • Blender 4.2.0
    • seed 19
    • occlusion 0.62

    provenance preserved

  • GEN-004821status: completed

    24,000 frames written

    • Blender 4.2.0
    • seed 42
    • occlusion 0.30

    provenance preserved

Record lifecycle

Once a run starts, its inputs stop moving.

A provenance record is only useful if it still describes what actually ran. When a generation moves out of PENDING, the fields that define the run are fixed; only operational fields keep changing.

Successful run

  1. PENDINGeditable
  2. RUNNINGinputs frozen
  3. COMPLETEDinputs frozen

Failed run

  1. PENDINGeditable
  2. RUNNINGinputs frozen
  3. FAILEDinputs frozen

Frozen at RUNNING

  • generator and version
  • parameters
  • seed
  • code version
  • environment metadata
  • input DatasetVersions
  • AssetVersions

Still changes

  • status
  • timestamps
  • completion metadata
  • error detail

Parameter space

Look at the runs you have already done.

Recorded experiments can be plotted against the parameters they varied. It is a way of reading experiment history — seeing where a sweep has been dense and where it has not.

This is a visualisation of search and comparison over past runs. SynthGraph does not propose parameters, run sweeps on your behalf, or optimise anything. Choosing the next experiment stays a research decision.

Illustrative data. Shown to explain the provenance model, not a benchmark or customer result.

Who it is for

Built around how research actually happens.

SynthGraph is designed for computer-vision research groups working with synthetic data — not for a generic enterprise workflow.

  • PhD researchers

    Keep experiments traceable while working toward papers, theses and reproducibility supplements — including the runs that did not make it into the results table.

  • Postdoctoral researchers

    Manage repeated experiments across long projects without relying on scattered notes, folder names and scripts that have since been edited.

  • Research labs

    Preserve experiment knowledge across projects, machines and researchers, so a run stays legible after the person who ran it has moved on.

  • Research engineers

    Connect generation infrastructure to downstream training and evaluation, and give the rest of the lab a consistent record of what produced what.

Request a Research DemoFor Researchers

Developers

A Python SDK, not another platform you have to live inside.

The SDK is the primary integration surface. It wraps the generator and training code you already run, and sends structured records to the API.

Early developmentPrivate integration stage

Architecture

  1. Existing tools
  2. SynthGraph SDK
  3. HTTPS / JSON
  4. SynthGraph API
  5. Provenance storage

The SDK is in early development and is being integrated against real research workflows during the pilot. It is not a finished v1.0 release, and the surface is still changing.

Design principles

  • Typed models

    Generators, parameters, reproducibility and references are typed rather than free-form dictionaries.

  • Canonical contract

    One provenance shape across every generator and training framework.

  • Flexible metadata

    Arbitrary domain metadata alongside the fields the model defines.

  • Safe retries

    Network failures during a long sweep should not corrupt a record.

  • Idempotency

    Repeating a call does not create a duplicate run.

  • Backend validation

    The server, not the client, decides what a valid record is.

  • Configurable endpoint

    Point the SDK at a hosted or self-controlled deployment.

  • Minimal instrumentation

    A small number of calls around code you do not have to restructure.

  • Storage neutrality

    References describe where data lives; SynthGraph does not require a particular provider.

Read the developer overview

Platform independence

One provenance model. Many research environments.

A generation from Blender, a generation from a custom C++ simulator and a generation from a Python script produce the same kind of record. That is what makes them comparable years later.

Roadmap

  1. v1.0Private pilot

    Manual capture

    The SDK is called explicitly from your own generation and training code.

  2. v1.1Planned

    Tool integrations

    Thinner wrappers for common generators and training frameworks.

  3. v1.2Roadmap

    Automatic instrumentation

    Capture that requires little or no explicit instrumentation in the research code.

Items marked planned or roadmap are not available today.

Security and privacy

Research provenance without unnecessary data collection.

The system is designed to hold as little as it needs to. Most of what makes an experiment reproducible is metadata — and metadata is what SynthGraph stores.

  • Transport security

    API traffic is served over HTTPS/TLS.

  • Server-side authorization

    Access decisions are made by the API, not by the client.

  • Protected API keys

    Keys are treated as credentials and are not written to logs.

  • No secrets in logs

    Structured logging excludes credential material.

  • Data minimisation

    Provenance records hold metadata and references rather than the datasets themselves.

  • Ownership boundaries

    Records belong to a user and a project, and access follows that boundary.

  • Deployment choice

    Cloud-hosted or local/self-controlled deployment, with the same provenance model.

  • Migration-backed persistence

    Schema changes are applied through versioned migrations.

On compliance claims

SynthGraph is designed with privacy and security requirements in mind. Formal legal compliance claims require appropriate legal review, and this site does not make them. You will not find certification badges here, because there are none to show yet.

Security overview

Deployment

Cloud when you need it. Control when you need it.

SynthGraph is designed to support cloud-hosted and local/self-controlled deployments while preserving the same core provenance concepts.

SynthGraph SDK

one client, one configurable endpoint

  • Cloud deployment

    A hosted API, so a lab can start recording provenance without operating a service.

    • Managed API
    • No infrastructure to run
    • Shared across a group

  • Self-controlled deployment

    The same provenance model, deployed where the institution’s requirements say it has to live.

    • Runs in your environment
    • Data stays inside your boundary
    • Same SDK, different endpoint

Deployment targets are described in terms of where the service runs, not in terms of a specific cloud provider. That choice is not finalised.

Private research pilot

Your next experiment should leave a trail.

SynthGraph is currently available through a limited research pilot. Request a demo to see how provenance fits into your existing workflow.

Request a DemoExplore the product

SynthGraph is being developed with a small number of research workflows before broader access.