Changelog

When a question turns on something the context does not settle, such as what makes a customer active, Cassis asks a short question, with choices when it has them, and waits. Answer it and the query runs. The question reaches you wherever you asked: in the web app, in your AI assistant, or in a Slack thread, where the choices are buttons.

Over MCP, the response carries the ready-to-send reply, so an agent continues the same chat with your answer. See ask_question.

Shortly after a chat with Cassis goes quiet, Cassis reviews the questions it was asked, the answers it returned and the feedback they got, and writes up where the answers held, where they did not, and the excerpts that show it. The Conversations page marks each chat Needs attention or Analyzed, so the ones worth a look stand out; anyone who can open a chat can read its review.

From a checkout, cassis chats list --review needs-attention lists the chats that need a look and cassis chats show prints one with its review. See Chats commands.

👍 or 👎 under a Slack answer opens the same short form as the web app: what was right, what was wrong. The feedback joins the chat, where its review and the issue queue read it.

On the Analytics page, thumbs up and down count every feedback given in the period, from the web app, an MCP agent or Slack, so the totals include feedback from all three.

A question runs straight away, or Cassis asks the one thing it needs to know first. There is no plan to approve and no Run plan button; chats from before keep their plan, read-only.

Over MCP, an agent continues a chat by replying to Cassis’s question with its clarification_id. If your integration sends execute_pending_plan or reads needs_execution or plan from ask_question, remove them: the tool does not use them. See ask_question.

Run your eval suite three or five times in one go from New run on the Evals page. Cassis compares the attempts of each case: passed every time, failed every time, or flipped, and for each flip whether the agent wrote different SQL or the judge ruled differently on the same SQL. A repeat run opens no issue in Review and is never the run shown before publishing.

Every new case gets a check of its own: Cassis runs it three times in the background, and the Test Cases tab flags it as flaky or failing before anyone relies on it. With cassis-cli 3.4, cassis eval run --repeat and cassis eval compare work the same way from a checkout or CI. See Build and run evals.

Where a context table or column has no description, Cassis reads the warehouse’s own comment on it, including dbt descriptions written with persist_docs. The documentation your data team already maintains reaches answers without being copied into the context. A description you write always wins.

A published version keeps the comments it was published with, so a corrected comment reaches answers at the next publish. cassis context check counts a column its warehouse comment covers as described. With cassis-cli 3.3, run cassis context fmt to refresh the guide in cassis/AGENTS.md.

Run cassis dbt check on a dbt pull request and Cassis lists the context tables, columns, joins, and metrics the change puts in doubt, each with why it matters and the context change to make. A removed model names the joins and metrics that use it. A column that disappears while another appears is flagged as likely renamed. The check never fails your CI.

After the merge, cassis dbt push files each finding as an issue. It waits in Review as a Possible dbt mismatch, with the dbt change, its commit, and its pull request attached.

See dbt changes and the CI setup. Both commands need cassis-cli 3.3.

A failed eval case names where the generated SQL first departs from the gold SQL: the table, a join, a filter, the aggregation, the time window, or the grain. Every result also compares the tables the gold SQL reads with the tables the plan used, so a case that passed by a different path is visible at a glance.

A case’s page shows how it behaves across runs, grouped by context version, model, and app version, and flags verdicts that flip on an unchanged configuration. cassis eval history prints the same, and cassis context check warns when a pull request removes a table an eval case reads. See Build and run evals.

Every issue in Review shows its reach: how many chat answers used its context tables in the last 30 days. Next to it, its evidence says how the issue was found: a dbt change, an AI review, user feedback, a failed eval, or the review of chats with Cassis.

Issues of equal impact are ordered by reach, so the gap your users hit most comes first. Rank an issue P1 to P3 and it moves ahead of the rest. cassis issues list and the MCP issue tools use the same order. See Review detected issues.

A column can now carry the full list of values it stores, each with an optional meaning: order statuses, payment types, department codes. Open a column on the table page and fill in Enum values, or add enum_values to the table’s file. Cassis filters with those exact values, so “home and garden sales” becomes DEPARTMENT = 'home_garden'. The context assistant moves value lists it finds in column descriptions into the new field, and cassis context check warns when a value doesn’t fit its column’s type.

See enum values for the file format. With cassis-cli 3.2, run cassis context fmt to refresh the guide in cassis/AGENTS.md.

If your company routes agents through its own MCP gateway, an admin can now create a gateway key for it on the API keys page. The gateway names the person behind each question, and Cassis answers as that person: the question lands in their own chat history, and their role and account status apply. Suspended people and people awaiting approval are refused, with a message the gateway can show them.

Colleagues who have never opened Cassis are added as Explorers on their first question, as long as your organization has claimed their email domain. A gateway key is always scoped to one project and works on the MCP only. See Gateway delegation for the headers your gateway sends.

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, requires a reason. 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.

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.

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. Needs cassis-cli 2.0.

Plans take over from the Data source review queue: use cassis schema plan where you used cassis source-changes, and cassis status for the waiting plan. Over MCP, drop list_source_changes, get_source_change and pending_source_changes from your agent.

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.

A DDL upload removes the columns that are gone from your source, as a warehouse schema sync does, so the ontology only offers the assistant columns that exist. 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.

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.

A DDL upload covers only the schemas present in the file, so you can export and upload one schema at a time and the others stay as they are. This holds for every client, including CLI versions older than 1.6.

If a pipeline of yours signals a dropped schema by leaving it out of the file, mark the file as complete: pass --complete on cassis schema push, or answer that the file is complete in the app.

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 waits for the detection run and exits 0 only once the DDL parsed and the schema applied; otherwise it fails with the parser’s message, so a pipeline never reports a schema that did not land. The command always waits, so drop --no-wait from your pipelines.

A DDL upload names the offending line and the likely cause, such as an export that mangled quote characters. A CREATE TABLE statement the parser cannot read fails the whole upload by name, so a pipeline sees the problem before any table goes missing from the imported schema.

Any member creates their own API key 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 see and can revoke every key in the organization.

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. Warnings never fail the check, so validation stays the merge gate.

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 answered from the published ontology version, never from unpublished work in progress, the same as in the web app. To try unpublished changes, ask on a branch.

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 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).

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.

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.

cassis ontology pull and cassis ontology fmt write the Cassis modeling guide into the checkout as cassis/AGENTS.md, so a coding agent working in the repository follows it with no per-agent setup. Commit it with the ontology files, and let the CLI keep it current.

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.

Editing goes through the repository and the CLI, which take over from the MCP tools edit_ontology, validate_ontology_tree, test_ontology_tree, get_unpublished_changes and get_ontology: remove them from your agent’s configuration.

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 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.

Source-change detection recognizes a renamed 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.

Pushing cassis/ files straight to the repository’s default branch syncs them into Cassis, reported as a check on the pushed commit, the same as a merged pull request.

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.

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.

Publishing from the main branch commits your changes straight to the connected GitHub repository, so a change on main lands in one step. When a change needs review first, work on a branch: publishing a branch opens a pull request.

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

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.

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, and each branch maps to its own branch on the remote, so several can be in review at once. Merging syncs back automatically.

Fixing an issue in chat proposes a single targeted edit for that issue. Adjacent improvements it spots are raised in the conversation, for you to decide on.

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.

The ontology editor is organized 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.

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.

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.

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

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.