The ontology is the layer of business meaning Cassis grounds every answer in. This page is for the data team that keeps it sharp. The ontology is physical-first: business meaning sits on your real schema, with no separate object layer to keep in sync.
You browse and edit it across the Explorer and Metrics tabs, or by chatting with the Assistant. More views keep it healthy: the Review queue, Versions and branches, and Evals. The examples below use a Formula 1 project.
Access is limited to selected design partners today. Leave your email at getcassis.com to be notified when it opens up.
Explorer
A domain tree on the left, the selected object on the right. Three kinds of object live in the tree:
Domains
Each holds a markdown context document. The root domain is the agent's global context, with no hidden prompt.
Tables
Mapped to your schema: physical, or virtual when defined by SQL. Joins are not separate objects; you manage them on the table they connect.
Metrics
Named, governed expressions: one definition, used exactly, never re-derived.
Schema and sync
Tables introspected but not yet placed in a domain live in the Schema section, not under the root domain, matching what the assistant sees. Re-sync any time to pick up new columns and drop tables whose physical table no longer exists.
Explorer13
Metrics6
▾Formula 1 data
▾racing
Race weekends
public.races
public.results
public.lap_times
▾reference
Drivers and teams
public.drivers
public.circuits
▸standings
ΣPodium finishes
ΣWins
public.results
~26,500 rows
Domainracing
DescriptionOne row per driver per race: finishing position, points, status.
Synonymsresult, finish
Grainresult_id
Joins (2)
→public.racesN:1manual
results.race_id = races.race_id
Each result belongs to one race.
→public.driversN:1manual
results.driver_id = drivers.driver_id
Metrics (1)
Podium finishes
COUNT(*) WHERE position <= 3
Columns (8)
result_idnumberintrospectedPK
Unique identifier for the result row
positionnumberintrospected
Finishing position. Null for a DNF.
+ 6 more
Selecting a table shows its joins (each with a direction and cardinality), the metrics built on it, and every column. A domain and a metric open the same way, picked from the tree on the left:
A domain is a context document. The root domain is the agent's global context, with no hidden prompt.
Explorer13
Metrics6
▾Formula 1 data
▾racing
Race weekends
public.races
public.results
public.lap_times
▾reference
Drivers and teams
public.drivers
public.circuits
▸standings
ΣPodium finishes
ΣWins
Formula 1 data root
Global context for the Formula 1 dataset.
Business context
How the data is organized
Race results since 1950: races, results, qualifying, lap times, plus driver and constructor standings. Two domains: racing (what happened on track) and reference (drivers, teams, circuits).
Rules that apply to every question
A win is finishing position 1. A podium is positions 1 to 3.
Sprint races are excluded unless the question says otherwise.
A DNF has a null position; exclude it from position-based questions.
A metric is a governed definition: one expression, used exactly, never re-derived.
Explorer13
Metrics6
▾Formula 1 data
▾racing
Race weekends
public.races
public.results
public.lap_times
ΣPodium finishes
ΣWins
Σ Podium finishes
Count of finishes in positions 1 to 3.
Namepodium_finishes
ExpressionCOUNT(*)
Tablepublic.results
Filtersposition <= 3
Unitcount
Synonymspodiums, top 3
Review
One queue for everything that needs your attention about the ontology: issues from real chats, the consistency audit, and warehouse schema changes. It opens on the All feed, most important first, and you can filter to a single source.
All
Every open item across the three feeds in one list, ordered by impact, so a breaking schema change sits alongside a wrong answer.
Conversations
Gaps surfaced from real chats. "Analyze conversations" scans recent chats on demand, and failing evals feed in automatically. Everything pointing at the same gap becomes one issue.
Schema changes Cassis detects in your warehouse. See Data source changes below.
How an issue reads
Cause
Why the answer went wrong, so you know how to fix it: an ontology gap (something to define or correct) or missing data (the warehouse does not have it).
Impact
What it did to the answer, most serious first: wrong answer, unreliable answer, no answer, or inefficient. The queue orders by impact, then how often the issue recurs, then how recently it was last seen.
Low-signal
Anything other than a recurring wrong answer is tucked into a collapsible Low-signal section, so the queue stays focused. A recurrence promotes it back up.
What you do
Apply & resolve
When the conversations agree on the rule that was missing, Cassis drafts the exact ontology edits and shows them inline. One click applies them and resolves the issue.
Fix in chat
When the fix needs judgment, send the whole pattern to the Assistant. Pick a branch in the switcher first and the fix lands there instead of on the live ontology.
Reference a table
When the data exists in a warehouse table that is not mapped yet, the issue points you straight at that table.
All
Conversations
Consistency
Data source
Wrong answerOntology gapSeen in 5 chats · 1 eval
"Podium" is computed inconsistently
Some chats counted positions 1 to 3, others the top 3 finishers including DNFs. Cassis drafted the metric edit that defines it once.
✓ Apply & resolve▶ Fix in chat✕
Data sourceRaised 2 times
Column renamed: position_text → status
Would break 2 joins and the Podium finishes metric. The proposed fix repoints them and keeps your descriptions, synonyms, and units.
✓ Apply fix✕ Dismiss
Consistency audit
A quality scan you run on demand. It streams findings as it goes, and saves the last run so you return to it instead of a blank slate, with a warning when the ontology has changed since it ran.
What it flags
Tables without a description, ambiguous synonyms, missing joins, and columns an agent would likely misread.
What you do
Save, copy, or download the findings. Some fixes, like applying suggested synonyms, apply straight from the results. Each finding links to its table in the Explorer.
Data source changes
Cassis watches your warehouse for schema changes and surfaces them here. Trigger a check on demand; a dot in the sidebar marks when changes are waiting.
What it catches
Renamed, removed, and retyped columns, and added or removed tables.
What it shows
Which of your joins, metrics, and virtual tables each change would break, linked to the affected object in the Explorer.
One-click fix
For renames and type changes, Cassis proposes a fix that keeps your curation (descriptions, synonyms, units) intact.
Pending, Applied, Dismissed
Review, apply, or dismiss each change. Restore a dismissed one back to the queue any time. A recurring change shows how many times it has been raised.
Assistant
Edit the ontology by chatting. Describe what you want ("define podium as positions 1 to 3"), and the Assistant proposes the change as a card you approve or reject. Long text edits, like a domain's context document, show as a git-style line diff (collapsed by default behind a +added/−removed summary, click to expand). It's the single path for applying changes, whether from scratch or from Fix in chat.
Versions and branches
How ontology changes ship: you edit, publish a version, and for bigger changes work on a branch first.
Publish a version
Pending edits collect as a diff you review, then publish like a commit. The label is pre-filled with an AI-suggested summary, and every published version is restorable.
Work on a branch
For bigger changes, create a named working copy from the branch switcher in the ontology header. Edit it in parallel without touching what is live, test it in the Assistant, then merge it back as a new published version.
Conflict-free by design
As soon as someone publishes or merges on main, other branches become read-only (stale) and can only be reviewed or deleted. No merge conflicts, ever.
Backed by GitHub
If the project is connected to a GitHub repository, publishing opens a pull request instead of applying right away, and the version goes live once it merges. See Connect a GitHub repository.
Export and import
Export the whole ontology as a single JSON file or a zip of human-editable YAML files (one per table, metric, and domain). Import either format back as a full replace.
Pending changesDiscard all↑ Publish changes
Domains~1 modified
→ racingmodifiedContext (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.
Question and reference-SQL pairs, run against the current ontology. Failures feed back into the Review queue's Conversations feed.
What an eval checks
Each case pairs a question with a reference (gold) SQL query. Since the data changes, the eval judges whether the generated query's logic matches the reference, not whether it returns a specific number.
How it's judged
An LLM judge compares the generated query's logic against your reference SQL.
Building a suite
Add a case from any chat, edit cases inline, see a case's full run history, and export or import suites as JSON.
Test Cases12
Runs
4 runs▶ Run evaluation
Date
Status
Accuracy
Version
Jun 6, 11:45
Completed
92%
v14
Jun 5, 15:20
Completed
83%
v13
Jun 2, 10:30
Completed
75%
v12
Want to try Cassis?
Access is limited to selected design partners today. Leave your email to be notified when it opens up.