Overview

DOGM turns a scenario spec, a short YAML file that describes tables, keys, columns and rules, into connected, fictional data. The same spec, seed and engine version give the same bytes on every machine, so a dataset is something you rebuild, not something you pass around.

Where to start#

How the pieces fit#

A spec goes through four steps, and the CLI, the hosted runs and the GitHub Action all run the same engine:

1. Compile. The engine checks the spec and returns every error with a JSON path and a stable code, or a plan.
2. Generate. It writes one file per table per chunk, plus manifest.json. output_sha256, the hash of the manifest, identifies the output.
3. Validate. Every key, reference, type and rule is checked, and the report comes out as JSON, JUnit XML and SARIF.
4. Mask, when the spec asks for it. Masking runs after validation, with a key you hold.

The engine never calls an AI model, the network or the clock. AI only drafts specs in the hosted app, and a person approves a spec before it runs.

Reference pages are generated#

The field tables, the generator list, the CLI help, the API reference, the Action's inputs and the plan limits come from the repository itself: spec.schema.json, the engine's catalog, the CLI's --help output, the API's OpenAPI schema, action.yml and the plans table. Every spec example on these pages is compiled by the CLI when the docs are regenerated and again in CI, so an example that stops compiling fails the checks instead of reaching you.