# Review detected issues

The Review queue groups repeated symptoms into issues, orders them by impact, and keeps the supporting conversations or eval failures attached.

Open **Review** in the web app, or use the [MCP issue tools](/reference/mcp/issues/) or the [CLI issues commands](/reference/cli/issues/). Start with the highest-impact open issue your team is ready to address.

## Read the issue

- **Cause** An **ontology gap** needs a definition or relationship. **Missing data** usually means modeling another warehouse table.

- **Impact** Wrong, unreliable, or missing answers rank ahead of inefficiency. Recurrence and recency break ties.

- **Occurrences** The questions, symptoms, diagnoses, and user corrections behind the issue. This is the evidence for the fix.

## Choose the response

- **Apply a proposed rule** When the conversations agree on the missing rule, review the proposal and apply it in the project’s chosen editing workflow.

- **Model referenced tables** When the data exists but is not in the ontology, inspect the named source tables and model them.

- **Decide manually** When the evidence does not establish one business meaning, ask the domain owner instead of inventing a default.

- **Dismiss** Use for noise, duplicates, or obsolete issues. Leave uncertain issues open.

**Resolve after publication.** On a git-managed project, that means the pull request merged and the published version contains the change. Changing the issue status alone fixes nothing. Resolving is still owed once the fix is published: an agent that made it should propose the resolve.

Continue with [Curate in a repository](/curate/agent/) or [Curate in the web app](/curate/web-app/).