# Capability matrix

Compare what each Cassis surface technically permits with the workflow recommended for production.

## What each surface can do

| Capability | Web app | MCP | CLI | Repository |
| --- | --- | --- | --- | --- |
| Ask questions | Yes, in chat | Yes, [`ask_question`](/reference/mcp/ask-question/) | Probe only, [`ontology test`](/reference/cli/ontology/) | No |
| Read the ontology | Yes, Explorer and export | No | Yes, [`ontology pull`](/reference/cli/ontology/) | Yes, it is the files |
| Edit the ontology | Yes, on any project. Supported for app-managed projects | No | Edit local files, then `upload` when the workflow permits | Yes, on git-managed projects |
| Look up the warehouse schema | Yes, the Schema page | Yes, [`get_source_schema`](/reference/mcp/source-schema/) | Yes, [`schema pull`](/reference/cli/schema/) | No, the snapshot is gitignored |
| Triage issues | Yes, the [review queue](/curate/issues/) | Yes, [read and set status](/reference/mcp/issues/) | No | Where the fix lands |
| Publish | Yes, the Publish button, on any project | No | [`ontology upload`](/reference/cli/ontology/), when the API key permits it | A merge triggers the GitHub App or a pipeline upload |

### Ask questions

Web app

Yes, in chat

MCP

Yes, [`ask_question`](/reference/mcp/ask-question/)

CLI

Probe only, [`ontology test`](/reference/cli/ontology/)

Repository

No

### Read the ontology

Web app

Yes, Explorer and export

MCP

No

CLI

Yes, [`ontology pull`](/reference/cli/ontology/)

Repository

Yes, it is the files

### Edit the ontology

Web app

Yes, on any project. Supported for app-managed projects

MCP

No

CLI

Edit local files, then `upload` when the workflow permits

Repository

Yes, on git-managed projects

### Look up the warehouse schema

Web app

Yes, the Schema page

MCP

Yes, [`get_source_schema`](/reference/mcp/source-schema/)

CLI

Yes, [`schema pull`](/reference/cli/schema/)

Repository

No, the snapshot is gitignored

### Triage issues

Web app

Yes, the [review queue](/curate/issues/)

MCP

Yes, [read and set status](/reference/mcp/issues/)

CLI

No

Repository

Where the fix lands

### Publish

Web app

Yes, the Publish button, on any project

MCP

No

CLI

[`ontology upload`](/reference/cli/ontology/), when the API key permits it

Repository

A merge triggers the GitHub App or a pipeline upload

## Possible is not the same as recommended

Several technically permitted operations sit outside the supported production workflow. Credentials and product controls determine what is enforced.

| Action | Possible | Recommended | Why |
| --- | --- | --- | --- |
| Edit in the app on a git-managed project | Yes | No | The next import replaces the complete ontology, so unpublished in-app work is lost and no conflict is raised |
| Publish from the app on a git-managed project | Yes. On a GitHub-synced project it commits the tree back | No | It commits the *whole* tree, so it can quietly revert a repo change made in parallel |
| Run `ontology upload` at a GitHub-synced project | Yes | No | Cassis syncs that repository itself, and the next import replaces whatever you uploaded |

## How publishing differs by setup

- **GitHub, with the app** A merge to the default branch touching the Path directory imports automatically from a webhook, and Cassis posts a sync check on the commit. Nothing to run.

- **Any other provider** A merge publishes nothing on its own. A pipeline job running [`cassis ontology upload`](/reference/cli/ontology/) on the default branch is what makes it live. See [Set up CI](/build/ci/).

- **App-managed** The Publish button. Pending edits become an immutable version.

## Important cross-surface rules

- **MCP never returns ontology content** No tool on the [MCP server](/reference/mcp/endpoint/) returns the ontology or edits it. An answer names the objects it used, and [`get_project_status`](/reference/mcp/projects/) reports the published version, pending changes, and the git binding, but the definitions themselves are not on the wire. An agent that needs to read the ontology reads it from a checkout.

- **The CLI asks questions to prove a change, not to serve people** [`cassis ontology test`](/reference/cli/ontology/) runs a question through the same agent against your local files, one full run per question. [`cassis eval run`](/reference/cli/eval/) is the regression side of the same job.

- **Triage is a status, never a fix** [`update_issue_status`](/reference/mcp/issues/) is the MCP server’s only write, and it requires the editor or admin role. It records an outcome; the ontology change is a separate edit.

- **Every publish replaces the ontology** All three paths replace the complete ontology, which is why a project should have one editing path. See [Choose how your ontology is managed](/start/choose/).

**Operating guidance is not an enforced boundary.** If your team needs the app to stay usable on a git-managed project, restrict who may write with [domain permissions](/setup/permissions/). API keys should be scoped so agents and CI can perform only the operations they own.