SQL

The most accurate description of your data is almost certainly a `CREATE TABLE` statement sitting in a migrations folder. It is reviewed, versioned, and executable - and it is legible to exactly one kind of consumer. Getting it out of that folder and into a data contract, a JSON Schema, or another vendor's dialect is usually where the accuracy stops.

| Route | Role | What it touches | |---|---|---| | `POST /graph/transform/schema/import/{projectId}` | Admin | writes the DDL's model into the project | | `POST /graph/transform/schema/export/{projectId}` | Viewer | reads the project, returns `CREATE TABLE` text | | `POST /graph/transform/schema/map/{projectId}` | Viewer (`ai`: Editor) | nothing - stateless, source in, target out | | `POST /graph/transform/plan/execute/{projectId}` | Viewer | nothing - replays a stored plan |

A partner attaches `subscriber_dump.sql` to a ticket. Backticks, an `ENUM`, a `DATETIME`, and one column named by a DBA who shouts. Your canonical model is a JSON Schema in a repo. Somebody has to reconcile the two, and historically that somebody spent an afternoon in a diff viewer.

Database teams solved schema-as-code years ago. DDL lives in git, migrations get reviewed, nobody types `ALTER TABLE` into production by hand. Then the schema has to leave the database - become a JSON Schema for the API team, a contract for the platform team, DDL for a second warehouse - and the discipline evaporates into a conversion script that one person ran once on a laptop.

Every other format on the CoreModels transform surface has somewhere to put meaning. JSON Schema has `x-` keywords. Avro has custom attributes. LinkML has `slot_uri` and `meaning`. OWL *is* meaning. SQL DDL has a name, a type, and a handful of constraints - and no annotation slot at all.