Skip to content

Context maintenance for analytics agents

Schemas change, definitions move, and nobody edits the context repo. Cassis catches the drift, drafts the fix, and proves it against evals. So your agents are always served current, approved context.

First answer in about two minutes. Read the quickstart

The loop

Serve always current, tested, approved context to your agents

Claude Code · cassis-context

01/06 · Listing maintenance issues

List the open Cassis issues.
● cassis · list_issues
Open issues (2)
1. No governed definition of “activated account”
cause: ontology_gap · impact: wrong_answer · observed in 6 conversations
Proposed fix: activated after the first successful production deployment.
2. Pending source change
Source: declared unit change in dbt manifest
deployments.duration · seconds → milliseconds
breaking · 3 context references affected

02/06 · Drafting the metric proposal

Fix the activated account gap.
Drafting a metric change from 6 observed conversations.
● Write(cassis/metrics/activated_accounts.yml)
Proposal only · Approval required from @activation-data
description: >
  Accounts whose first successful production deployment
  occurred in the requested period. Internal accounts excluded.
display_name: Activated accounts
domain_path: product/activation
expression: COUNT(DISTINCT "ACCOUNT_ID")
filters: '"IS_INTERNAL" = FALSE'
name: activated_accounts
synonyms:
- activated accounts
- activated customers
table_name: FIRST_DEPLOYMENT
table_schema: PRODUCT
unit: accounts

03/06 · Validating the context files

$ cassis ontology check
YAML parsing, round-trip and import validation passed
35 files valid · schema references resolve

04/06 · Testing against the eval suite

$ cassis eval run
✗ failed How many accounts activated last month?
not_equivalent · gold SQL returned 1,847, the agent returned 2,431
the draft counts accounts whose first deployment failed
11/12 passed
$ # count only succeeded first deployments, rerun
12/12 passed · month boundaries · retries · internal accounts
each case scored against its gold SQL, validated by a domain owner

05/06 · Pushing the review branch

$ git checkout -b cassis/activated-accounts && git add cassis/ && git commit -m "Govern the activated account definition" && git push -u origin HEAD
Branch pushed to origin/cassis/activated-accounts

06/06 · Opening the GitHub pull request

$ gh pr create --title "Govern the activated account definition" --fill
https://github.com/acme/analytics-context/pull/42
PR #42 opened · Review required: @activation-data via CODEOWNERS
The problem

Context drift does not fail CI

Business logic changed

User

How many accounts activated last month?

Agent
·Searching context for “activated account”
×No definition found
Using accounts.status = 'active'

2,431 accounts activated last month.

Expected expression
first_deployment.status = 'succeeded'

1,847 accounts activated last month.

Schema changed

declared unit change in dbt manifest
− deployments.duration · seconds + deployments.duration · milliseconds
Query, unchanged MEDIAN(deployments.duration)
Median deploy time
before change
4m 12s
after change
2d 22h

3 context references affected

Detection

How Cassis detects drift

As the context runtime for your analytics agents, Cassis records a gap each time an agent has to guess: no governed definition, two plausible signals, a clarifying question.

It also diffs every schema and dbt change against the context that references it. Your dbt definitions are imported, not redefined.

Claude Code · Cassis MCP
Ask Cassis: how many accounts activated last month?
● cassis · ask_question
“Activated account” is not defined in the ontology.
Two plausible signals:
1. accounts.status = 'active'
2. First successful production deployment
Pick one or provide your own definition.
List the open Cassis issues.
● cassis · list_issues
Open issues (2)
1. No governed definition of “activated account”
cause: ontology_gap · impact: wrong_answer · observed in 6 conversations
Proposed fix: activated after the first successful production deployment.
2. Pending source change
Source: declared unit change in dbt manifest
deployments.duration · seconds → milliseconds
breaking · 3 context references affected
Your workflow

Manage your context directly in your Git repository

Cassis structures your context as a Markdown and YAML file tree following Google's Open Knowledge Format.

Use the CLI and MCP from your preferred development environment to inspect detected issues, review and test proposed fixes, and publish approved context through your existing Git workflow.

acme / analytics-context Pull request #42

Govern the activated account definition

#42

acme-data wants to merge 1 commit into main from cassis/activated-accounts
Evidence: 6 observed conversations · Proposal only

cassis/metrics/activated_accounts.yml
+1 + description: >
+2 + Accounts whose first successful production deployment
+3 + occurred in the requested period. Internal accounts excluded.
+4 + display_name: Activated accounts
+5 + domain_path: product/activation
+6 + expression: COUNT(DISTINCT "ACCOUNT_ID")
+7 + filters: '"STATUS" = ''succeeded'' AND "IS_INTERNAL" = FALSE'
+8 + name: activated_accounts
+9 + synonyms:
+10 + - activated accounts
+11 + - activated customers
+12 + table_name: FIRST_DEPLOYMENT
+13 + table_schema: PRODUCT
+14 + unit: accounts
cassis ontology check 35 files valid · schema references resolve
cassis eval run 12/12 passed · month boundaries · retries · internal accounts
CODEOWNERS review Review requested from @activation-data
On merge published · the next "activated accounts" answer uses this definition version 12

The repository above is a specimen. Browse a real context repo on GitHub, CI gates included.

Security

Choose your security posture

Data access

Metadata only

No warehouse connection

Cassis uses your schema, dbt project, documentation, and questions. Your warehouse or existing agent executes the generated SQL. Row data stays in your environment. Evals score by SQL equivalence review.

Scoped warehouse access

Selected datasets only

Cassis executes generated SQL through a dedicated read-only role. Access is limited to the datasets your agents use, with no warehouse writes. Evals execute the generated and expected SQL and compare result rows.

Hosting

Cassis-managed

Hosted by Cassis

Hosted on AWS in Paris, in the eu-west-3 region.

Cloud-prem

Available on request

A Cassis-managed private deployment in your own cloud environment.

Inference

Managed inference

Anthropic through Bedrock

Cassis manages Anthropic inference through Amazon Bedrock.

BYOK Bedrock or Vertex AI

Your own account

Use your Amazon Bedrock or Google Vertex AI account.

Connecting your own warehouse starts with a conversation. One domain's schema is enough, as a read-only connection string or a DDL dump. Talk to us.

Get started

How it works

  1. 01

    Connect your environment

    Connect Cassis to your Git repository and install the Cassis CLI. Then give it your schema: a scoped read-only warehouse connection, or a DDL dump if you would rather not connect one yet.

  2. 02

    Bootstrap your context

    Run the bootstrap from your coding agent. Cassis writes the first context tree to your repository from your schema, dbt project, BI exports, query history, and docs.

  3. 03

    Serve it over MCP

    Connect Claude Code or any MCP-compatible agent. Cassis can answer questions, generate SQL, or return only the context the calling agent needs.

  4. 04

    Maintain it in your workflow

    List detected issues from your development environment, apply and test proposed fixes, then merge the approved pull request to publish a new context version.

Choose where to start

Run the full loop now on Stallora, the sample marketplace every new account starts with, or bring one domain from your own stack.

Already live in prod at leading tech companies, from a few hundred to a few thousand employees.