Connect Azure Synapse
Record the constraints that die on the way to a registered schema.
How CoreModels works with Azure Synapse
The Synapse profile in CoreModels exists for the silence, not for the conversion. Conversion is easy. Silence is expensive.
Encode-only JSON Schema for Synapse is draft-07 by design. The schematic migration recipe and LinkML-to-Synapse conversion make that subset explicit. Re-audit the governed model against what Synapse will actually validate so platform limits become reviewed findings, not vanished rules.
If you are moving meaning into Synapse, start from the richer model and keep the ledger. If you are already in Synapse, import what is there and stop pretending the registered schema was the whole definition.
Recipes
No recipes yet for Azure Synapse. The articles below still describe the problem this connector is built to close.
Uses
Problems this connector fixes
Articles that explain the gap, then point at the recipe that closes it.
The Constraint That Stopped Firing
A value that should have been rejected is sitting in a table. The governed model is explicit about that field: multiples of ten, strictly greater than zero. The schema the platform actually validates against says `integer`. Nobody deleted the rule on purpose. It was lost in translation months earlier, when a person hand-converted the model into the shape a Synapse registered schema can carry — and nothing, anywhere, recorded that it had been lost.
OutcomesThree Artifacts by Five O'Clock, None of Them Typed
By the end of the afternoon there are three things on the branch that did not exist at lunchtime: a registered-schema document ready to hand to Synapse, a blank curation grid, and a column dictionary listing every value set with its terms. Nobody typed any of them. They were projected from one governed model, in two calls, by a person whose actual work that afternoon was deciding whether the change deserved a minor or a patch bump.
GovernanceThe Difference Between a Guess and a Record
There are two ways to handle the places where a platform's public documentation goes quiet. You can guess — pick the behavior that seems likely, emit it, and hope the wire agrees with you. Or you can record — pick the conservative representation, write down exactly what you could not confirm, and hand that note to the person making the decision.
EcosystemWhere a Schema Goes After You Export It
Follow the artifact. A JSON Schema document leaves your modeling environment, gets registered with a schema service under an organization and a version, gets bound to entities on a data platform, and from then on every annotation set on those entities is validated against it. In parallel, a tabular manifest derived from the same definitions lands in front of contributors, who fill it in row by row; their uploads succeed or fail against the schema the platform holds. That is the life of a schema in the Synapse world — and understanding that world is the best way to understand where CoreModels does and does not sit in it.
AgentsAn Agent That Can Say "Unconfirmed"
Ask an AI assistant whether Synapse will enforce the `date-time` format on a string field, and you will get an answer. It will be fluent, it will cite draft-07's treatment of `format` as an annotation, it may even be correct — but you cannot tell, because the model would have produced an equally fluent answer either way. The honest response to that question is "unconfirmed," and unqualified fluency is the one register in which a language model struggles to say it.
Use caseYour Data Model Outlives Its Toolchain
For most of a decade, a data coordinating center in the Synapse world did not exactly have a data model — it had a schematic data model. The CSV the curation team maintained was written for schematic to compile. The JSON-LD graph it produced was shaped for schematic to traverse. The validation rules were expressed in schematic's vocabulary, the contributor manifests came out of schematic's generator, and the Data Curator App put a face on all of it. The model and the toolchain were one artifact, and that was fine — right up until April 2026, when the toolchain's repository was archived with a deprecation notice naming the end of the year.
QuickstartFrom JSON Schema to a Registration-Ready Synapse Schema in One Call
You have a JSON Schema. Synapse — Sage Bionetworks' data platform — will not accept all of it. Registered Synapse schemas are draft-07, and not even all of draft-07: the platform's `JsonSchema` REST object models a specific keyword subset, and anything outside it simply is not part of a registered schema. This quickstart takes a small, real schema across that boundary in one HTTP call to CoreModels (by ARAMAI), then reads the machine-readable ledger of exactly what the boundary cost.
APIThe Synapse Export, Route by Route: A CoreModels API Reference
Every format in the CoreModels transform surface belongs to two lists — the formats we decode and the formats we encode — and `synapse` appears in exactly one of them. The decode list is `jsonschema | shex | avro | jsonld | sql | osi | osi-json | owl | linkml | protobuf | odcs | odm`; the encode list swaps `odm` out and `synapse` in. This page is the working reference for that one direction: which routes produce a Synapse-ready schema, what each accepts, which one controls the registered-schema `$id`, and how to bring a Synapse schema back in anyway.
MCPSynapse Schemas from an Agent: transform_schema over MCP, End to End
Connect an MCP client — Claude Desktop, an IDE agent, your own orchestration — to a CoreModels deployment at `https://coremodels.example.com/mcp` (OAuth-protected), and two tools give it the entire Synapse workflow: `transform_schema` produces the registration-ready draft-07 schema, and `generate_synapse_manifests` produces the tabular curation companions. This article is the end-to-end session, with exact arguments and exact results, so an agent — or the person supervising one — knows precisely what each call does and does not do.
AutomationAutomating Synapse Schema Releases: Determinism, Plan Replay, and Version Discipline
Run the same Synapse export twice against the same model and you get the same bytes. That single property — deterministic encoding — is what turns the CoreModels `synapse` profile from a converter into release machinery: outputs you can commit and diff, plans you can store and replay, and a version rule you can enforce mechanically instead of remembering. This article builds that pipeline piece by piece, with the honest constraints stated where they bite.
Deep diveInside the synapse Coder: The Whitelist, the Ledger, and the Edge Cases
The entire CoreModels `synapse` profile can be stated in one sentence: *encode the neutral model as JSON Schema, then keep only what the Synapse `JsonSchema` REST object has a field for — and write down every single thing that rule removes.* This deep dive unpacks that sentence into the parts an integrator eventually needs: the IR-to-output mapping, the exact keyword whitelist and how strips are classified, the extras channel that carries verbatim keywords through the neutral model, the complete inventory of lossiness records the encoder can emit, and the edge cases our test suite pins — including the ones where we deliberately refuse to guess.