docs: point at docs.getcassis.com, keep the examples

.github/workflows/validate.yml

@@ -1,10 +1,10 @@
-# Validates the example context trees in this repo on every push and pull request,
-# using the official Cassis CLI (`pip install cassis-cli`).
+# Validates the example ontology trees in this repo on every push and pull
+# request, using the official Cassis CLI (`pip install cassis-cli`).
 #
 # This file doubles as a template for your own repo:
 #   1. Copy this workflow into .github/workflows/.
 #   2. Replace the two "Validate ..." steps with a single step for your own tree:
-#        - name: Validate the context
+#        - name: Validate the ontology
 #          run: cassis ontology check
 #          env:
 #            CASSIS_API_KEY: ${{ secrets.CASSIS_API_KEY }}
@@ -19,8 +19,9 @@
 #
 # Cassis itself also posts a "cassis / ontology validation" check on pull
 # requests that touch the tree; this workflow gives you the same verdict
-# inside your own CI — and on GitLab, see the GitLab CI snippet in
-# docs/workflow.md.
+# inside your own CI. For the GitLab CI variant, an eval-suite job to gate
+# merges, and the publish job for non-GitHub hosts, see
+# https://docs.getcassis.com/cli/#ci
 
 name: validate
 

README.md

@@ -1,46 +1,40 @@
-# Cassis context — author your context through git
+# Cassis ontology examples
 
-Your **Cassis context** is the curated semantic layer that Cassis's agent reads to turn natural-language questions into correct SQL: domains, tables and columns, joins, and governed metrics, plus the business rules that make them unambiguous.
+Two complete, working ontology trees you can copy as a starting point, plus the CI workflow that validates them.
 
-Cassis stores the whole context as a plain YAML tree in a GitHub repository you own. That means you can build and evolve your context the way you build the rest of your data platform: in an editor, on a branch, through a pull request, with CI validation — and every merge becomes a new published context version in Cassis.
-
-This repository documents the process and the file format, and ships working examples you can copy.
-
-> **A note on naming:** the GitHub check-run names and the CLI command still use the word *ontology* (`cassis / ontology validation`, `cassis ontology check`). Same thing — the docs here say *context*.
-
-## Start here
-
-1. [How it works](docs/how-it-works.md) — what a context is, and how the git sync model works
-2. [Getting started](docs/getting-started.md) — install the Cassis GitHub App, connect your repo, first sync
-3. [Repository layout](docs/repository-layout.md) — the `cassis/` tree
-4. [File reference](docs/file-reference.md) — every file type, field by field
-5. [Authoring guide](docs/authoring-guide.md) — how to write a context that makes the agent accurate
-6. [Day-to-day workflow](docs/workflow.md) — branches, pull requests, validation checks, troubleshooting
+**The documentation now lives at [docs.getcassis.com](https://docs.getcassis.com/).** This repository keeps the examples.
 
 ## Examples
 
-- [`examples/minimal/`](examples/minimal/) — the smallest realistic context (a tiny Postgres schema). Copy it as your starting skeleton.
-- [`examples/stallora/`](examples/stallora/) — a complete, well-authored context for Stallora, our demo marketplace dataset on Snowflake. This is what "done" looks like.
-
-## Validate before you push
+- [`examples/minimal/`](examples/minimal/) — the smallest realistic ontology, a tiny Postgres schema. Copy its `cassis/` directory as your starting skeleton.
+- [`examples/stallora/`](examples/stallora/) — a complete, well-authored ontology for Stallora, our demo marketplace dataset on Snowflake. This is what "done" looks like.
 
-The official CLI, [`cassis-cli`](https://pypi.org/project/cassis-cli/), runs the **exact same** three-stage validation as the `cassis / ontology validation` check on your pull requests — YAML parsing, canonical round-trip, and import validation:
+Copy one, point it at your own warehouse, and validate it:
 
 ```bash
 pip install cassis-cli
-export CASSIS_API_KEY=sk-k6-...   # create one under Organization settings → API keys
-cassis ontology check             # from your repo root
+export CASSIS_API_KEY=sk-k6-...   # Organization settings → API keys
+cassis ontology fmt               # canonical formatting, and writes cassis/AGENTS.md
+cassis ontology check             # the same validation as the pull request check
 ```
 
-The check runs server-side via the Cassis API, so it needs network access and an API key — but it is a pure function of the files it uploads: nothing in your project is read or written, the key only authenticates the caller. Success prints `✓ YAML parsing, round-trip and import validation passed (N files).`; failures print one finding per line. Run it before you push, locally or in CI — the GitHub Action in [`.github/workflows/validate.yml`](.github/workflows/validate.yml) is a working template, and the [workflow guide](docs/workflow.md#running-the-check-in-your-own-ci) has the GitLab CI variant.
+## Documentation
+
+| Topic | Where |
+|---|---|
+| Keeping the ontology in git: the sync model, connecting a repo, the pull request loop, troubleshooting | [docs.getcassis.com/git](https://docs.getcassis.com/git/) |
+| The file format, field by field | [docs.getcassis.com/file-format](https://docs.getcassis.com/file-format/) |
+| The CLI | [docs.getcassis.com/cli](https://docs.getcassis.com/cli/) |
+| Letting AI agents curate the ontology | [docs.getcassis.com/agents](https://docs.getcassis.com/agents/) |
+| How to write an ontology that makes the agent accurate | `cassis/AGENTS.md` in your own checkout, written by `cassis ontology fmt` |
 
-The CLI can also skip git entirely: `cassis ontology upload --project <project-id>` replaces a project's context with your local tree and publishes it. That makes bootstrapping fast — edit, upload, ask the agent, repeat, no GitHub App or merge needed — and it doubles as the publish path from CI on non-GitHub hosts. Details in the [workflow guide](docs/workflow.md#uploading-straight-to-a-project).
+The `docs/` directory here is kept only as stubs pointing at the pages above, so older links still lead somewhere.
 
 ## The short version
 
 ```text
 edit YAML under cassis/  →  open a PR  →  "cassis / ontology validation" check
-        →  merge to your default branch  →  Cassis imports it  →  new context version
+        →  merge to your default branch  →  Cassis imports it  →  new ontology version
 ```
 
 Questions? Reach out to your Cassis contact.