The pipeline

glotto generate is the end-to-end driver. It composes the pipeline stages — it never re-implements them — into a single deterministic flow:

1. Resolve + ingest + normalize the spec. The OpenAPI / AsyncAPI / GraphQL source is parsed and normalized into a byte-stable canonical spec (stable server URLs, sorted keys, stable example IDs). Determinism here is what makes regeneration reproducible.
2. Build the IR + apply transforms. buildGlottoIR turns the canonical spec into a Glotto IR, applying glotto.yml#/transforms.
3. Dispatch to enabled targets. The IR is handed to each engine listed in glotto.yml#/targets (@glotto/codegen-*) — SDKs, the docs site, the MCP server.
4. Write the output.

Because step 1 is deterministic, the same spec + glotto.yml always produce byte-identical output — which is what makes drift detection and committed codegen possible.

Seeing it hold

This page is the overview; each step’s proof lives with the step. Rather than restate them here, go to the two pages that own them — both render what Glotto’s own machinery printed, not a description of it:

• Drift detection — the check that fails a PR when committed output stops matching the generator, shown both in sync and catching a real change.
• The verification report — the per-regeneration attestation: pinned input hashes, per-target drift, managed-file integrity, and compile status.

Two commands

• glotto generate runs the whole flow and writes the result.
• drift detection runs it in memory and fails if the committed output has drifted (see Drift detection).

See the CLI reference for every flag — glotto generate and drift detection.