> ## Documentation Index
> Fetch the complete documentation index at: https://agents.concierca.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Build: Passport, Genome, Manifest, Blueprint

> The Build surfaces: Passport, Genome, Manifest, Blueprint, plus Variables, Versions, Test (pre-flight), and SOP.

The **Build** tab is where a mission is described, understood, checked, and packaged — everything *about* the mission that isn't the live step list itself. It gathers four identity surfaces (Passport, Genome, Manifest, Blueprint) alongside Variables, Versions, a pre-flight Test, and an auto-written SOP.

## The four identity surfaces

<CardGroup cols={2}>
  <Card title="Passport" icon="passport">
    The business identity **you** write.
  </Card>

  <Card title="Genome" icon="dna">
    A structural fingerprint of the steps, generated automatically.
  </Card>

  <Card title="Manifest" icon="clipboard-list">
    What the mission technically needs to run.
  </Card>

  <Card title="Blueprint" icon="box-archive">
    A portable, secret-free export of the whole mission.
  </Card>
</CardGroup>

### Passport — the business identity

The **Passport** is the part you fill in: what this mission *is*, in business terms. It captures the mission's **domain**, its **use case**, the **industry**, the **outcome it promises**, its **risk level**, and its **sharing policy**. It's the human-readable "who and why" that gives the rest of Build its meaning. It's editable at any time.

### Genome — the structural fingerprint

The **Genome** is generated for you from the steps. It describes the *shape* of the flow, not its content: the **pattern** (for example *agent → wait\_poll → human*), an **archetype**, a **complexity** measure, and the **automation ratio** (how much runs without a person). Two missions with the same Genome work the same way even if they do different jobs.

### Manifest — what it needs to run

The **Manifest** is the mission's requirements list: the **agent roles** it uses, the **systems and connections** it touches, the **data** it reads, and the **permissions** it needs — plus whether it needs **human approval**, makes **external calls**, or runs on a **schedule**. It's the fastest way to answer *"what does this mission depend on?"* before you rely on it.

### Blueprint — the portable export

The **Blueprint** is a **secret-free JSON export** of the entire mission — its steps, contracts, and settings, with credentials stripped out. **Preview** and **Export JSON** let you copy, review, or archive a mission's design safely. (Publishing and installing blueprints into other workspaces is not yet available.)

## Variables

**Variables** are the named values your steps reuse via `{{vars.key}}` — either static values or references to a connection (secrets stay hidden). Each variable tracks which steps use it, so you can see the impact before you change one. This is the other half of the [templating](/guide/mission-flow) you set up in the flow.

## Versions

**Versions** is the mission's configuration history — a safety net for changing a live mission.

| Action      | What it does                                                         |
| ----------- | -------------------------------------------------------------------- |
| **History** | Every published version of the mission's configuration.              |
| **Diff**    | A step-level comparison between two versions — exactly what changed. |
| **Restore** | Roll the mission back to an earlier version.                         |

Publishing a change **captures the current version first**, so you can always compare or roll back. See [Triggers & Drafts](/guide/mission-triggers) for the full draft-and-publish flow.

## Test — pre-flight before you run

**Test** runs a **pre-flight validation**: a **read-only** readiness check with **no side effects and no agent runs**. It confirms the mission is fit to run and reports a readiness result.

It checks that:

* the mission is **active**;
* every **agent step** has an assigned, active agent;
* every **human step** has an approver;
* any **webhook trigger** has a secret;
* there are **enough credits**;
* and it does a **mocked happy-path walk** that proves the steps are ordered correctly — without running anything.

<Note>
  Pre-flight is the cheap way to catch a broken mission before it costs a credit. Run it after any edit to the flow, agents, or triggers.
</Note>

## SOP — the auto-written runbook

**SOP** is a Standard Operating Procedure document **generated from the current flow** — purpose, scope, responsibilities, the process step by step, approvals, and audit rules. It's a plain-language runbook you can hand to a colleague so a mission isn't a black box.

<Note>
  From an AI client, these surfaces map to `mission_validate` (pre-flight), `mission_compare_versions`, and the mission read tools. See the [Missions API reference](/for-agents/missions) and [Mission Recipes](/for-agents/ai/mission-recipes).
</Note>