matthieu_bl

1. What is not in the codebase. Obvious of course, but building an ontology and maintaining it over time forces a company to document what was only living in the head of some experts and never written down. In the case of analytics use cases, think of all the quirks a data analyst might have in mind when querying the data. Very basic e.g. "exclude test accounts whenever you count customers". Every analyst on the team does it without thinking, it's rarely written anywhere, and an agent that doesn't know will happily count them.

2. Related to 1., your codebase or source material may hold different interpretations of the same definition (what "revenue" means can differ between Sales and Finance). The ontology forces you to choose one, or to state when to use each. Without that, the LLM may pick one a bit randomly.

3. It's a governance tool for humans. It gives the company a human-readable, "deterministic" source of truth to agree on what means what, then version it and evolve it.

Shameless plug: we built our own open source equivalent of auto-ontology a few months ago, that doesn't require any API key but your LLM one (or none if you use your coding agent subscription)

https://github.com/GetCassis/ontology-skills

“Note: Looker Studio is not impacted by this outage.” What a relief.

It has been removed from their website and Amazon listings, and at least some specific retailers in France are also withdrawing it from sale.

Peak valuation: $17.5B in 2022

https://techcrunch.com/2022/01/05/visual-collaboration-compa...

Confirmed, Anthropic are silently testing Mythos 5.1 with some users

Summary of the different scenarios

Service: Vibe Plan: Non-Enterprise Default: Opted in Opt-out possible? Yes

Service: Vibe Plan: Enterprise Default: Opted out Opt-out possible? Yes (admin-managed)

Service: Mistral Studio/API Plan: Not specified Default: Not stated, I assume opted in Opt-out possible? Yes

Hi HN, a bit of background on this project.

I’m building Cassis, a tool for maintaining the context used by analytics agents.

Of course, before you can maintain context, you need a context to begin with.

By context, we mean the information an analytics agent needs to generate the right queries to answer questions reliably: what business domains that data covers, what tables and columns mean, what are governed metrics and joins, etc.

So far, we’ve been building that first version manually with customers. They send us what they have (schema dumps, dbt repos, glossaries, internal documentation, query logs, dashboard exports, and so on) and we assemble it with the help of coding agents. Eventually, we want to automate as much of this as possible in the product.

In the meantime, I wanted teams to be able to assemble their initial context without us, so I packaged our internal methodology into skill (instructions, scripts, and review checkpoints). The guiding principles behind it are: 1. you already have most of what an analytics agent need in your repo and internal docs and 2. you should never let an LLM invent business meaning for you. So bootstrapping context is mostly about recovering what already exists, connecting it to the right data objects, and keeping track of what each source can actually support.

The skill takes in: your schema dump, dbt code, plus glossaries, docs, dashboards and query logs if you have them. During the process, it generates a list of questions to answer for key decisions (e.g. how to cut your business into relevant domains), when it detects gaps, and when it detects ambiguities. The result is a repo with a first version of your context as YAML and markdow files, in a file tree, that you can feed your analytics agent (or a PR enriching your dbt repo with structured metadata and docs): metrics, business domains, joins.

It runs locally with your favorite coding agent and doesn’t require a Cassis account. We’ve built and tested the workflow with Claude Code so far.

Happy to get your feedback on the approach and the skill itself.