Source schema
Reads the data source's own schema, as last introspected from the warehouse or uploaded as DDL. This is the layer beneath the ontology: every table the source has, including ones the ontology does not model at all.
Use it during triage when a fix needs data the ontology does not carry yet, for instance to inspect the columns of the unmapped tables a reference_tables fix proposal names. See Issues.
Parameters
| Name | Type | Notes |
|---|---|---|
project_id | UUID, required | The project whose source to read |
tables | list of strings | Fully qualified schema.table names to detail, at most 20 per call. Omit to list every table without columns |
Response
| Field | Notes |
|---|---|
schema_version | The source-schema snapshot number and when it was taken |
tables | [{name, status, column_count}] |
detailed | Only when tables was passed: [{name, status, columns: [{name, data_type, nullable?, description?}]}] |
error | Set instead of the keys above when the request fails. A project with no source schema yet returns an error telling you to sync it or upload a DDL first |
Status has three values, and the difference matters when deciding whether a table needs modeling:
| Status | Meaning |
|---|---|
modeled | Placed or curated in the ontology |
tracked | Mirrored by the ontology’s physical layer, but not modeled: no domain, no description |
untracked | The ontology has no record of it |
This is an interactive lookup, capped at 20 detailed tables per call. For bulk work across a whole schema, cassis schema pull writes the same schema to a gitignored local snapshot an agent can grep in one pass. Paging through this tool during a modeling sweep is the slow way to do it.
The schema here is observed state, not the ontology. Adding a table to the ontology means writing its file in the repository or creating it in the app, not calling a tool: see the capability matrix.