Where you work
- App-managed
- Web app
- Git-managed
- Repository
Curate and govern your context
Real questions expose missing or wrong business rules. Your team turns each one into a reviewed change to the shared context, tests it, and publishes it, so every later answer uses it.
How it works
- Find the gap
- Review, the issue queue in the web app that your agent also reads over MCP, lists the issues Cassis found in conversations, feedback and failing evals; triage decides which to fix. Source changes have their own paths: schema and dbt changes. Example: someone asked “How many active customers do we have?” and nothing defines an active customer.
- Decide the rule
- The owner agrees the rule: at least one delivered order in the last 90 days. A reply in one chat is evidence, not a decision.
- Change and review
- Add an
active_customersmetric with that rule and review the diff. - Test
- Before publishing, run the approved eval cases, and ask the question in other words against the proposed context: from a checkout in Git, or in a chat on a Cassis branch in the app.
- Publish and verify
- Publish, ask again in a new conversation, and close the issue once the published version carries the fix. If answers get worse, roll back.
To add a definition the business has just agreed, follow the workflow from its writing step. To cover a new business area, expand the existing context from its sources and check both old and new answers.
Choose how you make the change
Your project’s setup decides the workflow. If your team edits the context files in a repository, the project is git-managed; otherwise it is app-managed, and you edit in the web app. For a first project, follow Build and publish your first context.
| App-managed | Git-managed | |
|---|---|---|
| Where you work | Web app | Repository |
| How changes are reviewed | Review the proposed changes in Cassis | Review a pull request |
| How changes go live | Publish in Cassis | Merge; the GitHub App or CI publishes it |
| Best fit | Context owners who do not work in git | Teams already comfortable with git |
How changes are reviewed
- App-managed
- Review the proposed changes in Cassis
- Git-managed
- Review a pull request
How changes go live
- App-managed
- Publish in Cassis
- Git-managed
- Merge; the GitHub App or CI publishes it
Best fit
- App-managed
- Context owners who do not work in git
- Git-managed
- Teams already comfortable with git
Keep one place for edits. On a git-managed project, edit the repository; on an app-managed project, edit in Cassis. Parallel changes in both places can overwrite each other.
To move to Git, pull the existing context into a repository and choose how later changes publish. To move back to the app, disable the CI publisher or disconnect the GitHub integration first; the published context remains available.