# Publish and restore versions

Only the published ontology affects answers. Every publish creates an immutable version that can be inspected and restored.

## Publish through the chosen workflow

- **GitHub App** Merge to the default branch. The App imports the tree and records the commit on the new version.

- **Other git provider** The default-branch CI job runs `cassis ontology upload`.

- **App-managed** Review **Pending changes**, then use **Publish**.

Each path replaces the complete ontology, which is why a project should have one place where edits are made.

Publishing runs in the background. It does not hold up the app for anyone else, closing the tab does not cancel it, and the page reports the outcome when it finishes, so a very large ontology can take minutes and still land. Imports, branch merges, warehouse syncs, restoring a version, and discarding a branch’s changes all behave the same way.

## Confirm what is live

The Versions page shows the label, time, publisher, and git commit when one exists. After a GitHub App import, `cassis status --watch` can wait for the published commit. After a CLI upload, check the job and use `cassis status`. An MCP agent can use `get_project_status`.

Do not resolve the originating issue until this version contains the fix.

## Restore an earlier version

Choose the last known-good version in the Versions page and restore it. Restoring publishes a new version with that earlier ontology; it does not erase the history in between.

An unmerged pull request, an app branch, or pending Assistant changes affect no answers. “Did the change land?” always means “is it in the published version?”