> ## 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.
# Publish a Revision and Manage Governance Model Versions
> Freeze your governance model into a numbered revision so structure changes reach submitters, and read the revision history.
You edit a governance model freely: add a field, restructure a taxonomy, change which picklists link where. None of those edits reach the people filling in submissions until an admin **publishes**. Publishing freezes the model's current structure into a numbered, read-only **revision**, a snapshot at that moment. The submission builder always renders from a published revision, never from the live model you are editing.
A revision is how your structure goes live. Until you publish, your changes are drafts that only you and other editors see. Publishing snapshots the structure (fields, taxonomies, links, prefixes, suffixes, required and hidden settings) into the next revision number, and submitters start using it for new submissions.
## Draft versus published
There are two layers to a governance model:
* **The live model** you edit in the builder. Edits take effect immediately for editors but reach no submitters.
* **The published revision** the submission builder reads from. This only changes when you publish.
The gap between them is your "unpublished changes." Everything you have edited since the last publish sits in the draft layer until you publish again.
A governance model must be published at least once before anyone can submit against it. Until the first publish exists, opening the submission builder reports that the model has no published revision. Publish revision 1 first.
## The unpublished-changes indicators
Terminus Hub revalidates your model continuously as you edit (debounced shortly after each change), so the publish indicators stay current without you doing anything.
* **Sidebar dot.** A dot appears next to the **Revisions** nav item whenever you have unpublished changes. It is amber when the model is valid and ready to publish, and red when there are validation issues blocking the publish.
* **Header status badge.** The model header shows one of:
* **Up to date** (green): no unpublished changes, the live model matches the latest revision.
* **Ready to publish** (amber): you have valid unpublished changes.
* **Publish disabled: N issues** (red): unpublished changes exist but validation is failing. Click it to open the issue list.
* **Publish card.** On the **Revisions** page, a publish card appears only when you have unpublished changes. It is where you actually publish.
## View revision history
From inside your governance model, open the **Revisions** tab. You will see every published revision, newest first.
Each row shows:
| Column | Description |
| ------------------- | ---------------------------------------------------------------- |
| **Revision number** | Auto-incremented, starting at 1 |
| **Published at** | Date and time the revision was published |
| **Published by** | The user who published it, when that can be determined |
| **Notes** | The optional note entered at publish time |
| **Status** | A **Live** badge marks the current revision (the highest number) |
Click a revision row to view the structure exactly as it was at that version: fields, taxonomies, and how picklists were linked. This view is read-only. You cannot edit a past revision.
The newest revision is always the live one. There is no separate "activate" step: publishing makes the new revision live immediately.
## Publish a revision
Prerequisites: you need account-admin permission to publish. The publish button is hidden if you cannot publish, and the model must have unpublished changes (otherwise there is nothing to publish).
Make your edits, then go to the **Revisions** page. The publish card is there whenever you have unpublished changes. If validation is failing, the card lists the blocking issues instead of a publish button (see below).
In the publish dialog, the **Notes (optional)** field answers "What changed?" The note is stored with the revision and shown in the history. A one-line summary makes the history far more useful when you audit it later.
Make notes a habit. Something like "Added Campaign Owner field to the Campaigns taxonomy" tells the next person reading the history exactly what each revision did.
Click **Publish**. On success you see "Published as revision N," the new row appears with a **Live** badge, and the publish card disappears. On a brand-new model the card notes that this will be revision 1.
## Why a publish can be blocked
Publishing runs a validation check, and a failing model cannot be published. Two situations stop a publish:
* **Validation issues.** If the structure has errors (for example a `dropdown` field with no picklist linked, or a `concatenation` field referencing a field that no longer exists), the publish card turns into a red "Publishing blocked" card listing each issue, with no publish button. Fix the highlighted issues, then publish. See [Governance models](/reference/governance-models) for what the model needs to be valid.
* **No changes.** If you open the dialog and try to publish when nothing differs from the latest revision, publishing fails with "No changes since revision N." This includes editing something and then changing it back to exactly how it was: the snapshot is compared by value, so an edit that nets to nothing is treated as no change.
Publishing checks the current structure against the latest revision. If you cannot publish and the card says there are no changes, your edits may only have touched picklist options, which are not part of the snapshot (see below).
## What is and is not in the snapshot
A revision freezes the model's **structure**: its fields and their settings, its taxonomies, how picklists link to fields, and the prefixes, suffixes, required, and hidden settings.
**Picklist options are intentionally not in the snapshot.** Options are treated as content, not structure. The practical consequences:
* Editing an option's label, soft-deleting an option, or accepting a user-proposed addition does **not** require republishing. Those changes take effect for submitters right away.
* The submission form loads picklist options live, so submitters always see the current set of options regardless of which revision they are on.
* Because options are excluded, editing only picklist options leaves your model showing **Up to date** with nothing to publish.
So "publish" governs structure. Option values inside picklists are managed separately and do not flow through revisions.
## What happens after a publish
Once a new revision is live:
* New submissions render from the new structure.
* Submissions and records that were already created are pinned to the revision they were started against, and that pin does not change. In-progress work keeps the structure it began with rather than shifting under the submitter.
* The **Revisions** list shows the new revision with a **Live** badge, and the previous revision stays in history for reference.
## Revision rules and limits
Revisions are permanent and read-only. There is no edit, restore, roll back, or delete for a published revision. To "go back," recreate the structure you want in the live model and publish it as a new revision.
There is no hard cap on how many revisions you can publish. If you publish often, consider batching related structure changes into one revision so the history stays readable.
If two people publish at the same time, Terminus Hub serializes the publishes so revision numbers never collide. If your editor was behind, you may be told another revision was just published; reload the editor to pick up the latest, then publish again.
## Related
* [Governance models](/reference/governance-models): the structure that a revision snapshots, and what makes it valid to publish.