# How the curation loop works

Cassis keeps context current by turning questions, corrections, eval failures, and schema changes into evidence-backed ontology improvements.

## 1\. Detect a gap

Cassis watches real use: wrong or down-rated answers, corrections in conversations, unanswered questions, failing evals, and warehouse changes. Related signals are grouped into one issue so the team fixes the underlying gap once.

## 2\. Read the evidence

Each issue shows the questions involved, what went wrong, and any correction the user supplied. Read the occurrences before proposing a definition; similar symptoms can have different causes.

## 3\. Decide the fix

Cassis may propose a missing rule, point to unmodeled warehouse tables, or mark the issue for manual judgment. A proposal is a recommendation, not an applied change.

## 4\. Review the change

On a git-managed project, review a pull request. On an app-managed project, review the pending-changes diff. The reviewer checks the actual ontology change, not only its summary.

## 5\. Test the behavior

Re-ask the failing question, then run the approved eval suite to catch regressions. A new regression case becomes trusted only after someone validates its SQL and business interpretation.

## 6\. Publish and confirm

For git-managed projects, the GitHub App or default-branch CI job publishes after merge. For app-managed projects, publish the reviewed changes in Cassis. Confirm the new version is live before resolving the issue. In a repository workflow, the agent that made the fix proposes the resolve and an editor or admin confirms it, because resolving needs that role.

Resolving an issue records that the gap is closed; it does not change the ontology. Resolve only after the published version contains the fix.

## Choose the workflow

-   [Curate in a repository](/curate/agent/): Take an issue to a tested pull request.
-   [Curate in the web app](/curate/web-app/): Review evidence, approve a proposal, and publish.