Publish and restore versions

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.

Domains~1 modified

→ racing modified Context (markdown)

— 12 unchanged lines — A **podium** is a strong result near the front of the field. - - A podium is positions 1 to 3, sprint races included. + - A podium is finishing position 1, 2, or 3 in a race. + - Sprint races are excluded unless the question says otherwise. Use these definitions exactly; do not re-derive them.

Confirm what is live

Version	Date	Label	Published by	Commit
v2 Current	Jun 6, 2026	Define podium as positions 1 to 3	[email protected]	a1b2c3d
v1	Jun 2, 2026	v1 baseline	[email protected]	3c2b1a0

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?”