Changelog

A DDL upload now removes columns that are gone from your source, the way a warehouse schema sync already did — so projects that upload DDL stop carrying columns the source no longer has, and the assistant stops being offered them. Only bare columns go quietly: anything a join, metric or virtual table uses, or that you have described, still waits in Review. An upload that keeps every table but drops a quarter or more of their columns raises the same “this file looks incomplete” warning a mass table removal does.

A rejected upload now names its reason: a DDL file cut off part-way through says so.

cassis issues analyze starts the same “Analyze conversations” pass as the Review page button, from a checkout or a CI job, and waits for the result — so an agent or a pipeline can refresh the project’s issues right after a batch of questions instead of waiting for the nightly pass. Nothing new to analyze is a green no-op. Needs cassis-cli 1.7. cassis eval run --json and cassis schema push --json now keep stdout to the JSON record, so piping them into jq works.

Until now every DDL upload was treated as your project’s complete source schema, so a one-schema export marked every table in all your other schemas as removed. An upload now covers only the schemas present in the file.

This applies to every client, including CLI versions older than 1.6 that cannot say otherwise. If a pipeline of yours signaled a dropped schema by leaving it out of the file, pass --complete on cassis schema push, or answer that the file is complete in the app, to keep detecting whole-schema drops.

The Data source review queue is now readable without opening the app. cassis source-changes list prints the pending queue with breaking items flagged; cassis source-changes show prints one change’s impact references and its suggested edit; cassis status reports how many items are waiting and how many of those are breaking. Needs cassis-cli 1.6.

Agents get the same view over MCP: list_source_changes and get_source_change, with the pending count on get_project_status.

Approving stays in the app. An agent can see the drift and propose the edit; what your definitions become is your call.

cassis issues brings the triage queue to the checkout: issues list (filterable by status, impact, and cause), issues show for an issue’s diagnosis, suggested action, and occurrences, issues evidence for what the agent actually saw, and issues resolve / dismiss / reopen once you have acted on it.

cassis schema push now always waits for the detection run and exits 0 only when the run completed — meaning the DDL parsed and the schema was applied. The --no-wait flag is gone: large files no longer time out the upload request, and a parse error surfaces as a failed run with the parser’s message instead of a push that reported success for a schema that never parsed.

cassis ontology check and the pull request check are roughly 4x faster on large ontologies.

DDL uploads now name the offending line and the likely cause (an export that mangled quote characters, for example) instead of returning an internal error. A CREATE TABLE statement the parser cannot read fails the upload by name, rather than being silently dropped from the imported schema.

The CLI also waits for the server on a slow check, fmt, or upload instead of giving up first.

Issuing an API key no longer needs an org admin. Any member creates their own from API keys in the account menu, and a key acts as the person who created it, so it grants nothing they do not already have. Org admins still see and can revoke every key in the organization.

On projects built from a DDL file, Settings then Database now links straight to the Update from DDL uploader, instead of dead-ending on a message about having no live connection.

check now prints advisory quality warnings beside validation: tables assigned to no domain, joins or metrics pointing at unknown tables or columns, missing table and column descriptions. These were previously visible only through ontology test, which costs a full agent run per question. Warnings never fail the check, so validation stays the merge gate.

The ontology pull request check is also always posted, however many problems it finds. Pull requests with more than 50 findings used to get no check at all.

cassis projects list shows every project your API key can reach, with its id, published version, and SQL dialect, so you stop copying ids out of webapp URLs.

cassis status reports the published version, pending unpublished changes, and whether your checkout matches what is live. --watch waits for a merge’s publish to land instead of you watching the CI tab.

cassis verify runs the whole pre-merge gate in one command (ontology fmt --check, ontology check, eval run), stopping at the first failure.

Questions asked from Slack and from MCP clients are now always answered from the published ontology version, never from unpublished work in progress, matching what the web app does.

Org admins can restrict who edits which part of the ontology. A project sets its default to open or restricted, then grants members write access on a domain and everything beneath it, with exceptions to carve out subdomains. Everyone keeps full read access, and admins always keep write.

User management, invites, role changes, and domain grants now live on a single Organization > Users page.

The CLI now ships under the Apache License 2.0. Nothing changes about how you install it (pip install cassis-cli).

The modeling guide Cassis keeps in your repository also learned to run an extension pass, for adding a new schema or business area to an existing ontology. It agrees the scope and proposes the domain tree changes for you to approve before writing any content, instead of filling in tables first and reorganizing afterwards. The guide refreshes itself on your next ontology pull or fmt.

cassis eval list-cases and cassis eval delete-case let agents and CI jobs maintain the eval suite, pruning a case whose gold SQL encodes a definition the ontology has since changed.

In a git-synced repository every domain is now the README.md of its folder, with a small YAML frontmatter block for its name and description and the domain’s context as readable Markdown that renders on GitHub. Tables, joins, and metrics stay YAML.

Existing repositories keep working untouched. Convert whenever you like with cassis ontology fmt, on a current CLI.

CLI commands also default --project to the id recorded in the checkout, so once a repo is pulled you stop passing it.

An agent connected over MCP can now read the issue queue with its full evidence (the source conversations’ SQL, results, ratings, and judge verdicts), fix the root cause in the ontology repository, and mark issues resolved or dismissed.

It can also verify a change end to end before proposing it: cassis eval run for the project’s suite, and the new cassis ontology test to probe individual questions.

ontology pull and ontology fmt drop the Cassis modeling guide into the checkout as cassis/AGENTS.md, so a coding agent working in the repository follows Cassis doctrine with no per-agent setup.

On a GitHub-synced ontology, an agent edits the files in your repository and opens a pull request. It can validate the change and test-run real questions against it through Cassis before proposing anything.

cassis ontology fmt rewrites the ontology files in canonical form, like a code formatter, so any field Cassis would drop shows up in the diff before you commit. --check mode fails a CI job instead of rewriting.

The repository and CLI workflow replaces the discontinued MCP ontology tools: edit_ontology, validate_ontology_tree, test_ontology_tree, get_unpublished_changes, and get_ontology.

Validation now reports every problem in one run, YAML errors per file plus round-trip and semantic findings together, instead of one error per attempt.

cassis eval run scores your local ontology files, an existing branch, or the unpublished ontology, and prints per-question results, so you can test a change on your branch before pushing anything.

cassis ontology pull syncs a project’s ontology into your checkout. Useful for starting from the current state, or for working from a repository Cassis does not sync itself.

The data-source review feed is now grouped into foldable sections by kind of change (removed from the source, renamed, retyped, new in the source), breaking changes first.

The CLI can upload an ontology to a project from any CI pipeline, replacing the project’s ontology with the repository’s files and publishing them immediately as a new version. Opt out of the publish with --no-publish.

The GitHub sync path is configurable per project. Ontology files export under cassis/ by default, instead of a fixed cassis/ontology/.

The app also works on a phone now, showing one panel at a time on the Explorer and Schema pages.

Source-change detection now recognizes a renamed table instead of reporting a removal plus a new table. One review card renames it in place, keeping descriptions, synonyms, joins, and metrics, and rewrites the SQL that referenced the old name.

Rewrites are scope-aware: they only touch references provably belonging to the renamed table, so a same-named column on another table is never rewritten. Anything ambiguous is left untouched and disclosed.

Projects with no live warehouse connection can now create a project and update their schema from a DDL file, end to end.

The Review tab makes priority legible: severity is the only colored badge on a card, each issue shows how often it recurred, and the queue splits into “Needs attention” and “Held for more signal”, with held issues saying why they wait.

Pushing cassis/ files straight to the repository’s default branch now syncs them into Cassis, reported as a check on the pushed commit. Previously only merged pull requests triggered a sync.

Tables not yet in the ontology carry an amber unplaced badge, and an All / Unplaced / Virtual filter narrows the Schema tab to them. Schema search now matches column names, descriptions, and synonyms, so you can type a column name to find its table.

Ontology detail views are fully cross-linked: a metric’s table opens that table, a table’s metrics open the metric, and a join row jumps to the table on the other end. Column lists are one line per column, expandable to edit, with a filter box on wide tables.

Organization admins can change a member’s role between admin, editor, and explorer, and suspend or reactivate users, from the Organization > Users page.

Publishing ontology changes from the main branch now commits directly to GitHub instead of opening a pull request. Branch publishes still create pull requests as before.

The Explorer role lets someone chat with your data and read the ontology without being able to change it, run evals, or touch admin settings. Invite people as explorers from organization settings.

An organization settings page for issuing and revoking long-lived keys, so agent frameworks and scheduled jobs can reach Cassis without a browser sign-in.

A new Source changes view flags renamed, removed, and retyped columns, and added or removed tables, showing which parts of your ontology each one affects so you can review and apply the change.

When a question leans on a business term the ontology does not define, such as “active” or “lapsed”, Cassis now states the assumption it is making and asks you to confirm or define it instead of quietly picking one. Where it has made a judgment call, the query plan lets you switch to a different interpretation before running.

Create named working copies of the ontology, edit them in parallel without touching what is live, test them, and merge when ready.

With a repository connected, Publish opens or updates a pull request for review instead of applying the change immediately, and each branch maps to its own branch on the remote, so several can be in review at once. Merging syncs back automatically. Git sync also learned to target a folder inside the repository rather than always the root.

Fixing an issue in chat now proposes a single targeted edit rather than a sweeping rewrite, with no unrequested extra metrics or restructuring. Adjacent improvements it spots are raised in the conversation instead of being applied.

Schema sync now removes ontology tables whose physical table is gone from the warehouse, rather than leaving stale entries an agent could still reference.

Open a test case to see its full run history and compare any past result side by side with the gold SQL. Questions and gold SQL are editable in place, from the list or the detail page.

Install Cassis into Slack from organization settings in one click, then ask questions by mentioning the bot in the channels your team already works in. Answers come back in the thread with the SQL attached.

Chats and failing evals that hit the same gap are now grouped into one prioritized refinement, sorted by impact, for the data team to review. This is the loop that turns real use into a sharper ontology, and it is where today’s issue queue came from.

The ontology editor was rebuilt around your schema: browse domains as a tree with editable context, and curate the tables and columns underneath them with descriptions, synonyms, units, and grain. That is the shape the Explorer still has today.

You can also start a project from a .sql file of CREATE TABLE statements instead of a live connection. Cassis parses it to bootstrap an ontology, which is the basis of what is now generate-SQL-only mode.

Publish a version, browse the history, compare two versions, and restore an earlier one. Every published version is immutable, which is what lets production answers come from a known state.

Once Cassis builds an ontology it reviews its own work, flagging schema coverage gaps, ambiguous labels, and missing context, grouped by category with one-click fixes.

Follow-up questions now take your earlier feedback into account: rate an answer and the next turn adjusts accordingly.

When Cassis cannot execute SQL, eval runs no longer run the gold query. A judge compares it against the generated SQL to decide pass or fail, and judged runs are marked as such in the run list.

Eval runs also read the same context the chat does, including joins with their SQL and cardinality, so a verdict reflects what the agent actually had to work with.

An agent that explores the ontology, diagnoses what is missing, and proposes changes. Nothing it proposes lands without approval.

The first production deployment. Ask questions in plain language against Snowflake, BigQuery, or PostgreSQL, and get an answer with the SQL that produced it.

At launch: an ontology bootstrapped from your warehouse schema and your dbt project, an evaluation suite with test cases and versioned ontologies to score changes against, and thumbs up or down on every answer.