# Architecture (/architecture)



You don't need anything here to use Harmont — it's for the curious and for
debugging. The higher-level guides stay focused on writing and running
pipelines; this is the one place that explains what happens beneath them.

## From code to a build [#from-code-to-a-build]

Running a pipeline goes through a few stages:

1. **You write a pipeline** in the [Pipeline SDK](/pipeline-sdk) — a Python or
   TypeScript program under `.hm/`.
2. **`hm` compiles it** to a small, versioned JSON document — the intermediate
   representation (IR). The IR describes your steps as a graph: each step's
   command, image, cache policy, and which steps it depends on.
3. **Harmont creates a build** from that IR — one build with a job per step.
4. **The executor runs each job** in an isolated sandbox, streaming logs back
   as it goes. Dependent steps run in order and share a filesystem snapshot;
   independent steps run in parallel.

Two ways to start a build — hm run from your local working tree, or Harmont Cloud — both compile to the same IR. Harmont creates the build and the executor runs each job in an isolated sandbox, streaming logs back.

## Why an IR [#why-an-ir]

The IR is the stable contract between the SDK and the rest of Harmont. Both
the Python and TypeScript SDKs are front-ends that compile to the same IR,
which is why any example can ship the same pipeline in either language — and
why your choice of SDK is a matter of taste.

You can print the IR a pipeline compiles to, without running it:

```bash
hm render ci
```