Every staleness check passes
loyal_customer - Owner
- Growth analytics
- Last updated
- 6 days ago
- Schema
- unchanged
- Description
- present
Fresh
A definition can be fresh and still be wrong. Cassis uses real questions to uncover semantic gaps and turn them into reviewable, tested updates.
Already in production with data teams in insurance and the public sector, from a few hundred to a few thousand employees.
Catalogs ingest your schema automatically. The business meaning is written by hand, so it drifts. Staleness checks catch what's old, not the definition that reads fine and computes the wrong number. And analytics agents take every definition at face value.
loyal_customer Fresh
How many loyal customers churned last quarter?
renewal_count >= 3 1,284 customers churned.
subscription_months > 12 2,190 customers churned.
906 apart on an entry marked fresh
Cassis uses the definitions your team governs to answer each question. When real use exposes missing or stale context, it comes back as a reviewable update.
Answers use the approved definitions, with SQL and provenance attached.
Questions and source changes surface conflicting definitions, gaps, and drift, with evidence attached.
Your team reviews and tests the change before it becomes shared context.
Two attributed definitions produce different churn numbers.
renewal_count >= 3 subscription_months > 12 Loyal customer: an active subscription older than twelve months, attributed to Customer success.
The entries your team browses are the entries every answer reads. Every change has an author and an approval, and answers pin to the published version.
The definitions stay yours: define them once, sync them out to dbt, Snowflake, or Cube, or manage them as files in your own git repository. Browse a sample below: pick any object in the tree.
root Global context every question inherits.
customers Customers, their subscriptions, and how loyalty and churn are measured.
customers/churn-and-retention How churn is measured against the loyal base.
billing Invoices, payments, and recurring revenue.
loyal_customers Count of distinct customers with an active subscription older than twelve months. Also called loyal or long-term customers.
COUNT(DISTINCT customer_id) CORE.SUBSCRIPTIONS status = 'active' and subscription_months > 12 churn_rate Share of loyal customers whose subscriptions were canceled. Also called attrition.
COUNT(DISTINCT CASE WHEN status = 'canceled' THEN customer_id END) / COUNT(DISTINCT customer_id) CORE.SUBSCRIPTIONS subscription_months > 12 One row per customer. Grain: CUSTOMER_ID.
Owner Data platform
CUSTOMERS.CUSTOMER_ID = SUBSCRIPTIONS.CUSTOMER_ID [one_to_many] A customer’s subscriptions, past and current.
TEXT TEXT TIMESTAMP Materialized nightly by dbt from the CRM accounts extract. Source: RAW.CRM.ACCOUNTS.
One row per subscription. A customer can hold several subscriptions over time; the current one carries an 'active' status. Grain: SUBSCRIPTION_ID.
Owner Data platform
SUBSCRIPTIONS.CUSTOMER_ID = CUSTOMERS.CUSTOMER_ID [many_to_one] Every subscription matches exactly one customer.
COUNT(DISTINCT customer_id) COUNT(DISTINCT CASE WHEN status = 'canceled' THEN customer_id END) / COUNT(DISTINCT customer_id) TEXT TEXT NUMBER TEXT Materialized nightly by dbt from the billing system’s subscription extract. Source: RAW.BILLING.SUBSCRIPTIONS.
-- models/marts/customers/subscriptions.sql
select
subscription_id,
customer_id,
months_since_start as subscription_months,
lower(state) as status
from {{ source('billing', 'subscriptions') }} Anyone who uses the catalog can propose: a question that exposes a conflict, a correction in chat, or a source change becomes a staged update with the evidence attached. Staged changes affect no answers until your data team publishes them.
Every published version is kept, with its author, label, pull request, and commit. Any earlier version can be restored, and the same history lives in your git repository.
seller_ranking
Default to delivered business volume
Where does SQL run?
Cassis uses your schema, dbt project, docs, and questions. Your environment executes the SQL.
Cassis executes through a dedicated read-only role limited to selected datasets.
Where does Cassis run?
Hosted on AWS in Paris, in the eu-west-3 region.
A Cassis-managed private deployment in your own cloud environment. Today this is an enterprise conversation.
Whose model account is used?
Anthropic through Amazon Bedrock, managed by Cassis.
Use your own Amazon Bedrock or Google Vertex AI account, available on request.
Cassis bootstraps a baseline from your warehouse schema, dbt project, docs, and dashboards. An existing catalog comes in as a one-time import. Nothing starts from zero.
Your data team reviews the bootstrapped definitions with our help and approves what becomes shared context. A pilot is about three weeks of real work.
From there, questions and source changes surface the updates, and your team approves them as they come.
Watch a missing definition become governed context, then see the next question use it.