Every change to the Context Layer goes through a versioned release process. You never edit the live catalog directly — instead, changes are staged in a draft, tested, and deployed as a new version. This gives your team a clear history of what changed, when, and by whom.Documentation Index
Fetch the complete documentation index at: https://docs.clarityq.ai/llms.txt
Use this file to discover all available pages before exploring further.
How Versions Work
The Context Layer always has one published version — the version everyone sees and that the agent uses for Ask Anything answers. When you start editing in the Builder, a draft is created alongside it. The draft is private to you until you deploy it. Each time you deploy, the version number increments and your draft becomes the new published version. The previous version isn’t deleted — it stays in the version history permanently.What Gets Versioned
A single version captures the state of all Context Layer components managed through the Builder:- Entities and their dimensions
- Metrics
- Segments
- Skills
- Product memory entries
What’s Not Versioned
Some parts of the Context Layer live outside the draft-and-deploy cycle:- Table Catalog — Tables and columns are discovered directly from your data warehouse and updated by daily discovery jobs. Changes take effect immediately.
- Event Catalog — Events and parameters are synced from your data source. Like the Table Catalog, changes are live as soon as they’re made.
- Features — Features promoted from the Event Catalog are managed separately and not part of the versioned draft.
- Personal memory — Personal memory entries are saved and applied immediately in your conversations, without going through a deploy.
The Change Set
Every deployed version includes an auto-generated description of what changed. The change set records every component that was:- Created — New components added in this version
- Modified — Existing components that were updated
- Deleted — Components that were removed
Version History
To view the version history, click the All versions link at the top of the Semantic Catalog, Skills, or Product Memory screens. The page lists every deployed version with its:- Version number
- Timestamp
- Author (who deployed it)
- Auto-generated description of the changes
Actions on Each Version
- View Changes — See the detailed list of components created, modified, or deleted in that specific version. Available on every version.
- Compare to Current — See the cumulative changes between that version and the current published version. Useful for understanding how the catalog has evolved over time. Available on any version that isn’t the current one.
- Rollback — Immediately restores the catalog to that version’s state and publishes it as a new version. This is not a draft — the rollback takes effect right away. Rolling back doesn’t erase the versions in between — the history is append-only, so you always have a complete audit trail. Admins can roll back to any version. Contributors can only roll back if every version between the current one and the target was deployed by them — they cannot roll back past another user’s deploy.
Common Scenarios
”What changed in the last deploy?”
Open version history and click View Changes on the latest version. You’ll see exactly what was created, modified, or deleted.”Something broke — what changed since the last known good version?”
Find the version you trust in the history and click Compare to Current. This shows every cumulative change between that version and what’s live now.”I need to undo a bad deploy”
Find the version you want to restore and click Rollback. The catalog is immediately restored to that version’s state and published as a new version. The bad version stays in the history — nothing is lost.Rollback publishes a new version on top of the current one. It doesn’t delete or rewrite history. Your version timeline always moves forward.