> ## Documentation Index
> Fetch the complete documentation index at: https://docs.terminus.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Governance models
> The top-level container for the fields, picklists, and taxonomies that define how your team's campaign metadata is structured.
A governance model is the top-level container that holds the rules for a single data domain: its **fields**, its **picklists**, and its **taxonomies**. Define the rules once here, then expose them to the people who submit campaigns through workspaces. Most accounts run a single governance model.
## What it is
A governance model groups together everything that defines one campaign-metadata standard:
* **Fields**: the reusable definitions (text, URL, date, dropdown, short URL, QR code, and more). Each field belongs to one governance model. See [Fields](/reference/fields).
* **Picklists**: the option lists that dropdown fields choose from. Each picklist belongs to one governance model. See [Picklists](/reference/picklists).
* **Taxonomies**: ordered groupings of fields that become the forms people fill in. Each taxonomy belongs to one governance model. See [Taxonomies](/reference/taxonomies).
The governance model itself holds only a `name` and an optional `description`. The detail and structure live in its fields, picklists, and taxonomies. It is the definition layer, not the data layer: submissions and approved records live in workspaces, which consume the taxonomies a governance model exposes.
## When to use it
* You are setting up a new campaign-tracking standard and need one place to own its fields, picklists, and taxonomies.
* You want every workspace to draw on the same set of rules (field types, validation, computed values like UTM strings and short URLs).
* You need to keep two standards that share no fields fully separate. Create one governance model per standard.
Avoid creating multiple governance models when two standards share most of their fields. Fields, picklists, and references cannot cross from one governance model to another, so the sharing you want will not be possible.
## Creating and editing
You create a governance model from the model picker in the sidebar.
Choose **New**, then **Create from scratch** for a blank model, or import an existing one (see below). A blank model needs only a name to start.
Build the reusable field definitions and the picklists that feed your dropdown fields.
Create taxonomies that reference your fields in the order people should see them. See [Taxonomies](/reference/taxonomies).
Your edits stay as a working draft until you publish. Publishing a revision is what makes the current structure live for submissions. See [Publish a revision](/guides/publish-revision).
To rename a model or change its description, open its **Settings** page. The name is required and must be unique within your account. Two different accounts may use the same name; within one account each governance model name is distinct.
Creating, editing, importing, and deleting a governance model are admin actions. Any member of the account can view a model and export it.
### Deleting a model
Delete a governance model from its **Settings** page, behind a confirmation. Deleting a model removes everything it defines: its fields, picklists, taxonomies, and shared links. This cannot be undone.
## JSON import and export
A governance model can be saved to and rebuilt from a portable JSON file, so you can back up a model, move it between accounts, or hand a starting point to a colleague.
* **Export**: from **Settings**, choose **Export as JSON** to download the model as a `.json` file. The export uses readable placeholder identifiers (`gov_1`, `tax_1`, `fld_1`, `pkl_1`) instead of internal IDs, and it **includes the options inside your static picklists**, so the file is a complete, self-contained copy.
* **Import**: choose **Import from JSON** and upload a file. Import creates a brand-new model and all of its fields, picklists, and taxonomies in one step, rewiring every internal reference (parent picklists, computed-field sources, taxonomy field references) so the new copy is fully connected.
If you import a model whose name already exists in your account, the name is automatically suffixed: importing `Marketing` when `Marketing` exists creates `Marketing (1)`, then `Marketing (2)`, and so on. You never have to rename a file before importing it.
Import is all-or-nothing. If any part of the file fails the checks, nothing is created and the error points at the field, picklist, or taxonomy that needs fixing.
Import and export are available on every plan. There is no paid-tier gate on moving a governance model in or out as JSON.
## Gotchas
* **Deleting a model deletes its fields, picklists, and taxonomies.** A governance model cannot be deleted while any of its taxonomies still has approved records, because a taxonomy with records cannot be deleted. Never delete a model that has live records in any workspace.
* **References cannot cross governance models.** A field, computed-field source, picklist parent, or taxonomy field reference must stay within one model. Plan your model boundaries before you build. To move a field into a different model, recreate it there.
* **Names are unique per account.** If a name is taken in your account, choose another. The same name is allowed in a different account.
* **The model is the definition, not the data.** Submissions and records live in workspaces. To find "the records for Marketing," go to the workspace records page, not the governance model.
* **Edits go live only when you publish.** Day-to-day edits are saved as a draft and tolerate work in progress. Publishing a revision is the step that makes the structure live for new submissions. See [Publish a revision](/guides/publish-revision).
* **Import runs stricter checks than everyday edits.** Everyday editing lets you save partial drafts; import validates the whole model at once. An import error names the exact piece that breaks a rule.
## Related
The ordered field groupings a governance model exposes as forms.
The reusable field definitions a model contains.
The option lists that feed dropdown fields.
How edits to a model become live for submissions.