> For the complete documentation index, see [llms.txt](/llms.txt)

# 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](/docs/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](/docs/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](/docs/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](/docs/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](/docs/drift-detection)).

See the [CLI reference](/docs/cli) for every flag — [`glotto generate`](/docs/cli#glotto-generate)
and [drift detection](/docs/drift-detection).