Changelog

Tell your MCP agent whether a conversation with Cassis helped, and why. The agent records an up or down rating with your reason through submit_feedback, without asking another question or starting an answer. Rate at any point, as often as you like, even while an answer is running. Cassis also sees the feedback when it answers later questions in the same chat.

Each rating and its reason show in the chat in the web app, so whoever maintains your context reads what worked and what did not. In the web app, any rating, up or down, can carry a note. Only the person who started a chat can rate it.

Cassis is a context layer, and the product now says so. The Ontology page is now Context, at /context, and existing links still land there. Published, unpublished and draft context, the context assistant, and Add to context on the Schema page use the same word across the app, Slack and agent answers. MCP tool names and parameters stay the same.

In a checkout, cassis context runs check, pull, upload, fmt and test with the same options and exit codes. cassis ontology keeps working, so existing scripts and CI need no change. Run cassis context fmt to refresh the context design guide in cassis/AGENTS.md. Needs cassis-cli 3.1.

When you create an API key, pick the project it is for. The key acts with your permissions on that project only, and CI jobs and agents using it are refused every other project. A pipeline’s key reaches the one project it publishes, not your whole organization.

An agent connected over MCP with a scoped key goes straight to work: every tool runs on the key’s project, with no project to look up or pass. A key set to All projects reaches every project you can.

cassis ontology upload and cassis schema push record the git commit they upload from on the published version. cassis status then shows whether your checkout matches what is live, and cassis status --watch waits for a pipeline publish the way it waits for a GitHub App import.

Both commands run from a git checkout with the ontology files committed, and list the files that differ from HEAD otherwise. Your CI image needs git: the python:3.12-slim image does not have it. Needs cassis-cli 3.0.

Organization admins now have an Analytics page in the sidebar. Pick a project and a period to see adoption (questions per day, which surface they came from, the most active people), answer quality (outcomes and ratings), spend per day and what it bought, and the domains and tables your team relies on most.

A last section estimates the time Cassis frees up for analysts: set the minutes an answer saves and an hourly rate, and it sets that against your spend for the period.

Cassis can call Claude through your organization’s own AWS Bedrock or Google Vertex AI account, so inference runs on your capacity, under your quota and on your cloud bill. Cassis never holds a key: you create a role (Bedrock) or a workload identity pool (Vertex) that trusts Cassis for your organization only, and it mints short-lived credentials per call.

Organization > LLM provider validates your setup against every model Cassis uses before any traffic moves, and one switch turns routing off. If your account stops answering, Cassis says so rather than serving the request elsewhere. Bedrock accounts must be in a European region. Ask your Cassis contact to enable it.

Press Up in either chat composer to recall the previous message, then keep pressing to walk farther back. Press Down to move forward again. Once you pass the newest message, Cassis restores the draft you were writing.

Follow-up questions can now explore newly relevant ontology domains before deciding that a business term is undefined. In Review, conversation analysis stays visibly in “Drafting fixes…” until its proposed fixes are ready.

Cassis now uses a connected repository’s actual default branch when it reads or publishes the ontology and when it opens a pull request. Repositories whose default branch is not main no longer risk a stray branch or a pull request based on the wrong tree.

Concurrent push notifications are serialized before Cassis chooses the commit to publish. A burst of pushes therefore leaves the newest repository state published instead of allowing a slower job for an older commit to win the race.

Review issues now keep a history of status changes and an explicit reason when dismissed. Applied fixes stay open until their ontology change is published, and manual resolution asks you to confirm publication. If the same issue appears against a later published version, Cassis reopens it; a dismissed issue stays dismissed but shows that new evidence arrived.

The CLI lists open issues by default, adds --status all, requires dismiss --reason, and requires resolve --published in non-interactive use. MCP status updates use the same dismissal reasons and publication confirmation.

Cassis now imports ordinary and materialized views alongside tables from PostgreSQL, Snowflake, BigQuery, and DDL files. Source comments, view SQL, keys, constraints, defaults, generated expressions, object kinds, and catalog information remain available for modeling instead of being flattened away.

Schema plans also show object-level extraction diagnostics and the objects Cassis could read. If extraction is incomplete, the plan cannot be applied or pushed. This makes a partial or unsupported DDL export visible before it can change the tracked schema or ontology.

Write Resolves <issue id> in the description of the pull request that fixes a Review issue, and Cassis resolves the issue when the PR merges, on any branch of the connected repository. Closes and Fixes work too, and the id’s first 13 characters are enough. Ids come from cassis issues list or the MCP list_issues tool, and cassis issues show prints the exact line to paste.

Pull requests Cassis opens from a fix branch carry the mentions already. Each closed issue records how it was closed and the pull request it came through.

The Review queue opens as a list of ontology domains, each with its open-issue count, how often users hit those gaps, and how many fixes are ready. Pick a domain and work through its issues in a table: tick the ones that belong together, then “Fix in chat” to open a single ontology chat seeded with all of them, or resolve and dismiss them in bulk. The domain you opened is part of the URL, so it survives a reload and can be shared.

cassis issues list shows each issue’s domain and takes --domain to triage one from the terminal.

An ontology chat bound to a branch applies each change as it goes and shows it in the conversation as a diff the moment it lands, with the branch as the safety net. A panel beside the chat holds two tabs: the issues the chat was opened from, with a “Resolve issues” action, and every unpublished change on the branch, each with its diff and a one-click revert.

Ship them from there with “Merge into main” or “Open merge PR”, with the same label suggestion and pre-merge eval check as the Versions page. Merging marks the issues the chat set out to fix as resolved.

The Schema page lists the current schema of your warehouse, or of the DDL you uploaded, on its own: every table with its columns as introspected, filterable by whether it is in the ontology. Adopt a table into the ontology from there by picking its domain, or hand it to the assistant to model.

“Remove from ontology” sends a table back the other way: its curation and joins leave the ontology and nothing is touched in your warehouse, so it can be adopted again later. The Explorer stays what it always was, the curated ontology.

Answers show the domains Cassis consulted alongside the tables and metrics it queried. Click a domain in the app to read its business context, including the definitions and rules that can help explain an answer.

The list follows the order Cassis explored your ontology. It also appears when Cassis needs a definition before answering, so you can see where it looked. MCP responses carry the same domain paths for your analytics agent to inspect. A listed domain means Cassis read it, not that every rule in it shaped the answer.

cassis schema plan previews a schema update terraform-style: the source diff, the ontology edits it implies, and warnings, with exit 1 on a DDL that does not parse or looks truncated. cassis schema apply writes the resulting ontology files into the checkout for git diff. cassis schema push applies the schema and uploads the local ontology in one go, --yes for CI. On a warehouse-connected project, --warehouse plans from the live source instead of a file. Needs cassis-cli 2.0.

This replaces the Data source review queue. cassis source-changes is gone, cassis status reports the waiting plan instead, and the MCP list_source_changes and get_source_change tools are removed along with pending_source_changes on get_project_status.

Upload a DDL file or sync from your warehouse on the Schema page and Cassis shows a plan: the schema diff, and every ontology change it implies, down to the joins, metrics and virtual tables a dropped table takes with it. Nothing is written until you apply, and applying does exactly what the plan lists, in one step.

Every night Cassis also plans a warehouse sync for each connected project. When the source moved, the Schema page shows “A plan is waiting” until someone reviews it. A plan whose ontology or schema has moved on in the meantime is marked out of date, so you plan again rather than apply a stale one.

Ask us to register your company’s email domain, and anyone who signs up with an address on it joins your organization instead of a separate workspace. They arrive as Pending approval on Organization → Users, where an admin gives them a role (read-only by default) or turns them away. Every admin is emailed when a request arrives, and the colleague hears back once an admin approves them.

When a plan offers more than one way to read a term, say revenue as GMV or as delivered orders, your choice sticks. Pick an option, or run the plan as proposed, and Cassis carries that reading through the rest of the conversation. Follow-ups build on it, and the plan that ran stays the record of what was used.

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.