# CoreModels

> Import any schema, map it, export it. Functions for schema mapping and integration, with an MCP endpoint your agents can call.

## For agents
- [MCP endpoint (read-only)](https://go.coremodels.io/mcp): Streamable HTTP. Use a bearer API key, or OAuth via ids.schematica.io.
- [MCP endpoint (write)](https://go.coremodels.io/mcp-admin): For agents that need write access. Same auth.
- [Protected resource metadata](https://go.coremodels.io/.well-known/oauth-protected-resource/mcp): RFC 9728 metadata that names the authorization server.
- [App llms.txt](https://go.coremodels.io/llms.txt): The app host's own agent file.
- [MCP server guide](https://www.coremodels.io/mcp-server.md): How to connect Claude, Cursor and other clients.

## Pages
- [Home](https://www.coremodels.io/): Import any schema, map it, export it. Functions for schema mapping and integration, with an MCP endpoint your agents can call.
- [Pricing](https://www.coremodels.io/pricing): Builder $49/mo. Team $990/mo with 10 seats, $99 per extra seat. Enterprise from $4,000. Every plan starts with a 14-day free trial; a card is required to start, and nothing is charged during the trial.
- [Start building](https://www.coremodels.io/start): Sign in with GitHub or Google. Every plan starts with a 14-day free trial; a card is required to start.
- [Connectors](https://www.coremodels.io/connectors): Bring the file your tools already produce — a dbt manifest, a registry dump, a warehouse extract. No passwords. Every card says what you can do today.
- [Recipes](https://www.coremodels.io/recipes): 75 recipes, for 15 of the connectors.
- [CoreModels Solution Framework](https://www.coremodels.io/framework): How an organization keeps one connected core model of what its data means — across every system it runs and every agent it points at that data — and what CoreModels does to make that model real, governed, and ready for agents to build on and operate at runtime.
- [The Core Model](https://www.coremodels.io/framework/core-model): A core model is the one place your organization writes down what its data means, so every system and every agent can build on it, operate across it and answer from it instead of guessing.
- [Coherence: meaning survives many handoffs](https://www.coremodels.io/framework/coherence): A request inherits terms the estate holds. Those terms are mapped to meaning across many uses. When the meaning survives every mapping, that is coherence — and it is a capability, not a value statement.
- [Why CoreModels](https://www.coremodels.io/framework/why): Your systems already know what your data is. None of them knows what it means across the others. CoreModels holds each model as it is and keeps the mappings between them alive.
- [From ingestion to execution in five steps](https://www.coremodels.io/framework/how-it-works): Connect and ingest, model and map, collaborate and govern, expose and execute, adapt and scale — the mechanism behind the three steps on the landing page.
- [What a Core Model can do once it exists](https://www.coremodels.io/framework/capabilities): Graph-based modeling, adjustable meta-models, collaboration and suggestions, import-map-compare, precision editing, validation and governance, transformation across formats, and the agent endpoint.
- [Who it serves](https://www.coremodels.io/framework/who): Six kinds of team keep meaning somewhere. One model lets them keep it together — data and pipeline, standards and ontology, API and interface, content and semantics, research and domain, business systems and contracts.
- [The Schematica Suite](https://www.coremodels.io/framework/suite): CoreModels is the engine. The Suite is what it powers: the Schematica Library, the MCP server, the design plugins — and the wider ecosystem of standards they connect to.
- [MCP server](https://www.coremodels.io/mcp-server): Connect AI assistants to CoreModels over the Model Context Protocol. Read-only tools for search, export, validation, and schema transform.
- [Playground](https://www.coremodels.io/playground): Import a public dbt sample, audit a column rename, see what breaks and read the contract. No account needed.
- [Guides](https://www.coremodels.io/guides): Articles that explain the gap, then point at the recipe that closes it.
- [Company](https://www.coremodels.io/company): CoreModels is the platform of ARAMAI, part of the Schematica suite of solutions.
- [Agent-ready services](https://www.coremodels.io/agent-ready): Turn the systems you already run into services AI agents can use. Governed MCP access, read-only by default. The first one in ten business days.
- [Enterprise](https://www.coremodels.io/enterprise): Your scale, your controls.
- [Q&A](https://www.coremodels.io/q-a): Frequently asked questions about CoreModels, schema modeling, and semantic data platforms.
- [Changelog](https://www.coremodels.io/changelog): Dated changes to the connectors and the site, one line each, from the repository history.

## Connectors
- [Airbyte](https://www.coremodels.io/connector/airbyte): Govern the catalog every sync trusts - before a silent type change lands in the warehouse.
- [Apache Airflow](https://www.coremodels.io/connector/airflow): Govern the scheduler that already knows your freshness, ownership, and lineage.
- [Apache Avro](https://www.coremodels.io/connector/avro): One governed reading of the schema that currently lives in four places.
- [Google BigQuery](https://www.coremodels.io/connector/bigquery): Turn INFORMATION_SCHEMA from an inventory into a contract you can audit.
- [cBioPortal](https://www.coremodels.io/connector/cbioportal): Govern the four comment rows that are the schema of your study.
- [Confluent](https://www.coremodels.io/connector/confluent): Put meaning under every Kafka subject the Schema Registry already inventories.
- [Schema Converter](https://www.coremodels.io/connector/converter): A neutral hub between schema formats, with an honest lossiness ledger.
- [Databricks](https://www.coremodels.io/connector/databricks): Give Unity Catalog something to check thousands of columns against.
- [dbt](https://www.coremodels.io/connector/dbt): Your dbt project already holds the definitions, copied into every accepted_values list that tests a column. Bring a manifest; we connect the copies into one vocabulary you govern — that your agents build on, operate across and answer from.
- [Microsoft Fabric](https://www.coremodels.io/connector/fabric): Catch the warehouse type change that never pages anyone.
- [AWS Glue](https://www.coremodels.io/connector/glue): Stop treating a crawler snapshot as the meaning of your lake.
- [JSON-LD](https://www.coremodels.io/connector/jsonld): Make the vocabulary you already trust executable downstream.
- [JSON Schema](https://www.coremodels.io/connector/jsonschema): Stop asking a validator four questions it was only built to answer one of.
- [LinkML](https://www.coremodels.io/connector/linkml): Let the pipeline read the model that is already right.
- [Neo4j](https://www.coremodels.io/connector/neo4j): Write down the graph schema MERGE has been inferring for you.
- [ODCS](https://www.coremodels.io/connector/odcs): Make the contract a derived artifact of governed meaning, not a YAML twin of the table.
- [MACH ODM](https://www.coremodels.io/connector/odm): Stop shipping a recollection of the standard as if it were the standard.
- [Open Semantic Interchange](https://www.coremodels.io/connector/osi): Put two revenue numbers next to the same definition.
- [OWL](https://www.coremodels.io/connector/owl): Keep the ontology and the application schema from becoming two portraits of Person.
- [Protocol Buffers](https://www.coremodels.io/connector/protobuf): Carry reserved field numbers with the meaning, not only with the .proto file.
- [REDCap](https://www.coremodels.io/connector/redcap): Diff the codebook so a study change is a review, not a memory.
- [Salesforce](https://www.coremodels.io/connector/salesforce): Govern the org whose schema can change in forty seconds from Setup.
- [ShEx](https://www.coremodels.io/connector/shex): Keep the four assertions in every shape constraint from dying in a hand copy.
- [Snowflake](https://www.coremodels.io/connector/snowflake): Your Snowflake schema is not a contract. Generate one from the governed model.
- [SQL](https://www.coremodels.io/connector/sql): Give the column nobody can explain a definition your team governs and your agents act on.
- [Synapse](https://www.coremodels.io/connector/synapse): Record the constraints that die on the way to a registered schema.

## Recipes
- [Blank Airbyte project](https://www.coremodels.io/recipe/airbyte/generic): A preconfigured home for governing Airbyte catalogs: bring your catalog now or later.
- [CI Drift Gate for Airbyte](https://www.coremodels.io/recipe/airbyte/ci-drift-gate): Fail the build before a source schema change lands in your warehouse.
- [First Governed Import for Airbyte](https://www.coremodels.io/recipe/airbyte/first-governed-import): Turn your Airbyte catalog into a governed model in one upload.
- [Source Onboarding Review](https://www.coremodels.io/recipe/airbyte/source-onboarding-review): Govern a new source at the door, before its first sync.
- [Blank Apache Airflow project](https://www.coremodels.io/recipe/airflow/generic): Govern your orchestration estate from your own REST API exports: no credentials, ever.
- [CI Drift Gate for Airflow](https://www.coremodels.io/recipe/airflow/ci-drift-gate): Catch pipeline drift before it ships.
- [Cross-DAG lineage map](https://www.coremodels.io/recipe/airflow/cross-dag-lineage-map): Chain lineage through shared assets: producer DAG to asset to consumer DAG.
- [First governed Airflow import](https://www.coremodels.io/recipe/airflow/first-governed-import): Zero to first audit: your DAG estate governed from one API response.
- [Blank BigQuery project](https://www.coremodels.io/recipe/bigquery/generic): A preconfigured home for governing your BigQuery estate: bring your extract now or later.
- [CI Drift Gate for BigQuery](https://www.coremodels.io/recipe/bigquery/ci-drift-gate): Fail the Dataform/Terraform PR when the estate drifts from the governed model.
- [Estate Documentation Audit](https://www.coremodels.io/recipe/bigquery/estate-documentation-audit): Find every undocumented table and every ungoverned STRUCT/ARRAY/JSON payload.
- [First Governed Import for BigQuery](https://www.coremodels.io/recipe/bigquery/first-governed-import): Turn one INFORMATION_SCHEMA query into a governed estate.
- [Generate BigQuery DDL from the Governed Model](https://www.coremodels.io/recipe/bigquery/generate-back): Close the loop: meaning goes back where BigQuery users actually read it.
- [Clinical attribute registry](https://www.coremodels.io/recipe/cbioportal/attribute-registry): One governed dictionary for every study, because 24 spellings of radiation therapy is not a vocabulary.
- [Consortium conformance loop](https://www.coremodels.io/recipe/cbioportal/consortium-conformance): Retire the curation checklist: a drift loop for every study in the portfolio.
- [Staging-file preflight](https://www.coremodels.io/recipe/cbioportal/staging-preflight): Start valid instead of fixing invalid: headers minted from governed meaning.
- [Study-update gate](https://www.coremodels.io/recipe/cbioportal/ci-drift-gate): Republishing a study shouldn't silently change what its attributes mean.
- [cBioPortal governed baseline](https://www.coremodels.io/recipe/cbioportal/generic): The study's clinical schema, governed, headers only, so no patient data ever leaves your site.
- [Blank Confluent Schema Registry project](https://www.coremodels.io/recipe/confluent/generic): Govern your streaming estate from a subjects export: registry credentials stay yours.
- [CI Drift Gate for Confluent Schema Registry](https://www.coremodels.io/recipe/confluent/ci-drift-gate): Fail the build before the consumer breaks.
- [Contract-triad governance for the registry](https://www.coremodels.io/recipe/confluent/contract-triad): Avro, JSON Schema and Protobuf in one governed estate: coverage gaps stay visible.
- [First governed registry import](https://www.coremodels.io/recipe/confluent/first-governed-import): Zero to first audit: your Schema Registry as a governed model.
- [Registry-ready Avro back out](https://www.coremodels.io/recipe/confluent/generate-back): Governed model in, schemas/{Record}.avsc out.
- [Author an ODCS v3 Data Contract](https://www.coremodels.io/recipe/converter/contract-authoring-odcs): From governed model to Bitol Open Data Contract Standard, no retyping.
- [Blank conversion project](https://www.coremodels.io/recipe/converter/generic): A neutral hub between schema formats: start empty or seed it with a schema.
- [JSON Schema to SQL DDL](https://www.coremodels.io/recipe/converter/jsonschema-to-sql): From the JSON world's common tongue to CREATE TABLE, in your dialect.
- [LinkML to Synapse Registered Schema](https://www.coremodels.io/recipe/converter/linkml-to-synapse): The LinkML-to-Synapse toolchain every DCC currently hand-builds, with the subset losses declared.
- [Protobuf to Avro](https://www.coremodels.io/recipe/converter/proto-to-avro): Move a contract across the registry triad without retyping it.
- [Semantic Model for dbt (Apache Ossie JSON)](https://www.coremodels.io/recipe/converter/semantic-to-dbt): Export your governed meaning as osi-json: the serialization dbt ingests.
- [Synapse schema migration](https://www.coremodels.io/recipe/converter/synapse-schema-migration): schematic sunsets at the end of 2026. Migrate your data model with a fidelity report, not a rewrite.
- [Blank Databricks Unity Catalog project](https://www.coremodels.io/recipe/databricks/generic): Three SQL-editor queries to a governed lakehouse: no credentials, ever.
- [CI Drift Gate for Unity Catalog](https://www.coremodels.io/recipe/databricks/ci-drift-gate): Wire a Unity Catalog drift gate into CI, and keep it honest after merge.
- [Delta DDL back to Databricks](https://www.coremodels.io/recipe/databricks/generate-back): Governed model in, coremodels_delta_tables.sql out.
- [First governed Unity Catalog import](https://www.coremodels.io/recipe/databricks/first-governed-import): One information_schema extract to a governed lakehouse and a first audit.
- [Lineage-aware lakehouse governance](https://www.coremodels.io/recipe/databricks/lineage-aware-governance): Govern tables with the dependency graph that explains them.
- [A contract for the consumers dbt can't see](https://www.coremodels.io/recipe/dbt/contract-of-record): Model contracts stop at the dbt boundary. Your reverse-ETL job, your ML pipeline and the team next door have nothing.
- [Give your agent the governed meaning of `status`](https://www.coremodels.io/recipe/dbt/agent-grounding): An LLM writing SQL against your warehouse has three bad options: guess from the column name, read the SQL, or ask a human. Give it a fourth.
- [Jaffle Shop, worked: what `orders.status` means](https://www.coremodels.io/recipe/dbt/jaffle-shop-status): dbt Labs' sample project, with its five-value status column annotated so an agent looks it up instead of guessing. Every field is on the page.
- [One enum, every model](https://www.coremodels.io/recipe/dbt/governed-vocabulary): Two files test the same column with different accepted_values. Both pass. Find the one that drifted.
- [Publish governed meaning into dbt](https://www.coremodels.io/recipe/dbt/publication-contract): Meaning has nowhere to live in dbt. Govern it once, and let it reach the warehouse column comment.
- [The PR your dbt CI passes](https://www.coremodels.io/recipe/dbt/ci-contract-gate): Delete an accepted_values test and CI goes green, because the test is gone. Nothing compares the PR to what you agreed.
- [What breaks if I rename this?](https://www.coremodels.io/recipe/dbt/change-impact): dbt lineage tells you which models depend on this one. It cannot tell you who outside dbt is relying on this column.
- [Who decides what this column means?](https://www.coremodels.io/recipe/dbt/ownership-register): 41% of analytics teams say data ownership is ambiguous. dbt can tell you who owns a model. Nobody owns a definition.
- [dbt project](https://www.coremodels.io/recipe/dbt/generic): Bring a dbt estate under governance, the baseline the publication contract builds on.
- [Blank Fabric project](https://www.coremodels.io/recipe/fabric/generic): A preconfigured home for governing your Fabric Warehouse or SQL Server estate.
- [CI Drift Gate for Fabric](https://www.coremodels.io/recipe/fabric/ci-drift-gate): Fail the schema-change PR when the warehouse drifts from the governed model.
- [First Governed Import for Fabric](https://www.coremodels.io/recipe/fabric/first-governed-import): Turn two T-SQL queries into a governed warehouse model.
- [Generate T-SQL DDL from the Governed Model](https://www.coremodels.io/recipe/fabric/generate-back): Close the loop: stand up a new environment from governed meaning, not copied DDL.
- [SQL Server Estate Governance](https://www.coremodels.io/recipe/fabric/sqlserver-estate-governance): Govern a plain SQL Server estate, same connector, same T-SQL extract.
- [Blank Glue project](https://www.coremodels.io/recipe/glue/generic): A preconfigured home for governing your Glue Data Catalog: bring your export now or later.
- [CI Drift Gate for Glue](https://www.coremodels.io/recipe/glue/ci-drift-gate): Catch crawler re-inference before it breaks something downstream.
- [First Governed Import for Glue](https://www.coremodels.io/recipe/glue/first-governed-import): Turn one AWS CLI call into a governed lake catalog.
- [Generate Athena DDL from the Governed Model](https://www.coremodels.io/recipe/glue/generate-back): Close the loop: governed meaning rides back out as CREATE EXTERNAL TABLE COMMENTs.
- [Lake Catalog Governance](https://www.coremodels.io/recipe/glue/lake-catalog-governance): Give your S3 lake a second, independent account of what it is supposed to look like.
- [Blank JSON Schema project](https://www.coremodels.io/recipe/jsonschema/generic): Turn a JSON Schema document into a governed model.
- [Govern multiple JSON Schemas](https://www.coremodels.io/recipe/jsonschema/multi-schema): Bring a whole folder of schemas into one governed model.
- [Import a JSON Schema from a URL](https://www.coremodels.io/recipe/jsonschema/from-url): Point CoreModels at a hosted schema and govern it in place.
- [Blank Neo4j project](https://www.coremodels.io/recipe/neo4j/generic): A preconfigured home for governing your Neo4j graph: bring artifacts now or later.
- [CI Drift Gate for Neo4j](https://www.coremodels.io/recipe/neo4j/ci-drift-gate): Fail the build when your graph drifts from the governed model.
- [First Governed Import for Neo4j](https://www.coremodels.io/recipe/neo4j/first-governed-import): Turn apoc.meta.schema() into a governed model in one upload.
- [Generate Neo4j Constraints from the Governed Model](https://www.coremodels.io/recipe/neo4j/generate-back): Close the loop: make Neo4j enforce the governed shape.
- [GraphRAG Grounding for Agents](https://www.coremodels.io/recipe/neo4j/graphrag-grounding): Stop agents guessing your graph schema: give them the governed model over MCP.
- [Blank REDCap project](https://www.coremodels.io/recipe/redcap/generic): The whole schema estate is one CSV: govern it in one upload.
- [CI Drift Gate for REDCap](https://www.coremodels.io/recipe/redcap/ci-drift-gate): The dictionary changed on a Tuesday: catch it before the export breaks.
- [Data-dictionary round trip](https://www.coremodels.io/recipe/redcap/dictionary-round-trip): Dictionary in, governed model, upload-ready dictionary back out.
- [First governed REDCap import](https://www.coremodels.io/recipe/redcap/first-governed-import): Zero to first audit with one CSV.
- [Blank Salesforce project](https://www.coremodels.io/recipe/salesforce/generic): Govern your Salesforce org from one describe export: CoreModels never touches the org.
- [CI Drift Gate for Salesforce](https://www.coremodels.io/recipe/salesforce/ci-drift-gate): Fail the build before the org forgets what it means.
- [First governed Salesforce import](https://www.coremodels.io/recipe/salesforce/first-governed-import): Zero to first audit: your org as a governed model from one describe export.
- [Object scaffolds back to Salesforce](https://www.coremodels.io/recipe/salesforce/generate-back): Governed model in, Metadata-API CustomObject XML out, deployed only by you.
- [Salesforce object-model governance](https://www.coremodels.io/recipe/salesforce/object-model-governance): It takes forty seconds to change what a field means. Make the meaning governed.
- [Blank Snowflake project](https://www.coremodels.io/recipe/snowflake/generic): Govern your Snowflake estate from three Snowsight queries: no credentials, ever.
- [CI Drift Gate for Snowflake](https://www.coremodels.io/recipe/snowflake/ci-drift-gate): Fail the build when the warehouse drifts from the governed model.
- [First governed Snowflake import](https://www.coremodels.io/recipe/snowflake/first-governed-import): From Snowsight to first audit with one query result.
- [Warehouse contracts for Snowflake](https://www.coremodels.io/recipe/snowflake/warehouse-contracts): Your Snowflake schema is not a contract. Generate one from the governed model.

## Use articles
- [Schema Changes Don't Knock: Why Airbyte Pipelines Need a Front Door](https://www.coremodels.io/connector/airbyte/h1-need): An application team ships a routine release, and somewhere in their product database a numeric total becomes a string with a currency prefix. No announcement reaches the data team — schema changes don't knock. Airbyte keeps syncing, because moving data is its job. The warehouse keeps loading, because storing data is its job. Every sync stays green while the numbers drift quietly out of truth, until a human happens to squint at them. The only thing that broke was the meaning of the data, and meaning was the one thing no part of that pipeline was watching.
- [The Quiet Week: Life With a Governed Airbyte Connection](https://www.coremodels.io/connector/airbyte/h2-outcomes): The most convincing demo of schema governance is a boring week. No archaeology through sync logs, no "who changed this?" threads, no Friday backfill. What follows is a composite week for a data engineer who owns an Airbyte deployment after the catalog is governed in CoreModels — and, running alongside it, the same week as it used to go.
- [Five Commitments We Make Before Touching Your Airbyte Catalog](https://www.coremodels.io/connector/airbyte/h3-governance): Any tool that asks to sit between your data sources and your governed schemas is asking for a lot of trust. We think that trust should rest on verifiable commitments rather than assurances — specific behaviors, designed into the system, that you can test before you rely on them. Here are the five that govern how CoreModels handles an Airbyte catalog, and why each one exists.
- [Open Pipes, Open Meaning: Airbyte's Place in a Neutral Governance Layer](https://www.coremodels.io/connector/airbyte/h4-ecosystem): Airbyte's founding bet was that data movement should be open: an open-source platform, a connector catalog anyone can extend, and — the part that matters most for governance — schemas declared in the open. Every Airbyte stream describes itself with JSON Schema inside a catalog document: property names and types, nullability expressed as type arrays, enums, primary keys, supported sync modes. You can extract that catalog from your own instance with a single API call. No proprietary binary, no export ceremony.
- [From Plausible to Provable: Giving AI Agents the Truth About Your Airbyte Streams](https://www.coremodels.io/connector/airbyte/h5-agents): Watch a coding agent write transformation logic against ingested data and you can see the exact moment it starts making things up. Asked to build staging models over an Airbyte-landed orders stream, it will confidently produce column lists it inferred from the table name, treat every id as a unique key, assume updated_at implies incremental sync, and enumerate status values it has seen in other companies' schemas. The output is fluent, well-formatted, and structurally fictional — not because the model is weak, but because nothing in its context contained the actual schema. Agents don't fail loudly on missing ground truth; they interpolate over it.
- [Zero to First Audit: Putting an Airbyte Catalog Under Governance](https://www.coremodels.io/connector/airbyte/t1-quickstart): Everything in this tutorial happens in a shell. There is no agent to install in your Airbyte deployment, no warehouse connection to configure, and no credential of yours that ever reaches CoreModels. You export one JSON document that Airbyte already produces, upload it, and ask a question about it.
- [Every Verb, Every Role: The Airbyte HTTP Surface](https://www.coremodels.io/connector/airbyte/t2-api): One sentence in the controller sets the shape of everything below it: the vendor integration surface is read-authority. Import writes to the graph, and only additively. Audit and generate never write anything. Recording an audit run in the history is opt-in bookkeeping — except for re-audit, which always records its run because that is the whole point of the verb.
- [Tool Calls, Not Screenshots: Running an Airbyte Audit from an AI Agent](https://www.coremodels.io/connector/airbyte/t3-mcp): There are two ways to let an AI assistant help with an ingestion catalog. The first is to paste the catalog into a prompt and ask what looks risky — fast, ungrounded, unverifiable. The second is to give the assistant a tool that runs the real audit against your governed model and returns coded findings. This article is about the second one.
- [A Drift Gate for Airbyte: CI, Badges, and the Heartbeat Between Runs](https://www.coremodels.io/connector/airbyte/t4-automation): A dbt gate has an obvious trigger: someone opens a pull request, the project compiles, and the compiled artifact is the thing you audit. Airbyte has no build step. A catalog is *discovered*, not compiled, and the schema it describes belongs to a system nobody in the repository controls. So the first question for an Airbyte drift gate is not "which endpoint do I call" — it is "where does catalog.json come from, and when".
- [Inside the Airbyte Connector: Identity, Types, Checks, and the Limits We Publish](https://www.coremodels.io/connector/airbyte/t5-deep-dive): Every vendor CoreModels integrates parses into one neutral shape: datasets with fields and normalized checks, plus lineage between them. Vendor detail rides in metadata bags, never as new top-level concepts, and connectors are pure — they parse, map types and contribute audit rules, never touching the graph.
- [The Scheduler Knows Everything About Your Data. Nobody Governs the Scheduler.](https://www.coremodels.io/connector/airflow/h1-need): Picture a failure any Airflow estate can produce. The revenue dashboard is wrong for nine days. Not down — wrong, which is worse, because down gets noticed. During a migration someone paused the DAG that rebuilds the orders file. The downstream DAG that feeds the dashboard keeps right on running, every run green, consuming a file that has quietly stopped changing. Airflow does exactly what it was told. That is the problem: nothing in the system is broken, and nothing in the system is accountable either.
- [What Changes on an Ordinary Tuesday, Once Your Airflow Estate Is Governed](https://www.coremodels.io/connector/airflow/h2-outcomes): Governance tooling should be judged by what it changes about an ordinary working day — not the demo day, the Tuesday. So instead of listing features, here is a walk through the moments that go differently once your Airflow deployment has a governed model behind it: after you have extracted your DAG list, tasks, and data-aware scheduling assets from your own REST API, imported them into CoreModels, and wired the audit into CI.
- [Five Questions to Ask Before Any Tool Touches Your Airflow Metadata](https://www.coremodels.io/connector/airflow/h3-governance): Your orchestration metadata is a map of how your business actually runs — what moves, when, owned by whom, feeding what. Any tool that wants to import it should be interrogated first. Here are the five questions we think you should ask, and how our Apache Airflow connector answers them. We are publishing the answers because the posture *is* the product: a governance tool you cannot trust is worse than none.
- [Airflow Sits in the Middle of Your Stack. Govern It Without Wrapping It.](https://www.coremodels.io/connector/airflow/h4-ecosystem): Draw a map of a typical modern data platform and Apache Airflow is rarely at the edge. It is the connective tissue: it triggers the ingestion jobs, kicks off the dbt build, loads the warehouse, refreshes the feature tables, and moves the files everything else depends on. An Apache Software Foundation project with pipelines defined as Python DAGs and a broad provider ecosystem, Airflow became, for many data teams, simply *the scheduler* — the thing all the other tools are arranged around.
- [Your AI Agent Shouldn't Have to Read Python to Understand Your Pipelines](https://www.coremodels.io/connector/airflow/h5-agents): Watch what a coding agent does when you ask it why a table is stale. It opens the DAG repository, reads some Python, greps for table names, follows a few imports, and produces a fluent explanation of what it *thinks* the pipelines do. The prose is confident. The structure underneath it is guessed — and orchestration is one of the worst places in your stack to guess.
- [Zero to First Audit: Bringing an Apache Airflow Deployment under CoreModels Governance](https://www.coremodels.io/connector/airflow/t1-quickstart): Your Airflow deployment can already describe itself. The stable REST API v1 will tell you every DAG, every task, and — if you use data-aware scheduling — every asset your pipelines produce and consume. What it will not tell you is whether any of that still matches what your organization *thinks* it runs: who owns each pipeline, which assets are consumed but produced by nothing, which consumers are quietly running on stale data because every producer is paused.
- [The Airflow Integration API, End to End: Every Route, Role, and Payload](https://www.coremodels.io/connector/airflow/t2-api): Every vendor integration in CoreModels answers the same first question the same way. Ask the platform what it knows how to govern:
- [Governing Airflow with an AI Agent: The CoreModels MCP Tools in Practice](https://www.coremodels.io/connector/airflow/t3-mcp): "Which of our pipelines have no accountable owner, and is anything downstream of a paused DAG?" That is a governance question, and until recently answering it meant a human clicking through the Airflow UI and cross-referencing a wiki. With CoreModels, an AI agent answers it directly: the same import/audit machinery we expose over HTTP is exposed over the Model Context Protocol, so an agent connected to your CoreModels server can inspect connector capabilities, run a full drift-and-hygiene audit of an Airflow deployment, and read back a human-quality report — all through typed tool calls.
- [Catch Pipeline Drift Before It Ships: A CI Gate and Drift Loop for Airflow](https://www.coremodels.io/connector/airflow/t4-automation): Orchestration drift is the quiet kind of failure. Nobody deletes a pipeline; a schedule is flipped to manual during an incident and never flipped back, and for three weeks a downstream table renders yesterday's world with perfect confidence. Nobody removes a dataset from governance; a DAG is renamed in a refactor and the governed model now describes a pipeline that no longer exists. None of this throws an exception — which is exactly why it belongs in CI, where a machine checks it on every change.
- [Lineage First: How CoreModels Maps an Airflow Estate into the Governed Graph](https://www.coremodels.io/connector/airflow/t5-deep-dive): Airflow is not a schema estate. A warehouse table has columns with types; a dbt model has a contract; an Avro subject has fields. A DAG has none of those — it has tasks, a schedule, an owner, and (with data-aware scheduling) declared relationships to the data it produces and consumes. So when we built the Apache Airflow connector for CoreModels, the design question was not "how do we pretend DAGs are tables?" but "what is orchestration's actual governance value?" The answer we committed to: the DAG-to-asset dependency graph, and pipeline hygiene. This connector is lineage-first, and every mapping decision below follows from that.
- [The Four Places Your Avro Schema Isn't](https://www.coremodels.io/connector/avro/h1-need): Someone posts a question in a team channel: *what are the legal values of status on the orders stream?*
- [The Day After Import: What a Team Can Do Once Avro Is a Projection](https://www.coremodels.io/connector/avro/h2-outcomes): Four requests land on a platform team in one week. None is unusual, and each is, underneath, the same request wearing a different hat.
- [Nothing Silent: The Rules Behind Every Avro Round Trip](https://www.coremodels.io/connector/avro/h3-governance): The dangerous transformation is not the one that fails.
- [Avro Won a Layer, Not the Estate](https://www.coremodels.io/connector/avro/h4-ecosystem): Every durable format is built around one decision, and Avro's is easy to name: the schema travels with the data. A reader does not guess; it is handed the writer's schema and reconciles it with its own. That single choice produced the compact encoding, the evolution rules, the registries, and the reason Avro is still a default schema language of event streaming.
- [Stop Guessing the Union Branch: Avro for AI Agents](https://www.coremodels.io/connector/avro/h5-agents): An agent is asked to produce test records for an orders topic. It has seen ten sample messages, and it writes what those samples look like: a JSON object with an age of 30.
- [Your First Avro Transform: One Call, Three Things to Read](https://www.coremodels.io/connector/avro/t1-quickstart): You have an .avsc file. Somewhere downstream, somebody needs the same shape as JSON Schema, or as a table, or as a data contract — and they need to know what the conversion cost. This article gets you from that file to a converted schema in a single HTTP call, and then teaches you to read the three parts of the answer: the schema, the plan, and the lossiness ledger.
- [Avro Over HTTP: Four Endpoints and Their Honest Limits](https://www.coremodels.io/connector/avro/t2-api): Every transform route in CoreModels answers with the same envelope, so learning the contract once buys you the whole surface:
- [Handing Avro to an Agent: `transform_schema` End to End](https://www.coremodels.io/connector/avro/t3-mcp): Ask a language model to "convert this Avro schema to LinkML" and it will improvise — plausible YAML on a good day, invented field names on a bad one. Connect it to CoreModels over MCP and the same sentence becomes a tool call: typed arguments, a deterministic engine, and a machine-readable account of what the conversion cost. This article is the whole loop for Avro — connection, exact arguments, a real conversion, and what a well-behaved agent does with the answer.
- [Ship the Plan, Not the Script: Avro Pipelines That Replay](https://www.coremodels.io/connector/avro/t4-automation): Here is a job every streaming platform eventually has. An internal topic carries a rich record; a partner, a public catalog, or another business unit gets a redacted projection of it. Somebody writes a script. The script knows which fields to drop and which to rename, and that knowledge lives nowhere else. Six months later the source schema gains a field, the script silently passes it through, and the first person to notice is on the other side of the boundary.
- [Every Avro Construct, and Where It Lands in the IR](https://www.coremodels.io/connector/avro/t5-deep-dive): Does an int come back as an int?
- [A Complete Answer That Tells You Nothing: The BigQuery Metadata Problem](https://www.coremodels.io/connector/bigquery/h1-need): There is a query most BigQuery engineers can write from memory. Select from INFORMATION_SCHEMA.COLUMNS, join TABLES, and you get a perfect inventory of the estate: every table, every column, every data_type, every is_nullable flag, in order. It is fast, it is free, and it is complete.
- [The First Thing You Notice Is What Stops Happening](https://www.coremodels.io/connector/bigquery/h2-outcomes): Govern a BigQuery estate with CoreModels and the change is less a new capability than an absence. The archaeology stops. The "does anyone know what this column is" thread stops. The quarterly scramble to work out what changed since the last review stops, because the answer is already written down, dated, and fingerprinted.
- [Follow One Column: Where the Machine Stops and a Person Starts](https://www.coremodels.io/connector/bigquery/h3-governance): Trust in a governance tool is not established by a promise on a landing page. It is established by being able to point, precisely, at the places where automation ends and human judgement begins — and by those places being the same ones every time.
- [Thirteen Connectors, One Model: Where BigQuery Fits](https://www.coremodels.io/connector/bigquery/h4-ecosystem): Ask a CoreModels deployment which vendors it knows and it will tell you at runtime. The vendors endpoint returns every registered connector with its key, display name, capabilities and the artifacts it expects: bigquery, snowflake, databricks, fabric, glue, dbt, confluent, airbyte, airflow, neo4j, salesforce, redcap, cbioportal.
- [What Your Agent Reads in the Four Seconds Before It Writes the Query](https://www.coremodels.io/connector/bigquery/h5-agents): The interesting question about AI agents and BigQuery is not whether an agent can write SQL. It plainly can. The question is what it consults in the moment before it does.
- [Your First BigQuery Drift Audit with CoreModels](https://www.coremodels.io/connector/bigquery/t1-quickstart): *Zero to a recorded schema audit of a BigQuery dataset: one SQL query, two HTTP calls, no credentials shared.*
- [The CoreModels BigQuery Integration, Route by Route](https://www.coremodels.io/connector/bigquery/t2-api): *The complete HTTP surface for governing a BigQuery estate: every verb, every role, every payload.*
- [Governing BigQuery from an AI Agent over MCP](https://www.coremodels.io/connector/bigquery/t3-mcp): *The same import–audit–generate loop, driven by tool calls instead of curl — including how agents ship multi-megabyte extracts.*
- [A CI Drift Gate for BigQuery: Fail the PR, Not the Dashboard](https://www.coremodels.io/connector/bigquery/t4-automation): *Turning the CoreModels schema audit into an automated gate — the v1 API, errorCount semantics, the badge, the history trail, and the two directions drift can come from.*
- [Inside the BigQuery Connector: How an Estate Becomes a Governed Graph](https://www.coremodels.io/connector/bigquery/t5-deep-dive): *What actually happens between a flat JSON extract and a queryable governed model — identities, type mappings, metadata mixins, audit rules, and the approximations we admit to.*
- [Four Comment Rows Are the Schema of Your Study](https://www.coremodels.io/connector/cbioportal/h1-need): Open data_clinical_sample.txt from any cBioPortal study and look at the top of the file. Four lines beginning with #, then a row of attribute IDs, then the data. Those four lines carry the display names, the human descriptions, the datatypes — STRING, NUMBER, BOOLEAN — and the priorities for every clinical attribute in the study. They are the study's complete declared clinical meaning.
- [The Study Update That Reviews Itself](https://www.coremodels.io/connector/cbioportal/h2-outcomes): The clearest way to describe what changes when a cBioPortal study is governed is to follow one ordinary study update through a working week — the same update your team already ships, with the governance layer switched on.
- [Where the Software Stops: Governing a cBioPortal Study](https://www.coremodels.io/connector/cbioportal/h3-governance): There is one question worth asking any tool you point at a clinical schema: what is it allowed to change without asking you?
- [A Study Is Never Only a cBioPortal Study](https://www.coremodels.io/connector/cbioportal/h4-ecosystem): Trace one clinical attribute backwards from a cBioPortal study and watch how many systems it passes through. It was captured in a form or an EDC instrument. It was cleaned somewhere. It was joined to a specimen table in a warehouse. Somebody transformed it into an analysis-ready model. Then it was written into four # header rows of a staging file, validated, and uploaded — and along the way it was named four different things by four different teams, each of whom was right within their own system.
- [What an Agent Should Know Before It Answers a Question About Your Study](https://www.coremodels.io/connector/cbioportal/h5-agents): The question that exposes an ungoverned study is a boring one. "Is OS_MONTHS a number here, and what is it measured from?"
- [Twenty-Four Ways to Say Radiation Therapy](https://www.coremodels.io/connector/cbioportal/h6-attribute-registry): A public audit of 375 cBioPortal studies went looking for how the same clinical concepts were encoded from study to study — by hand, header by header. Radiation therapy alone turned up under 24 distinct encodings: different attribute IDs, different datatypes, different value conventions, all describing the same treatment. Multiply that by every common concept — smoking status, tumor stage, vital status — and the shape of the problem is plain. The platform's cross-study query tools are excellent; the attributes they query were never designed to line up. A cohort filter that matches one study's encoding silently misses the patients recorded under the other twenty-three.
- [The Curation Checklist Does Not Scale](https://www.coremodels.io/connector/cbioportal/h7-portfolio-conformance): Ask how a cancer study gets into the public cBioPortal datahub and stays good, and the answer is a checklist. A GitHub issue opens, a curator works through the required files and formats, a reviewer checks boxes, a pull request merges. It is careful, human, and it works — once, per study, at submission time. Now ask the harder question. Fifteen published studies, three curators, standards that have moved twice since the oldest study went up: who re-checks study number seven?
- [Zero to first audit: putting a cBioPortal study's clinical schema under governance](https://www.coremodels.io/connector/cbioportal/t1-quickstart): The clinical schema of a cBioPortal study does not live in a database, a catalog, or an API. It lives in the first five lines of two tab-separated text files that a curator maintains by hand. Those five lines decide whether an attribute passes portal validation, what it is called in the UI, whether it is a number or a string, and how prominently it is displayed. They are also, in most study repositories, the least reviewed lines in the project.
- [Every cBioPortal route, every role: the CoreModels HTTP surface for study governance](https://www.coremodels.io/connector/cbioportal/t2-api): Ask the API what it can do for cBioPortal before you write a line of client code:
- [Handing a cBioPortal study to an agent: governance over MCP](https://www.coremodels.io/connector/cbioportal/t3-mcp): "Check whether the study files on this branch still match what we govern, and tell me what changed."
- [One character, one broken study: automating cBioPortal drift checks in CI](https://www.coremodels.io/connector/cbioportal/t4-automation): Here is a pull request diff from a study repository:
- [Following one clinical attribute all the way into the graph](https://www.coremodels.io/connector/cbioportal/t5-deep-dive): Take a single column out of a cBioPortal patient staging file:
- [The Meaning Gap Under Every Kafka Topic](https://www.coremodels.io/connector/confluent/h1-need): Ask your Schema Registry for its subject list and you get an inventory: a name per subject, each with a version, a schema id, a schema type, and a schema document. It is a complete answer to the question *what shape is this?*
- [Day Two: Five Things a Streaming Team Can Do Once the Registry Is Governed](https://www.coremodels.io/connector/confluent/h2-outcomes): Someone posts in the platform channel: *does shipped_at ever arrive null on the shipment events topic?*
- [Receipts, Not Reassurance: How We Govern a Registry We Never Touch](https://www.coremodels.io/connector/confluent/h3-governance): A successful import in CoreModels returns two lists. One is errors, which is empty — the run proceeded. The other is lossiness, and it is often not empty at all: an itemized statement of everything the import approximated, counted without parsing, or deliberately left out.
- [A Subject Is a Border Crossing](https://www.coremodels.io/connector/confluent/h4-ecosystem): Two teams that will never attend the same meeting still have to agree on something, and in a Kafka estate that something is a subject in the Schema Registry. The producer owns a service and a release train; the consumer owns a different service, a different train, and different assumptions. Between them sits one versioned schema document that neither fully owns and both depend on.
- [Give the Agent Something to Cite](https://www.coremodels.io/connector/confluent/h5-agents): An engineer types into an assistant: *add a refund_reason field to the payments event and update the two consumers that need it.*
- [Confluent Schema Registry to CoreModels: Zero to First Audit](https://www.coremodels.io/connector/confluent/t1-quickstart): Your Schema Registry already knows every event contract in your streaming platform — every subject, every version, every Avro record your producers have ever registered. What it does not know is what those contracts *mean*, whether the meaning is still what your consumers agreed to, and who is guarding it. In this tutorial we take a real registry from nothing to a completed schema audit in CoreModels: export the subjects with one shell loop, import the estate into a governed project, run the first audit, and read the result line by line.
- [The Complete HTTP Surface for Confluent Schema Registry Governance](https://www.coremodels.io/connector/confluent/t2-api): This is the reference we wish every integration shipped with: every route, every role, every payload — nothing implied. CoreModels exposes eight core verbs for a Schema Registry estate across two HTTP surfaces, and this article walks all of them with real request and response bodies. The vendor key is confluent; the connector declares Import, Audit, Generate, so every verb below is genuinely available — including artifact generation, which not all of our connectors support.
- [Ask Your Agent Whether the Kafka Schemas Drifted: Confluent Governance over MCP](https://www.coremodels.io/connector/confluent/t3-mcp): "Did anything in the registry drift from what we agreed?" is a question a platform engineer answers with three terminal commands and a diff. It is also, increasingly, a question they type into a chat window — and the agent on the other end needs real tools, not guesses. CoreModels ships its Confluent Schema Registry governance as a set of MCP tools, so any MCP-capable agent — Claude, Claude Code, or anything speaking streamable HTTP — can run the same import, audit, generate, and status verbs the HTTP API exposes, with the same role enforcement and the same read-only guarantees.
- [Failing the Build Before the Consumer Breaks: A CI Drift Gate for Confluent Schema Registry](https://www.coremodels.io/connector/confluent/t4-automation): The Schema Registry's compatibility checks are necessary and not sufficient. They guarantee a new schema version can be deserialized by existing consumers — wire compatibility. They say nothing about whether amount is still the governed Double your downstream jobs assume, whether an enum quietly grew a symbol nobody reviewed, or whether a topic your reports depend on disappeared from the registry altogether. Those are questions about *meaning*, and meaning drift in streaming breaks things at runtime, in production, at consumer speed. This article wires the CoreModels schema audit into CI as a merge gate for schema changes, then completes the loop with the status badge, the rolling history, one-call re-audits, and the scheduled heartbeat.
- [Anatomy of a Governed Streaming Estate: How the Confluent Connector Maps Subjects into the Graph](https://www.coremodels.io/connector/confluent/t5-deep-dive): A schema registry is three naming systems wearing one trench coat. There is the *subject* (orders-value), the registry's versioned unit. There is the *record* (com.acme.Order), the Avro type the schema declares. And there is the *topic* (orders), the physical stream the subject-name strategy encodes. Most tooling collapses these into one string and loses information doing it. This deep dive walks exactly how CoreModels maps a Confluent Schema Registry export into the governed graph — what becomes a Type, an Element, a Taxonomy or a reference; what rides metadata; which audit rules are this vendor's; and where the mapping is lossy, because a governance product that hides its own approximations cannot be trusted about anyone else's.
- [Six Thousand Columns, and Nothing to Check Them Against](https://www.coremodels.io/connector/databricks/h1-need): Run one query against system.information_schema in a mid-size Unity Catalog estate and what comes back is genuinely impressive: every table and view addressed as catalog.schema.table; every column with its full_data_type spelled out exactly as the catalog holds it, its ordinal position, its nullability flag, and a comment wherever somebody bothered. Hundreds of tables. Thousands of columns. Complete, accurate, current.
- [The Meeting That Used to Take Two Weeks](https://www.coremodels.io/connector/databricks/h2-outcomes): Somebody proposes changing a column. Not a dramatic change — order_total needs a different type after a rounding bug, or status needs one more allowed value.
- [Trust Is a Set of Powers Refused](https://www.coremodels.io/connector/databricks/h3-governance): Most tools that want to govern a data platform begin by asking for access to it. A service principal, a warehouse role, a token with just enough scope — and from that moment the honest answer to "what can this thing do to my estate?" is "you'd have to read the code."
- [Follow One Table Across Your Stack](https://www.coremodels.io/connector/databricks/h4-ecosystem): Pick a table. Say sales.orders.
- [What an Agent Should Be Allowed to Assume](https://www.coremodels.io/connector/databricks/h5-agents): Hand an AI agent a table name and a task, and before it writes a line it has made a dozen assumptions. That customer_id identifies a customer and is unique. That status has a small set of values and active is one. That amount is a number, in one currency, never null. That the orders it found is *the* orders. That today's shape is the shape it was told about.
- [Zero to First Audit: Governing a Databricks Unity Catalog Estate with CoreModels](https://www.coremodels.io/connector/databricks/t1-quickstart): This is a working session, not a tour. By the end of it you will have a governed model of a Unity Catalog schema inside CoreModels, and you will have run your first drift audit against it — without installing anything in your workspace and without handing us a single credential. Everything CoreModels learns about your lakehouse arrives as JSON files you extract yourself from the Databricks SQL editor.
- [Every Endpoint of the CoreModels Databricks Integration, With Real Payloads](https://www.coremodels.io/connector/databricks/t2-api): Reference articles usually show the happy path and gesture at the rest. This one is the full inventory: every HTTP route the CoreModels Databricks Unity Catalog connector answers on, the role each one enforces, the request and response bodies as they actually are, and — where a verb lives on one surface but not the other — an explicit statement of that fact rather than a diagram that implies otherwise.
- [Ask Your Agent Whether the Lakehouse Drifted: Unity Catalog Governance over MCP](https://www.coremodels.io/connector/databricks/t3-mcp): "Has our Unity Catalog estate drifted from what we agreed it means?" is a question an AI agent can now answer with evidence instead of vibes. The same governance verbs that back the CoreModels HTTP API — status, audit, import, generate — are exposed as tools on our MCP server, so an agent can inspect a governed Databricks estate, audit a fresh extract against it, and draft the fix, all inside one conversation. This article walks that loop exactly as an agent drives it, with the real tool names and arguments, including the artifactUrls path for extracts too large to paste into a chat.
- [Fail the Build, Not the Dashboard: A CI Drift Gate for Databricks Unity Catalog](https://www.coremodels.io/connector/databricks/t4-automation): Somewhere in your lakehouse, a notebook is about to rebuild a table with a widened column type, and nothing will fail until a dashboard does — days later, in front of the wrong audience. The cheapest place to catch that is a pull request. This article turns the CoreModels schema audit into a merge-blocking CI gate for a Unity Catalog estate, then builds out the rest of the operational loop most drift setups forget: the status badge, the rolling history, the one-call re-audit for when the governed model itself changes, and the scheduled heartbeat that keeps watch between releases.
- [Anatomy of an Import: How a Unity Catalog Estate Becomes a Governed Graph](https://www.coremodels.io/connector/databricks/t5-deep-dive): Take a single row of a Unity Catalog extract:
- [Seven Problems, One Cause](https://www.coremodels.io/connector/dbt/00-start-here): If you run dbt at scale, you have probably hit several of these. They arrive as unrelated annoyances, get filed under different headings, and get fixed — when they get fixed — by different people using different tools.
- [Eleven Copies of One Enum](https://www.coremodels.io/connector/dbt/h1-need): Grep a mature dbt project for accepted_values and count the hits on your order status field. In a mature project, the number is rarely one. The list appears in the staging model that first cleans the column, in two intermediate models, in the fact table, in three marts built for three teams, and in another four models a second squad wrote when it needed the same field and copied the nearest example it could find.
- [The Ticket Nobody Files](https://www.coremodels.io/connector/dbt/h2-outcomes): The enum problem is the one everybody recognizes, and it is not the whole of what changes. Once meaning is governed once and published back into dbt, a set of small recurring chores stop happening — and one of them has been costing time every month without ever being on a roadmap.
- [Six Refusals: What CoreModels Will Not Do to Your dbt Project](https://www.coremodels.io/connector/dbt/h3-governance): A dbt project is the most consequential text a data team owns. The definitions in it decide what gets built, what gets tested, and what every downstream consumer believes. CoreModels asks to publish into that text — governed descriptions, types, vocabularies, and bound ontology terms, emitted as dbt model property files with enforced contracts. Anything asking for that position should be judged less by what it can do than by what it will not do.
- [dbt Owns the Transformation. Nobody Owns the Definition.](https://www.coremodels.io/connector/dbt/h4-ecosystem): Pick one column — status in your orders mart — and count the tools that hold an opinion about it. dbt tests it and, if the model is contracted, refuses to build when its type changes. A catalog lists it, draws its lineage, and lets someone attach a note. An observability tool watches its distribution and raises an alert when yesterday looks unlike last week. A semantic layer, in the BI sense of metrics and dimensions, exposes it as a dimension. Outside the warehouse, an API team ships a field meant to mean the same thing, and a streaming team keeps an enum on a topic meant to mean it again.
- [The Fourth Option for a Column Named status](https://www.coremodels.io/connector/dbt/h5-agents): This is no longer a hypothetical audience. dbt Labs' 2026 State of Analytics Engineering (n=363) reports 72% of teams prioritizing AI-assisted coding and 71% concerned about incorrect data reaching stakeholders — the same teams, describing both halves of the problem below.
- [The Rename You Didn't Make](https://www.coremodels.io/connector/dbt/h6-change-impact): There is a column in your project called status, and you have wanted to rename it for about eight months. It should be order_status — everyone agrees. You have not done it.
- [Ask in #analytics and See Who Replies](https://www.coremodels.io/connector/dbt/h7-ownership): Somebody wants to add a value to a status column. They are not being careless — they have checked that the value is real, and they have found the model. What they cannot find is the person who gets to say yes.
- [The Consumers dbt Can't See](https://www.coremodels.io/connector/dbt/h8-contract-of-record): Your mart has a contract. It is enforced, it is checked on every build, and it is genuinely good.
- [Every Check You Run Compares the PR to the Last Commit](https://www.coremodels.io/connector/dbt/h9-ci-gate): Here is a two-minute experiment worth doing on a branch before you read further.
- [Manifest In, Contracts Out: A dbt Round Trip in Five Steps](https://www.coremodels.io/connector/dbt/t1-quickstart): Most integrations treat dbt as somewhere to read from. This one also publishes back: governed meaning leaves CoreModels as dbt model property files with enforced contracts, one file per model, colocated beside that model's own .sql. This walkthrough runs the whole loop — artifacts out of dbt, meaning governed on top of them, contracts back into the repo, dbt build green. Nothing here needs a warehouse credential or a dbt platform connection: artifacts in, artifacts out. CoreModels never writes to your repo and never opens a pull request. Generate returns files; your own PR flow lands them.
- [Four Verbs and a Fan-Out: The dbt Integration over HTTP](https://www.coremodels.io/connector/dbt/t2-api): The dbt connector declares Import, Audit, and Generate, and four routes carry the loop that matters: push artifacts in, check them against governed meaning, publish contracts back out, and ask what the last import knew. This is the route-by-route reference — role gating, request bodies field by field, exact response shapes. Throughout, https://coremodels.example.com stands in for your deployment, $TOKEN for your bearer token, and $PROJECT_ID for the 32-character hex id of the governing project. The vendor key is dbt. One property runs through all four: no credentials — artifacts in, artifacts out. CoreModels never connects to your warehouse, never runs dbt, never reads a dbt platform API, and never writes into your repository; Generate hands back files, and your own PR flow lands them.
- [Four Tools and a Ledger: dbt Contracts from an Agent's Seat](https://www.coremodels.io/connector/dbt/t3-mcp): "Generate the contracts for stg_orders and stg_customers, and tell me if anything won't apply cleanly." That sentence is an afternoon of dbt property-file maintenance, and an agent connected to CoreModels over MCP can answer it with real tool calls instead of plausible-looking YAML. Four vendor integration tools give the agent the same governance surface a human gets over HTTP: the same role checks, the same read-only guarantees, and the same honest ledger of what could not be represented.
- [Two Loops and an Empty Diff: dbt Contract Automation in CI](https://www.coremodels.io/connector/dbt/t4-automation): Try this on a branch first, because it reframes what the gate is for. Take a model with an accepted_values test, delete the test, and open a pull request.
- [Every Line Has a Source: Inside the dbt Contract Generator](https://www.coremodels.io/connector/dbt/t5-deep-dive): CoreModels publishes governed meaning *into* a dbt project. You call Generate and get back dbt model property files with enforced contracts — one per model, colocated with the model's own .sql — which your own pull request flow lands in the repo. CoreModels never writes to your repo, never opens the PR, never runs dbt, and never connects to a warehouse; it returns files. Which means the files have to be checkable. Every line the generator emits traces back to a fact recorded in the governed model, and where a fact is missing it omits the line and says why rather than guessing. This is the mechanism in the order it runs, so an engineer reading the output can verify it against the rules instead of trusting it.
- [Grounding an Agent in Your dbt Project: What It Reads, and What Changes](https://www.coremodels.io/connector/dbt/t6-agent-grounding): An agent pointed at your warehouse can already write SQL. The question is what it knows about the columns it writes against, and the honest answer is: the names, the types, and whatever free text happens to be in a description. Everything else it infers.
- [Finding the `accepted_values` List That Drifted](https://www.coremodels.io/connector/dbt/t7-vocabularies): Two files in your project test the same column against different value lists. Both tests pass, so nothing has ever told you. This guide finds them, and turns the list into something that can only be defined once.
- [Building an Ownership Register That Survives Contact With a Real Team](https://www.coremodels.io/connector/dbt/t8-ownership): Ownership registers fail in a predictable way: someone fills a spreadsheet in a week of good intentions, three people leave over the next year, and the file becomes an archaeological record of who used to work here. This guide builds one that does not do that.
- [Nothing Broke. That's the Problem.](https://www.coremodels.io/connector/fabric/h1-need): The expensive warehouse incidents never announce themselves. A monthly reconciliation comes out a few cents off per row. Every pipeline ran green. Every dashboard rendered. Nobody was paged. Three weeks earlier, a table was rebuilt and an Amount column went from decimal(18,2) to float — and the database did exactly what a database is supposed to do: it stored the values, coerced the types, and answered every query without complaint.
- [Five Questions a Governed Warehouse Answers Without a Meeting](https://www.coremodels.io/connector/fabric/h2-outcomes): Every team that owns a Fabric Warehouse or a SQL Server estate fields the same handful of questions. They arrive in stand-ups, in review threads, in messages from someone who needs an answer before lunch. Individually they look small. Collectively they are where warehouse ownership goes: a day tracing a type, an afternoon explaining a join, a standing meeting whose only purpose is to reconstruct what everyone used to know.
- [A Catalog That Agrees With Everything Can Warn You About Nothing](https://www.coremodels.io/connector/fabric/h3-governance): Here is a design flaw hiding inside a lot of metadata tooling. Point it at your Fabric Warehouse and it crawls the schema, recording what it finds. Point it again next week and it records what it finds *now*. The tool is always current, always accurate, and useless for the one job that matters: telling you something changed that should not have.
- [Your Warehouse Is a Junction, Not a Destination](https://www.coremodels.io/connector/fabric/h4-ecosystem): Draw your data estate on a whiteboard and the warehouse always ends up in the middle of the picture. That placement is accurate about traffic and misleading about authority. A Fabric Warehouse is where things pass through: transformations land tables in it, ingestion tools feed it, BI semantic models and reports and notebooks and agents read out of it, and downstream systems copy from it. Very little of what a warehouse table *means* actually originated in the warehouse.
- [Pasting Your Schema Into the Prompt Is Not Grounding](https://www.coremodels.io/connector/fabric/h5-agents): The standard way to make an AI agent useful against a warehouse is to give it the schema: dump the DDL, or scrape INFORMATION_SCHEMA into a text blob, and paste it into the context window with "use this to answer questions about our data." It works well enough to demo, which is why it survives long enough to cause problems.
- [From INFORMATION_SCHEMA to a Governed Model: A Microsoft Fabric Walkthrough](https://www.coremodels.io/connector/fabric/t1-quickstart): Your warehouse already publishes a complete, machine-readable description of itself. Every Fabric Warehouse and SQL analytics endpoint answers SELECT ... FROM INFORMATION_SCHEMA.COLUMNS with the tables, the columns, the types, the nullability. Every one of them answers INFORMATION_SCHEMA.TABLE_CONSTRAINTS with the keys. That description is the whole input CoreModels needs to build a governed model of the estate and then guard it.
- [The Fabric Integration API: Every Route, Every Role, Every Payload](https://www.coremodels.io/connector/fabric/t2-api): CoreModels exposes vendor integrations over two HTTP surfaces, and the split is not decoration. The interactive surface under graph/integrations/... is what a person or a notebook calls with a normal CoreModels login token. The machine-to-machine surface under v1/... accepts user API keys and is what a build pipeline calls. Both require authentication; both then enforce a per-project role on top of it.
- [Governing a Fabric Warehouse from an Agent: the MCP Integration Tools in Practice](https://www.coremodels.io/connector/fabric/t3-mcp): An agent has a context window, not a file system. That single constraint shapes how AI-driven governance of a Microsoft Fabric warehouse actually works: the model cannot paste a forty-megabyte INFORMATION_SCHEMA extract into a tool call, cannot hold your SQL credentials, and should not be trusted to invent a schema comparison in its head. What it *can* do is call a small set of typed tools that run the real audit engine server-side and hand back a verdict.
- [Wiring the Drift Gate: Continuous Schema Governance for Fabric and SQL Server](https://www.coremodels.io/connector/fabric/t4-automation): Schema governance that lives in a document is not governance. It is a document. The version that actually holds is the one a pipeline can fail on — a single number, checked on every change, with a trail behind it that shows whether the estate is getting better or worse.
- [Identity, Types and Honest Loss: What a Fabric Import Actually Writes](https://www.coremodels.io/connector/fabric/t5-deep-dive): Governance starts with a question that sounds trivial and is not: what *is* a table, once it stops being a table?
- [The End of Schema Silos: Why We Built 13 Credential-Free Data-Estate Integrations](https://www.coremodels.io/connector/general/01-end-schema-silos): Every system in your data estate holds a fragment of what your data means — and none of them holds the whole. We built CoreModels to gather those fragments into one governed graph, and we did it without ever asking for a single password. Here's why that posture matters as much as the graph itself.
- [Schema Drift Is Inevitable. Losing Track of It Isn't.](https://www.coremodels.io/connector/general/02-schema-drift): Your data estate changed this week — a column's type widened to unblock a load, a model's contract quietly stopped being enforced, an enum grew a value nobody reviewed. None of that is a failure of discipline; it is what living systems do, and the only real failure is not knowing. CoreModels is built around that distinction: drift is expected, and the product's job is to make sure it never goes unnoticed.
- [The Semantic Interchange Moment](https://www.coremodels.io/connector/general/03-semantic-interchange): For years, the meaning of your data — what a metric measures, which dimension a field belongs to, which values a status is allowed to take — has lived inside whichever tool happened to define it. That is finally changing: open specifications for semantic models, data contracts, and domain schemas are converging on one idea — meaning should travel. CoreModels is built for exactly that moment.
- [From Labels to Meaning: Ontology-Grounded Schemas for FAIR Data](https://www.coremodels.io/connector/general/04-ontology-grounding): A column called diagnosis tells a machine almost nothing. Is it a disease, a symptom, a billing code, or a paragraph of a clinician's notes? For research data to be genuinely reusable, that ambiguity has to resolve somewhere — and the place it resolves is a shared ontology. This is how CoreModels helps you attach real, resolvable meaning to a schema element, one term at a time, with a person always making the final call.
- [Agents Should Consult, Not Guess](https://www.coremodels.io/connector/general/05-agent-grounding): An LLM agent working against your data platform always has an opinion about your schema. The only question is whether that opinion comes from a stale paste buried in a prompt — or from the system that actually governs what your data means. We built the CoreModels MCP server so agents can ask instead of assume.
- [Governing Your Warehouse Schema: A dbt + Databricks Walkthrough](https://www.coremodels.io/connector/general/06-warehouse-integration-walkthrough): *Your dbt project and your Databricks catalog each think they know what orders.order_total means. CoreModels holds the governed answer in one place — and audits both estates against it, in CI, without ever holding a warehouse credential. Here is the whole loop, end to end, with real requests and real responses.*
- [One Neutral IR, Fourteen Formats: The Schema Transformation API](https://www.coremodels.io/connector/general/07-universal-schema-transformation): JSON Schema, Avro, SQL DDL, LinkML, proto3, an ODCS data contract: each format you run is a partial view of the same underlying model. CoreModels treats it that way: one neutral intermediate representation in the middle, fourteen formats around it, and a signed confession every time a hop loses something. This article walks the transformation API end to end, over HTTP and over MCP.
- [Data Contracts That Mean Something: ODCS In and Out](https://www.coremodels.io/connector/general/08-odcs-data-contracts): A data contract is a promise from a producer to its consumers: this dataset will have these properties, with these types, and these ones will always be present. The Open Data Contract Standard (ODCS) gives that promise an open, versioned YAML form — and CoreModels gives it something to be *true of*: a governed model that exports the contract, imports it, and audits the estate against it. Here is the full loop, with an honest ledger of what each hop can and cannot carry.
- [AI-Proposed, Gate-Approved: Safe LLM Schema Mapping](https://www.coremodels.io/connector/general/09-ai-assisted-mapping): Large language models are genuinely good at proposing field mappings — and genuinely terrible at being trusted blindly. CoreModels resolves that tension architecturally: the AI proposes a mapping plan, and the same deterministic validation gate that checks human-written plans accepts or rejects it. What survives the gate is a replayable artifact you can execute forever without the model in the loop.
- [Governing Kafka Contracts: The Schema Registry Triad](https://www.coremodels.io/connector/general/10-streaming-schema-governance): Streaming estates rarely standardize on one serialization format. A real Schema Registry holds Avro subjects next to JSON Schema subjects next to Protobuf subjects, and every one of them is a contract some consumer depends on at runtime — which is exactly where drift surfaces: not in a code review, but in a deserialization exception at 2 a.m. Here is how to govern that estate from one place with CoreModels — including an honest account of where today's parsing boundary sits — and how the same .proto or .avsc becomes SQL DDL, JSON Schema, or an ODCS contract for the rest of your platform.
- [The Catalog Knows Your Tables. It Doesn't Know What They Mean.](https://www.coremodels.io/connector/glue/h1-need): A crawler ran over the weekend. On Monday, a column in a table your finance dashboards depend on is no longer a bigint — a few malformed rows in a new S3 partition convinced the crawler it was looking at strings. Nothing failed. Nothing alerted. The Glue Data Catalog did exactly what it is designed to do: it recorded what the files look like now. The first person to notice is an analyst three days later, staring at a join that silently returns nothing.
- [After the Import: What a Governed Glue Catalog Changes Day to Day](https://www.coremodels.io/connector/glue/h2-outcomes): The honest test of any governance tool is not the demo — it is what an ordinary Tuesday looks like six weeks after you adopted it. So instead of walking through features, let us walk through a week with a Glue Data Catalog that has a governed CoreModels project behind it, and contrast each moment with how the same moment used to go.
- [Read-Only by Design: How We Earn Trust With Your Glue Catalog](https://www.coremodels.io/connector/glue/h3-governance): "What does it touch?" is the first question a platform team asks about any tool that wants to look at their data lake, and it is the right question. Our answer for the AWS Glue integration is unusually short: nothing in your AWS account, ever. CoreModels never holds AWS credentials and never opens a connection to AWS. You run aws glue get-tables yourself, with your own credentials, inside your own perimeter, and upload the resulting JSON. A live-sync mode is a capability we have deliberately deferred rather than quietly shipped, precisely because "we'll be careful with your keys" is a weaker promise than "we never have them."
- [Glue Is the Metastore. It Shouldn't Have to Be the Meaning.](https://www.coremodels.io/connector/glue/h4-ecosystem): Few pieces of infrastructure are load-bearing for as many systems as the AWS Glue Data Catalog. It began as a managed, Hive-compatible metastore and became the connective tissue of the AWS analytics stack: crawlers and Glue ETL jobs populate it, Athena resolves every query through it, EMR and Redshift Spectrum read it, Lake Formation layers permissions over it. If your data lives in S3 and you query it with SQL, the catalog is almost certainly in the path.
- [Agents Shouldn't Guess at the Data Lake](https://www.coremodels.io/connector/glue/h5-agents): Give an AI agent access to Athena and ask it a business question — "how many participants enrolled last quarter" — and you can watch it improvise. It lists tables and picks the one whose name sounds right. It infers that status = 'active' probably means enrolled, because what else would it mean? It writes a query that scans every partition because nothing told it the table was partitioned by month. The SQL is fluent, the answer arrives with confidence, and every load-bearing assumption in it was a guess.
- [Ten Minutes to a Governed Glue Catalog](https://www.coremodels.io/connector/glue/t1-quickstart): Open a terminal. Everything in this tutorial is one AWS CLI command and two HTTP calls, and at the end of it your AWS Glue Data Catalog has a governed twin in CoreModels plus a first drift audit you can read line by line. Nothing gets installed in your AWS account, no IAM role is granted to us, and no credential of yours travels anywhere: you run the CLI, you upload the JSON it printed.
- [The AWS Glue Integration API, Route by Route](https://www.coremodels.io/connector/glue/t2-api): CoreModels models vendor governance as a small, fixed set of verbs and applies them uniformly to every connector. For AWS Glue Data Catalog — vendor key glue — that is eight core routes on the interactive surface and two on the machine-to-machine surface. (A newer sync-plan surface — sync/propose, plan fetch, and the sync ledger — sits beside these and is not covered here.) This is the reference: the exact paths, the role each one enforces, the request bodies as the API defines them, and the responses you actually get back.
- [Handing the Glue Catalog to an Agent: CoreModels over MCP](https://www.coremodels.io/connector/glue/t3-mcp): An agent that can answer *"did our lake drift?"* needs three things: a way to reach the governed model, a way to hand it a fresh catalog export, and a guarantee that asking the question cannot change the answer. The CoreModels MCP server provides all three. The same vendor-integration engine behind the HTTP routes is exposed as MCP tools, with the read verbs at Viewer role and the write verbs behind an admin endpoint and real project membership.
- [Automating Glue Drift: The Gate, the Trail, and the Heartbeat](https://www.coremodels.io/connector/glue/t4-automation): Nothing in your repository changes when a crawler retypes a column. That is the awkward fact about lake governance: the estate you need to watch does not live in git, so the usual "run it on pull requests" reflex leaves the interesting drift entirely unobserved. A Glue drift gate has to be driven by a clock, not by a commit — and once it is, three more mechanisms fall out of it almost for free: a rolling trail, a status badge, and a server-side heartbeat that watches the *other* direction of drift.
- [What Happens to a Glue Table on Its Way into the Graph](https://www.coremodels.io/connector/glue/t5-deep-dive): Take one entry out of an aws glue get-tables response — a table called events in database lake, a few columns, one partition key, a classification parameter, an S3 location — and follow it into CoreModels. By the end it is a governed Type with Elements, a vendor identity, a metadata mixin, an entry in an estate snapshot, and a set of audit rules watching it. This is that journey, plus the honest edges: what is approximated, what is deliberately not invented, and which behaviors will surprise you.
- [You Already Have the Vocabulary. Why Can't Anything Use It?](https://www.coremodels.io/connector/jsonld/h1-need): Somewhere in most organizations that take meaning seriously, there is one document nobody argues with. It might be a partner's published vocabulary, a domain model built by a standards-literate team, or a profile of schema.org. It is written in JSON-LD: classes and properties in an @graph, each carrying a globally unique identifier, with a @context declaring exactly which namespace every short name expands into. It is often the most carefully reasoned description of the business anyone in the building owns.
- [After the Import: The Requests That Stop Being Projects](https://www.coremodels.io/connector/jsonld/h2-outcomes): The clearest sign that a vocabulary has been properly adopted is not a diagram. It is a category of request that stops requiring a meeting.
- [Who Is Allowed to Change What Your Model Means?](https://www.coremodels.io/connector/jsonld/h3-governance): Every organization has an answer, and in most of them the honest one is: whoever ran the last import. A tool ingested a document, wrote what it found, and a governed concept shifted meaning because a parser made a decision at three in the morning.
- [JSON-LD Is Everywhere Except in Your Pipeline](https://www.coremodels.io/connector/jsonld/h4-ecosystem): You have already shipped JSON-LD, whether or not you think of it that way. It sits in the head of your marketing pages as structured data. It is how schema.org publishes its own vocabulary. It is the interchange shape for a great many knowledge graphs, research catalogs and public reference datasets, because it lets a document be plain JSON to an application developer and RDF to a triplestore at the same time.
- [A Field Name Is a Rumor](https://www.coremodels.io/connector/jsonld/h5-agents): Give a capable model two schemas and ask it to align them. It will produce a clean mapping table in seconds: name to full_name, status to state, created to one of the four fields called date. Most rows will be right — which is what makes the output dangerous. A mapping that is mostly right ships, and the rest becomes a data-quality incident with excellent grammar.
- [Zero to First Transform: Running a JSON-LD Vocabulary Through CoreModels](https://www.coremodels.io/connector/jsonld/t1-quickstart): By the end of this page you will have made exactly one HTTP call and produced two artifacts: a JSON Schema generated from an RDF vocabulary, and a lossiness ledger that states — in writing — what the conversion could not carry across. Learning to read both is the entire skill. Everything else in the CoreModels transform surface is a variation on this loop.
- [Four Verbs and a Vocabulary: The JSON-LD HTTP Surface, With Real Bodies](https://www.coremodels.io/connector/jsonld/t2-api): Everything you can do with an RDF vocabulary on the CoreModels HTTP API fits in four routes. One writes a vocabulary into a governed project, one publishes a project back out as a vocabulary, one converts statelessly through the mapping engine, and one replays a stored conversion. This article walks all four with request and response bodies we actually ran, then states the direction limits plainly — including the one that has no ledger entry to warn you about it.
- [Three Questions an Agent Must Answer After Converting a Schema](https://www.coremodels.io/connector/jsonld/t3-mcp): When an agent converts a vocabulary into something else, it should be able to answer three questions afterwards: what did it produce, what did it lose, and can it do that again identically? Most conversion tooling answers the first. The transform_schema tool on the CoreModels MCP server answers all three in a single call — the produced schema, an explicit lossiness ledger, and the executed plan as a replayable artifact. This article runs a JSON-LD vocabulary through it end to end, with the exact arguments and the exact response.
- [Boring on Purpose: JSON-LD Conversion Pipelines That Produce the Same Bytes Every Time](https://www.coremodels.io/connector/jsonld/t4-automation): A generated artifact is only trustworthy if it is boring. If regenerating last week's JSON Schema from the same vocabulary reshuffles keys, renames anonymous constructs, or quietly drops a constraint, then the diff in your pull request is noise and nobody reads it. This article is our recipe for the opposite: JSON-LD conversions that are byte-stable, gated by a reviewed plan, and loud when meaning is lost.
- [The Coder That Never Complains: A Full Accounting of JSON-LD Fidelity in CoreModels](https://www.coremodels.io/connector/jsonld/t5-deep-dive): Here is the fact that should make you suspicious: in either direction, the CoreModels JSON-LD coder emits no lossiness records at all. Not "few" — none. Most coders in the engine keep a list of things they apologize for; this one's ledger is empty. That is either an honest structural property or a place where losses hide, so this article is the accounting: what maps to what, what rides in the extras channel, what the @id contract guarantees, where fidelity breaks, and what the tests pin down.
- [Your JSON Schema Answers One Question. You Keep Asking It Four.](https://www.coremodels.io/connector/jsonschema/h1-need): The review comment that starts the trouble is always polite. *"Quick question — is this customer_id the same one the warehouse calls customer_key?"* The pull request adds two properties to a JSON Schema file. The author is fairly sure the answer is yes. Nobody can prove it from what is on the screen, because what is on the screen is a validator, and validators do not carry that kind of knowledge. The reviewer approves. The question stays open, and the next person to ask it will be an on-call engineer at an inconvenient hour.
- [The Week a Schema Change Stopped Being a Project](https://www.coremodels.io/connector/jsonschema/h2-outcomes): Add one property. That is the entire request: sales needs preferredChannel on the customer record, three allowed values, by Friday.
- [The Second Import Is Where Trust Is Won](https://www.coremodels.io/connector/jsonschema/h3-governance): Anyone can survive the first import. You feed a JSON Schema into a tool, something appears on the other side, and it looks broadly right. The interesting moment is the second — six weeks later, when the schema has changed, other people depend on the model, and a quiet alteration would propagate into a warehouse table, a partner contract, and a validation rule before anybody noticed.
- [Count the JSON Schemas You Used Today Without Noticing](https://www.coremodels.io/connector/jsonschema/h4-ecosystem): Before lunch you probably touched five of them. The request body in an API definition is JSON Schema. The configuration file that failed CI with a helpful message was validated against JSON Schema. If your team runs a schema registry, some of the subjects in it are JSON Schema rather than Avro. If you asked a model for structured output, the shape you asked for was JSON Schema. And if you used an AI assistant with tools, every one of those tool contracts — the argument names, the types, the required list — was JSON Schema too.
- [The Wrong Schema an Agent Writes Looks Exactly Like the Right One](https://www.coremodels.io/connector/jsonschema/h5-agents): Here is the failure mode that costs teams real time. You ask an assistant to draft a JSON Schema for the customer object it is about to integrate against, and it produces something clean: sensible property names, a tidy required array, an enum on the status field, format: "date-time" where a timestamp belongs. It looks like something your team would have written. It goes into a pull request and gets approved.
- [One Call, Three Answers: Your First JSON Schema Transform](https://www.coremodels.io/connector/jsonschema/t1-quickstart): Every transform call in CoreModels returns three things, and the third one is the reason we built it this way. You get the converted schema. You get the plan that produced it. And you get a ledger of everything the conversion could not carry across exactly — written in English, with a path pointing at the construct it happened to.
- [Four Routes and a Round Trip: JSON Schema Over HTTP](https://www.coremodels.io/connector/jsonschema/t2-api): A couple of format keys in the CoreModels transform surface are honest about being one-way. odm decodes only, because entity documentation is authored, not generated. synapse encodes only, and says so out loud when you try the other direction: *"'synapse' is encode-only: a Synapse schema is plain draft-07 JSON Schema — decode it with the 'jsonschema' format."*
- [Give an Agent a JSON Schema and a Target: transform_schema Over MCP](https://www.coremodels.io/connector/jsonschema/t3-mcp): An agent working on your repository will find a .schema.json file long before it finds your conversion documentation. What happens next depends entirely on the tools it can reach. Without one, it writes a converter, or worse, writes the target schema from scratch and presents its guesses with the same confidence as facts.
- [Same Plan, Same Bytes: Automating JSON Schema Conversion](https://www.coremodels.io/connector/jsonschema/t4-automation): A generator you cannot re-run and get identical output from is not a build step. It is a rumor with a timestamp. That is the practical objection to putting schema conversion in a pipeline: if today's run can differ from yesterday's for reasons nobody logged, then the generated Avro, the generated DDL, and the generated proto files are all provisional, and reviewing them is theater.
- [The Fidelity Contract: JSON Schema to IR and Back, Construct by Construct](https://www.coremodels.io/connector/jsonschema/t5-deep-dive): Every format coder in CoreModels has to answer the same awkward question: what do you do with the parts of a document you do not model? There are three bad answers — drop them, guess at them, or refuse the document — and one good one, which is to carry them untouched and be explicit about the handful of cases where carrying them is not enough.
- [Your LinkML Model Is Right. Your Pipeline Never Read It.](https://www.coremodels.io/connector/linkml/h1-need): The ticket that lands on a Monday morning rarely says "semantic drift." It says: *rows rejected, unexpected value in sex column.* Someone traces it back. Six weeks earlier a curator added a permissible value to an enum in the team's LinkML model, complete with a meaning URI pointing at a specific ontology term. The model was correct that day and has been correct every day since. The warehouse constraint, the JSON Schema the API validates against, and the Avro subject in the registry were each written by hand from an older reading of that file, and none of them heard about the change.
- [One Model, Every Downstream Format: What Governed LinkML Actually Buys You](https://www.coremodels.io/connector/linkml/h2-outcomes): The clearest sign that a team has adopted this is what has gone missing from their repository. The four hand-maintained schema files that used to shadow the LinkML model — a DDL script, a JSON Schema, an Avro subject definition, a catalog entry — are no longer there. Not stale, not deprecated, not marked "regenerate me." Gone, because they are outputs now.
- [Who Approved That Meaning? Governing a LinkML Model You Can Defend](https://www.coremodels.io/connector/linkml/h3-governance): Sooner or later somebody senior asks a question that sounds simple and is not: *how do you know the column in the warehouse means what the model says it means, and who decided that?*
- [LinkML Doesn't Need Us to Generate JSON Schema](https://www.coremodels.io/connector/linkml/h4-ecosystem): Start with the awkward fact; it is the honest way in. LinkML already ships a generator toolchain. If your entire need is "turn this model into a validation artifact," the project's own tooling does that, maintained by the people who write the specification, and you should keep using it. A product that opens by claiming otherwise is selling something.
- [The Expensive Kind of Wrong: Agents, LinkML, and Guessed Semantics](https://www.coremodels.io/connector/linkml/h5-agents): The costly failure of an AI agent working on schemas is not the one that errors out. It is the output that is perfectly well-formed and quietly invented — valid YAML, sensible field names, a plausible type for every slot, and three or four decisions nobody made. It passes review because it looks like the work, and fails in production.
- [LinkML to Postgres in One Call: A CoreModels Quickstart](https://www.coremodels.io/connector/linkml/t1-quickstart): Ten minutes, one YAML file, one HTTP call. By the end of this you will have converted a LinkML schema into Postgres DDL through CoreModels, read the machine-readable ledger of everything the conversion could not carry exactly, and sent the same schema back out as LinkML unchanged.
- [The LinkML HTTP Surface: Import, Export, Map, Replay](https://www.coremodels.io/connector/linkml/t2-api): There are ten routes on the CoreModels transform API. Five of them matter if LinkML is your source or your target, and the first thing to settle is which one you actually want — because the difference between them is not the format, it is whether anything gets written and who decides what passes through.
- [Give an Agent a LinkML Schema: `transform_schema` over MCP](https://www.coremodels.io/connector/linkml/t3-mcp): > Analyst: Here's our product catalog in LinkML. The warehouse team needs a Postgres table for it. What do we lose?
- [Plans, Not Scripts: Repeatable LinkML Conversion Pipelines](https://www.coremodels.io/connector/linkml/t4-automation): A conversion you cannot reproduce is not a pipeline; it is a favor someone did once. The interesting question for automation is not "can this tool turn LinkML into Postgres DDL" — it is "will the run in six months, on a build agent, with a token nobody remembers issuing, produce the same bytes and tell me if it did not."
- [Inside the LinkML Coder: Every Construct, Every Loss](https://www.coremodels.io/connector/linkml/t5-deep-dive): Start with one line of YAML:
- [The Schema You Never Wrote Down](https://www.coremodels.io/connector/neo4j/h1-need): A duplicate-node incident is one of the quietest failures in software. Nothing throws. No log line turns red. A MERGE (p:Person {email: $email}) runs a few hundred thousand times a day and, for eleven months, does exactly what everyone expects. Then a second ingestion path is added — this one merges on name, because that is what the upstream file happened to carry — and the graph starts growing two Person nodes where there used to be one. Traversals still return results. Dashboards still render. The number of people in the company just slowly stops being true.
- [Four Things That Exist Afterwards](https://www.coremodels.io/connector/neo4j/h2-outcomes): Adoption stories usually get told as a list of features. This one is easier to tell as an inventory: after a team wires CoreModels to their Neo4j instance, four artifacts exist that did not exist before, and almost everything that changes about the week is downstream of those four.
- [Read the Roles, Not the Brochure](https://www.coremodels.io/connector/neo4j/h3-governance): You can predict how a tool will behave inside your systems by reading which of its operations require which permission. Roles are enforced by code paths; brochures are not.
- [Count the Homes of One Entity](https://www.coremodels.io/connector/neo4j/h4-ecosystem): Pick a single entity in your organization — Customer, Patient, Instrument, whatever your domain calls the thing everything else hangs off — and count where it physically lives. In a serious estate the count is rarely below four. It is a label in Neo4j. It is a table in a warehouse. It is a subject in a schema registry. It is a model in a transformation project, a form in a capture system, a class in an application's JSON Schema.
- [Six Guesses Before the First Hop](https://www.coremodels.io/connector/neo4j/h5-agents): Ask an agent a question about your graph — "which companies do our top account contacts work for?" — and watch what it has to decide before it can write a single line of Cypher.
- [Your First Neo4j Schema Audit: A Complete Worked Example](https://www.coremodels.io/connector/neo4j/t1-quickstart): Take a small graph — three labels, a handful of properties, three relationship types. By the end of this article that graph has a governed model in CoreModels and a recorded baseline audit that tells you, in machine-readable form, exactly what is under governance and where the graph is structurally weak. Total effort: two Cypher statements and two HTTP calls.
- [The Neo4j Integration API, Route by Route](https://www.coremodels.io/connector/neo4j/t2-api): Ten routes, two surfaces, one rule about who is allowed to write. That is the core HTTP contract for governing a Neo4j estate with CoreModels, and this article documents it exhaustively — payloads, roles, response shapes, and the failure modes you will actually hit.
- [Four Tools, One Knowledge Graph: Neo4j Governance from the Agent Side](https://www.coremodels.io/connector/neo4j/t3-mcp): An AI agent connected to CoreModels over MCP sees a small, deliberately shaped set of vendor-integration tools. Three of them cannot write anything at all; the fourth requires Admin membership on the project *and* a different endpoint. That shape is the point of this article: an agent can drive the entire Neo4j governance loop — discover, audit, report, generate the fix — while the only mutating step in the loop stays behind an explicit privilege boundary.
- [Automating Neo4j Drift Control: The Gate, the Trail, the Badge, the Heartbeat](https://www.coremodels.io/connector/neo4j/t4-automation): Most CI integrations start with an artifact the build already produces. Neo4j does not produce one — there is no compile step for a property graph, no manifest, no migration file that reviewers can read. So the first job in automating Neo4j governance is not writing the gate. It is deciding where meta_schema.json comes from in your pipeline.
- [Projecting a Property Graph onto a Governed Model: Inside the Neo4j Connector](https://www.coremodels.io/connector/neo4j/t5-deep-dive): CoreModels has one estate model and every vendor parses into it: datasets (table-shaped things) with fields and normalized checks, plus lineage edges and projections. A dbt project, a warehouse schema, and a schema registry all land in the same shape.
- [The Cheapest Way to Break a Data Contract Is to Retype It](https://www.coremodels.io/connector/odcs/h1-need): Here is one property from an ordinary data contract, written in the Open Data Contract Standard:
- [The Meeting That Stops Happening](https://www.coremodels.io/connector/odcs/h2-outcomes): The clearest measure of a governance tool is not a feature list. It is a meeting that falls off the calendar.
- [Seven Things Our ODCS Support Refuses to Do](https://www.coremodels.io/connector/odcs/h3-governance): We could describe how CoreModels handles data contracts as a list of capabilities. It is more useful to describe it as a list of refusals, because in governance the interesting question is never what a tool can do. It is what the tool will not do to your document when nobody is watching.
- [ODCS Is Not Competing With Your Schema Format](https://www.coremodels.io/connector/odcs/h4-ecosystem): A question we get early in most conversations: "If we adopt ODCS, do we stop using JSON Schema?"
- [The Fine Print Is Where Agents Fail](https://www.coremodels.io/connector/odcs/h5-agents): Every data contract has a headline and a fine print. The headline is the list of columns and their types; any competent reader gets that right. The fine print is the rest: that this primary key is explicitly required: false; that this column is classified restricted and has an encrypted counterpart; that the quality check on the amount column demands a null count of exactly zero at error severity.
- [One Contract, Three Schemas: An ODCS Quickstart](https://www.coremodels.io/connector/odcs/t1-quickstart): A data contract is a promise with a schema inside it. The ODCS documents your platform team publishes — Open Data Contract Standard, the Bitol project's v3 line — carry tables and columns, but also servers, quality checks, SLAs, ownership: everything the promise needs and most target formats cannot hold. This quickstart takes one real contract through a single CoreModels call three times — to JSON Schema, to SQL, and back to ODCS — and shows you how to read what each conversion kept, what it set aside, and where the set-aside parts went.
- [ODCS Over HTTP: The Transform Routes for Data Contracts](https://www.coremodels.io/connector/odcs/t2-api): Direction first, because we publish it per format and it decides what you can build. The format key odcs appears in both of CoreModels' transform lists — decode (jsonschema | shex | avro | jsonld | sql | osi | osi-json | owl | linkml | protobuf | odcs | odm) and encode (jsonschema | shex | avro | jsonld | sql | osi | osi-json | owl | linkml | protobuf | odcs | synapse). ODCS round-trips. Its neighbors do not all manage that: odm decodes only (ODM entities are authored documentation, and we do not generate prose), and synapse encodes only (its output is plain draft-07 JSON Schema — re-import it as jsonschema). What odcs means here is a Bitol Open Data Contract Standard v3 document — apiVersion: v3.1.0, kind: DataContract — as YAML or JSON.
- ["Turn Our Data Contract Into an Avro Schema": ODCS Through `transform_schema`](https://www.coremodels.io/connector/odcs/t3-mcp): "The platform team publishes the orders contract — can you make the Avro schema for the streaming team?" That sentence, said to an agent with no tools, produces plausible-looking .avsc with invented decisions baked in. Said to an agent connected to CoreModels over MCP, it becomes a call to transform_schema: a deterministic engine does the conversion, and the agent gets back the schema, the executed plan, and a machine-readable account of what the trip cost. This article is the complete loop for ODCS — connection, the exact tool contract, two real conversions, and the contract-specific habits that separate a good agent from a confident one.
- [The Contract Pipeline Is a Plan File: Automating ODCS With Replay](https://www.coremodels.io/connector/odcs/t4-automation): Automation is where schema tooling usually stops being honest. A conversion that a human runs once gets its output eyeballed; the same conversion in a nightly job gets trusted. So the two properties that matter most for automating data contracts are not features, they are guarantees: CoreModels transforms are deterministic — the same contract in produces byte-identical output every run, which makes diffs a real review surface — and every mapping executes from a plan that comes back in the response as JSON you can commit, review, and replay. This article builds an ODCS pipeline on those guarantees: a published subset of an internal contract, regenerated on every change, with drift caught by the engine instead of by a consumer.
- [Anatomy of the ODCS Coder: What Maps, What Rides, What's Declared](https://www.coremodels.io/connector/odcs/t5-deep-dive): Where does servers: go?
- [Transcription Is Where Conformance Goes to Die](https://www.coremodels.io/connector/odm/h1-need): Open almost any codebase that claims to follow an open data standard and, sooner or later, you find the file. It sits in a schemas/ folder, named something like customer.schema.json, and near the top there is a comment: *adapted from the MACH ODM entity definition*. No version. No date. No link back to the source. Somebody, once, working against a deadline, read a published entity document and typed out what they believed it said.
- [A Revision Lands: The Open Data Model on Working Terms](https://www.coremodels.io/connector/odm/h2-outcomes): Standards adoption is usually described in terms of intent: we align with the Open Data Model, our partners can integrate faster. Those sentences are cheap. The useful question is narrower and more revealing: when a revision to an entity document is published on an ordinary weekday morning, what does your team actually do?
- [Two Verbs and a Dry Run: Governing a Standard You Do Not Own](https://www.coremodels.io/connector/odm/h3-governance): Our ODM surface has exactly two verbs, and the distance between them is the entire governance argument.
- [The Composable Stack's Missing Noun](https://www.coremodels.io/connector/odm/h4-ecosystem): Assemble a modern commerce or content platform the MACH way — microservices-based, API-first, cloud-native, headless — and you get the promised benefits almost immediately. Best-of-breed everywhere. Vendors swappable in principle. No monolith to renegotiate every five years.
- [Two Ways to Answer a Question About the Standard](https://www.coremodels.io/connector/odm/h5-agents): Someone drops a question into a channel: *does the Open Data Model require an external identifier on the customer entity, or is it optional?* An AI assistant watching the channel answers in four seconds, in complete sentences, with a confident field list.
- [Your First MACH ODM Transform: Markdown In, JSON Schema Out](https://www.coremodels.io/connector/odm/t1-quickstart): The MACH Alliance publishes its Open Data Model (ODM) as entity documentation: Markdown files with prose, a field table, embedded YAML schema definitions, and sample objects. That is a great format for humans and a frustrating one for machines — you cannot validate a payload against a Markdown page.
- [MACH ODM over HTTP: One Converter, Two Importers, and an Honest "No Export"](https://www.coremodels.io/connector/odm/t2-api): Every schema format on the CoreModels transform surface declares its direction, and we hold ourselves to those declarations in public. The odm format — MACH Alliance Open Data Model entity documents — is decode-only: ODM entities are authored documentation, not a generated artifact, so there is no encode back to prose. Rather than paper over that, the HTTP surface is built around it. This article walks the complete set of routes that touch ODM, with real request and response bodies, the role each route requires, and exactly what happens when you try the direction that does not exist.
- [Converting MACH ODM Entities with an Agent: transform_schema over MCP](https://www.coremodels.io/connector/odm/t3-mcp): Picture the request as it actually arrives: someone pastes a MACH Alliance Open Data Model entity document into a chat and asks their agent, "stand up a Postgres table for this." The document is Markdown — an H1, some prose, YAML blocks inside a schema section. Between that paste and a CREATE TABLE statement sits exactly one tool call.
- [ODM at Scale: Batch Conversion, Deterministic Pipelines, and Replayable Plans](https://www.coremodels.io/connector/odm/t4-automation): One entity document is a demo. A standards repository is dozens of them — identity, product, inventory, pricing — revised by pull request, consumed by teams who need formal schemas, not Markdown. The moment MACH Open Data Model documents become an input to your build, three engineering questions appear: can the conversion run unattended, will the same input always produce the same output, and what happens when one file in the batch is broken?
- [Inside the MACH ODM Coder: What Maps, What Rides Along, What Gets Reported](https://www.coremodels.io/connector/odm/t5-deep-dive): A MACH Alliance Open Data Model entity document is five things wearing one Markdown file: an H1 that names the entity, an ## Entity purpose section of prose, an ## Object table with normative practice levels, a ## YAML Schema Definition section holding the actual schema, and a ## Sample Object. The CoreModels odm coder reads all five — and this article is the precise account of where each one lands, what travels as annotation rather than structure, which situations produce lossiness records, and why this format is the one place in our lineup where round-trip is deliberately not the goal.
- [Two Numbers, One Word](https://www.coremodels.io/connector/osi/h1-need): Someone puts a slide on the screen: revenue for the quarter, from the finance dashboard. Someone else has the same metric open in a notebook, sourced from the warehouse, and the figure differs by a little under two percent. Both are right, in the sense that each number is exactly what its definition says it is. One nets out returns; the other does not.
- [A Tuesday With a Governed Semantic Model](https://www.coremodels.io/connector/osi/h2-outcomes): The clearest way to describe an after-state is to walk through an ordinary day in it. Nothing dramatic happens on this Tuesday; that is the point. Here is the day, with the before-state noted each time, for a team whose Apache Ossie semantic model is a projection of a governed graph rather than a file inside one tool.
- [A Definition Is a Privileged Change](https://www.coremodels.io/connector/osi/h3-governance): There is a sentence in our own API documentation that decides how the whole surface behaves: *"success: true does not mean 'nothing changed.' It means 'it ran.' Always read lossiness."*
- [The Missing Artifact](https://www.coremodels.io/connector/osi/h4-ecosystem): Take the modern data stack layer by layer and ask one question of each: can I have that as a file?
- [What an Agent Decides Before It Answers](https://www.coremodels.io/connector/osi/h5-agents): Ask an AI agent connected to a bare warehouse what revenue was last week, and watch the decisions it makes before writing a line of SQL.
- [Ten Minutes to Your First Apache Ossie Transform](https://www.coremodels.io/connector/osi/t1-quickstart): A semantic model lands in your repository: a YAML file with datasets, fields, a primary key, and a couple of time dimensions. It is the analytics team's description of what the warehouse *means*. Now somebody needs it as a table definition, or as JSON Schema for a validator, or as the JSON serialization dbt ingests. This walkthrough takes you from that file to a converted schema with one HTTP call — and, just as importantly, to a machine-readable ledger of everything the conversion did and did not preserve.
- [The Ossie HTTP Surface: Import, Export, Map, Replay](https://www.coremodels.io/connector/osi/t2-api): Four verbs cover everything you will do with an Apache Ossie semantic model through the CoreModels API, and picking the right one is mostly a question of *where the schema lives*. Is it a file you have? Import it, or map it statelessly. Is it a governed model in a CoreModels project? Export it. Do you need the same conversion again next month, byte for byte? Replay a stored plan.
- ["Convert Our Semantic Model for dbt" — Ossie Through the transform_schema Tool](https://www.coremodels.io/connector/osi/t3-mcp): Here is the request, as an analyst actually phrases it: *"Take the billing semantic model in our repo, give me the JSON form our dbt project ingests, and tell me what didn't survive the conversion."*
- [Ossie Conversions That Belong in CI: Plans as Artifacts, Ledgers as Gates](https://www.coremodels.io/connector/osi/t4-automation): Run an Ossie conversion twice and diff the two outputs. If the bytes differ, the conversion cannot live in a pipeline — you would be re-reviewing generated files every build. CoreModels (by ARAMAI) gives you the other answer, and it comes from three deliberate design choices: the encoder is hand-written with fixed key order, the mapping plan is returned as an artifact you can store, and replaying a stored plan runs the same validation gate as the call that produced it.
- [Every Key, Every Record: How the Ossie Coder Maps to the IR](https://www.coremodels.io/connector/osi/t5-deep-dive): An Apache Ossie semantic model and a typed intermediate representation disagree about the world in one fundamental way: an Ossie field has no type. It is a name, an optional expression, an optional description, and optional dimension metadata. The IR that CoreModels (by ARAMAI) moves schemas through is typed, and so is every neighboring format — SQL, Avro, JSON Schema, LinkML.
- [Two Truths About "Person": Why Ontologies and Application Schemas Drift Apart](https://www.coremodels.io/connector/owl/h1-need): Somewhere in your organization there are two documents that both claim to define a person. One is an OWL ontology, lovingly curated in Protégé by someone who understands description logic: Person is a class, name is a datatype property, there are equivalences to schema.org and careful subclass axioms. The other is the schema your applications actually run on — a JSON Schema, a set of CREATE TABLE statements, an Avro record — written by engineers who have never opened a Turtle file and never will.
- [The Day the Ontology Became a Build Artifact](https://www.coremodels.io/connector/owl/h2-outcomes): Tuesday, 9:40 a.m. A message arrives from the knowledge-graph team: "We're loading the reference data into GraphDB this sprint. Can you send us an ontology for the content model?" Six months ago that message would have started a two-week side project. Today the modeler it lands on opens the CoreModels project that already governs the content model, makes one export call with format: "owl", and posts the resulting Turtle file back before her coffee is cold. It loads into GraphDB without edits. It loads into Protégé without edits. The reasoner accepts the cardinality axioms as axioms.
- [The Confession at the Top of the File: Governance Through the OWL Round Trip](https://www.coremodels.io/connector/owl/h3-governance): Open an ontology exported from CoreModels and, before any prefix declaration, you may find something unusual: a block of comment lines beginning # lossiness:. Each one names a kind of change, the exact path in the model where it happened, and a plain-English explanation of what the export could not carry. Comments are valid Turtle, so the file still loads cleanly into GraphDB or Protégé — but anyone who opens it reads the confession first.
- [A Field Guide to the Stack Beneath OWL — and Why We Keep Our Turtle Vanilla](https://www.coremodels.io/connector/owl/h4-ecosystem): OWL is not one standard; it is the top floor of a building. At the foundation sits RDF, the data model in which everything is a triple — subject, predicate, object — and every named thing is an IRI. Above it, RDFS adds the basic schema vocabulary: classes, properties, domains, ranges, subclass relations. OWL adds the expressive machinery on top — equivalences, restrictions, unions, the constructs a reasoner can actually reason over. Beside the tower stands SKOS, the W3C vocabulary for thesauri and controlled vocabularies: concepts, schemes, broader/narrower hierarchy, preferred labels. And Turtle is none of these — it is simply the friendliest syntax for writing any of them down, the serialization humans actually read.
- [Axioms Beat Sample Data: What OWL Support Means for AI Agents](https://www.coremodels.io/connector/owl/h5-agents): Ask an AI agent to integrate with a system it has never seen, and watch what it does: it requests a few sample records and starts inferring. Three JSON documents in, it has decided that email is always present (it appeared in all three), that tags is a scalar (each sample happened to have one), and that status takes two values (it saw two). Every one of those conclusions is a guess dressed as knowledge, and every one can be wrong in ways that surface weeks later as a production incident.
- [Turtle In, JSON Schema Out: Your First OWL Transform](https://www.coremodels.io/connector/owl/t1-quickstart): There is a .ttl file somewhere in your repository. Someone modeled the domain properly once — classes, subclass axioms, cardinality restrictions, a SKOS scheme for the controlled list — and then everyone else carried on hand-writing JSON Schema and DDL, because nothing bridged the two.
- [OWL Over HTTP: Export, Import, Map, Replay](https://www.coremodels.io/connector/owl/t2-api): Two questions decide whether a format is really supported: can the system read it, and can the system write it? For the owl format key in CoreModels the answer is yes to both, and this article is the proof — four routes, real request bodies, real responses, and the direction rules stated without hedging.
- [Ontology Alignment You Can Delegate: `transform_schema` and OWL Over MCP](https://www.coremodels.io/connector/owl/t3-mcp): A partner sends you their vocabulary as a Turtle file. You need your catalog expressed in their terms so the two sides can exchange data, and you need a record of which of your concepts had no counterpart on their side. That used to be an afternoon in an ontology editor plus a spreadsheet nobody trusts.
- [Infer Once, Gate Always, Replay Forever: OWL in a Build Pipeline](https://www.coremodels.io/connector/owl/t4-automation): Commit an exported ontology, re-run the export tomorrow, and look at the diff. If it shows reordered prefixes and reshuffled blocks, the export is not a build artifact — it is a rumor, and no reviewer will read it twice. If it shows exactly the statements your model changed, you have something CI can gate on.
- [What the OWL Coder Knows: The IR Map, the Extras, the Ledger](https://www.coremodels.io/connector/owl/t5-deep-dive): Ask a schema converter what it does with owl:Restriction and you learn most of what you need to know about it. Many treat OWL as a serialization problem — emit classes and properties, drop the axioms — so "required" and "single-valued" evaporate at the border. CoreModels treats it as a semantics problem: required and cardinality ride as owl:Restriction subclass axioms, OWL's own carrier, in both directions. That decision propagates through everything below.
- [The Field Number Nobody Wrote Down](https://www.coremodels.io/connector/protobuf/h1-need): A team retires a field. It has been dead for a year, nothing reads it, and the pull request that removes it is three lines long and gets approved in under a minute. Months later somebody adds a new field and takes the next number that looks free — the same one. Both changes were correct on their own. Together they mean an older client and a newer one now disagree about what a stretch of bytes says, and the disagreement surfaces as a value that is quietly wrong somewhere nobody is watching.
- [What Your Service Team Stops Being Asked](https://www.coremodels.io/connector/protobuf/h2-outcomes): Every team that owns a .proto file also owns an unpaid second job: being the interpreter for it. The requests arrive individually, each one reasonable, each one costing an afternoon. Can we get the order model as tables? The partner needs this as JSON Schema by Thursday. Which of these fields are actually required? Can you add a discount field without breaking the mobile clients?
- [Put the Generated .proto in a Pull Request](https://www.coremodels.io/connector/protobuf/h3-governance): That is the test. Not a feature list, not a pipeline diagram — a reviewer, a diff, and a wire contract other people's clients depend on. If a governance layer cannot survive that moment, everything upstream of it is decoration.
- [Good Neighbors: proto3 Among the Formats It Has to Live With](https://www.coremodels.io/connector/protobuf/h4-ecosystem): Protocol Buffers was designed for a conversation between two running programs. Everything distinctive about it follows from that: the compactness, the field numbers, the fanatical attention to what happens when one side upgrades before the other. It is a contract about bytes in flight, and it is very good at being one.
- [Fluent, Confident, and Wrong: Grounding Agents in Real proto3](https://www.coremodels.io/connector/protobuf/h5-agents): Ask a capable model to write the .proto for your order service and you will get a file that compiles. Idiomatic names, an enum with a zero-valued UNSPECIFIED member because that is the convention, a google.protobuf.Timestamp for the placed-at field, numbers counting up from one. It will look like something a good engineer wrote on a good day.
- [Ten Minutes With proto3: Your First CoreModels Transform](https://www.coremodels.io/connector/protobuf/t1-quickstart): You have a .proto file. It is the truth for a service, and now somebody outside that service needs the same shape — as JSON Schema for a validation step, as a data contract for a review, as a table for analytics. The usual answer is to retype it. This article replaces the retyping with one HTTP call, and then spends most of its length on the part that matters more: reading what the conversion cost you.
- [The Transform API for proto3: Four Routes, Both Directions](https://www.coremodels.io/connector/protobuf/t2-api): Most schema converters are one-way. You can get *out* of the format or *into* it, rarely both, and the documentation usually leaves you to discover which by trying. So let us answer the direction question for Protocol Buffers first and in one sentence: proto3 decodes and encodes. The key protobuf (alias proto) appears in both the decode list and the encode list, so it is valid as a source and as a target on every route below.
- [Handing proto3 to an Agent: transform_schema over MCP](https://www.coremodels.io/connector/protobuf/t3-mcp): "Take our telemetry .proto and give me the Postgres table for it — and tell me what we lose."
- [Deterministic proto3 Pipelines: The Plan Is the Artifact](https://www.coremodels.io/connector/protobuf/t4-automation): A conversion you run once is a favor. A conversion you run on every commit is infrastructure, and infrastructure needs two properties that one-off tooling never has to prove: the second run must produce the same bytes as the first, and when the input changes in a way the conversion cannot honor, the pipeline must stop rather than quietly produce something different.
- [Inside the proto3 Coder: The IR Mapping, the Extras, and Every Lossiness Record](https://www.coremodels.io/connector/protobuf/t5-deep-dive): Proto3 has fifteen scalar types. A neutral intermediate representation that also hosts JSON Schema, SQL, Avro, LinkML, OWL, and half a dozen other formats cannot afford fifteen distinct numeric primitives, and any tool that claims otherwise is hiding something. The arithmetic settles the question up front: some proto3 facts map structurally, some ride alongside as preserved detail, and some are declared as loss. This is the complete account, in that order.
- [Nobody Diffs the Codebook](https://www.coremodels.io/connector/redcap/h1-need): Somewhere in the second year of a study, a monitoring meeting stalls on a question that should be trivial: was the systolic blood pressure field always integer-validated, or did that change after the pilot?
- [Six Questions Your REDCap Project Can Suddenly Answer](https://www.coremodels.io/connector/redcap/h2-outcomes): Ask a team what changed about their REDCap work after putting a project under governance, and the honest answer is: nothing. They still design instruments in REDCap. They still enroll participants, still branch, still export. Nobody handed over an API token, and nothing outside the team ever writes to the instance.
- [The Powers We Deliberately Did Not Take](https://www.coremodels.io/connector/redcap/h3-governance): A tool that governs a research study's schema could be given a great deal of authority. It could hold an API token and read the project directly. It could reconcile your model to the latest upload automatically. It could push corrected instruments back into REDCap. Each of those would demo well.
- [The Dictionary Travels Further Than the Data](https://www.coremodels.io/connector/redcap/h4-ecosystem): A REDCap data dictionary gets around. It is emailed to a collaborating site so they can stand up the same instruments. It is attached to a protocol so a reviewer can see what is being collected. It is handed to a statistician who needs the codebook, to an engineer who needs to build a load, to the next study that wants to reuse a validated instrument. The participant data stays behind an access committee. The dictionary circulates freely, because it carries meaning rather than records.
- [The Agent Cannot Tell Which Column Is the Key](https://www.coremodels.io/connector/redcap/h5-agents): Give a capable AI assistant two REDCap exports and ask it to join them. Watch what it has to do.
- [REDCap to CoreModels: Zero to First Audit with One CSV](https://www.coremodels.io/connector/redcap/t1-quickstart): Most schema estates take real work to extract: information-schema queries, catalog exports, manifest builds. A REDCap project is the pleasant exception — the entire schema estate is one stable file, the data dictionary CSV, and you almost certainly already know how to download it. That makes the distance from "nothing governed" to "first drift audit" unusually short. This tutorial walks the whole distance: export the dictionary, import it into a governed CoreModels project, run your first audit, and read what comes back. No REDCap credentials are ever shared with CoreModels at any point.
- [Every REDCap Route in CoreModels: the Full HTTP Reference](https://www.coremodels.io/connector/redcap/t2-api): The CoreModels REDCap connector declares all three capabilities — Import, Audit, Generate — which means every integration verb on our HTTP surface is live for it. This article is the complete route-by-route reference: what each endpoint takes, what it returns, which role it requires, and which of the two HTTP surfaces it lives on. If you're writing a script, a service, or an internal tool against the REDCap integration, this is the page to keep open.
- [Give Your Agent the Dictionary: REDCap Governance over MCP](https://www.coremodels.io/connector/redcap/t3-mcp): When the caller is an AI agent rather than a shell script, the interesting question stops being "what's the route?" and becomes "what is the agent allowed to know, and what is it allowed to do?" CoreModels answers that with an MCP server whose vendor-integration tools mirror our HTTP surface exactly — same audit engine, same additive import, same read-only posture — but packaged as typed tools an agent can discover, reason about, and chain. This article walks the four tools that matter for REDCap, with the real arguments, and shows the pattern we recommend for agents that govern clinical research schemas: discover, audit, and only then (with a human's admin endpoint) import.
- [The Dictionary Changed on a Tuesday: CI Drift Gates for REDCap](https://www.coremodels.io/connector/redcap/t4-automation): REDCap's greatest operational strength is also its governance problem: a data manager with the right permissions can change a production instrument in minutes. A validation type quietly switches from integer to plain text, a choice list gains a code, a required flag disappears — and every downstream extract, harmonization script, and statistical pipeline inherits the change without a review. The fix isn't to slow REDCap down. It's to make the data dictionary a versioned, gated artifact like any other piece of production configuration. This article builds that gate with CoreModels: a CI audit that fails on drift, a status badge, a rolling history, one-call re-audits, and the scheduled heartbeat that catches drift nobody pushed.
- [Inside the REDCap Connector: How a Data Dictionary Becomes a Governed Graph](https://www.coremodels.io/connector/redcap/t5-deep-dive): To trust a governance tool you should be able to predict what it does with your data — row by row, column by column. This deep dive opens the hood on the CoreModels REDCap connector: how the data dictionary CSV is parsed, how each REDCap concept lands in the governed graph, which facts ride vendor metadata rather than governed meaning, what triggers each audit rule, and precisely where the mapping is lossy.
- [It Takes About Forty Seconds to Change What a Salesforce Field Means](https://www.coremodels.io/connector/salesforce/h1-need): Setup. Object Manager. Pick a field. Edit the picklist. Save.
- [A Week With a Governed Salesforce Org](https://www.coremodels.io/connector/salesforce/h2-outcomes): "Has anything in the org drifted from what we agreed?"
- [Governing a Salesforce Org You Never Let Us Touch](https://www.coremodels.io/connector/salesforce/h3-governance): A governance tool pointed at your CRM is asking for a lot of trust. Your Salesforce org holds the pipeline, the customer list, and the revenue numbers; any tool that wants to "govern" it should have to say, precisely, what it will and will not do. So before we describe what the CoreModels Salesforce integration does, here is what it refuses to do — because the trust story is the product.
- [Account Is Not a Salesforce Object — It's a Business Concept With a Salesforce Copy](https://www.coremodels.io/connector/salesforce/h4-ecosystem): Trace one entity through a typical stack. *Account* starts life as an sObject in a Salesforce org. A sync pipeline copies it into the warehouse, where it becomes a table. A transformation layer reshapes it into curated models. An event stream carries account changes to other services under a registered schema. Four systems, four technical dialects — and one business meaning that no single system owns.
- [When an AI Agent Meets Your Salesforce Org, It Guesses — Unless You Give It the Model](https://www.coremodels.io/connector/salesforce/h5-agents): Ask an AI agent to write an integration against your Salesforce org — a validation script, a sync mapping, a report definition — and watch what it does with Status__c. It will guess. It has seen ten thousand orgs' worth of training data, so the guess will be fluent: plausible picklist values, a plausible type, a plausible relationship to Account. Fluent, plausible, and wrong, because your org is not the average org. It is fifteen years of customization, custom objects, repurposed standard fields, and picklists whose real values live in a settings page the agent has never seen.
- [Governing a Salesforce Org in an Afternoon: From describe.json to Your First Drift Audit](https://www.coremodels.io/connector/salesforce/t1-quickstart): Somewhere in your org, last quarter, somebody edited a picklist. Nobody remembers who, the field history doesn't say why, and the report that broke three weeks later never mentioned it at all. Salesforce makes schema change wonderfully easy — and makes *remembering what the schema is supposed to mean* entirely your problem.
- [Seven Verbs and Two Surfaces: The Complete Salesforce Integration API](https://www.coremodels.io/connector/salesforce/t2-api): Before writing a single call, it pays to see the whole map. The Salesforce integration in CoreModels (vendor key salesforce) is small enough to hold in your head: the seven core per-vendor verbs on the interactive HTTP surface, two on the machine-to-machine surface, one artifact, and two roles. The connector declares all three capabilities — Import, Audit, Generate — so every verb below is live for Salesforce; nothing in this reference is aspirational.
- ["Did the Org Drift?" — Running Salesforce Governance Through an AI Agent](https://www.coremodels.io/connector/salesforce/t3-mcp): Watch an agent handle a governance request end to end. A data engineer types: *"Here's this week's describe export — check whether the Salesforce org still matches the governed model, and summarize anything that changed."* The agent calls one tool, reads back structured findings plus a ready-made markdown report, and answers with specifics: which object, which field, which severity. No dashboard visit, no memorized route, no guessing.
- [The Build Goes Red Before the Org Goes Wrong: A Salesforce Drift Gate in CI](https://www.coremodels.io/connector/salesforce/t4-automation): Schema governance that lives in a wiki dies in a wiki. The only governance that survives contact with a delivery team is the kind wired into the pipeline — a check that runs on every change, fails loudly when meaning breaks, and costs nothing to keep passing. This article wires that check up for Salesforce with CoreModels: a CI job that audits a fresh describe export against the governed model, a one-line pass/fail contract, a status badge, a rolling evidence trail, and the two mechanisms that cover what CI cannot see.
- [Anatomy of a Governed Org: How Salesforce Metadata Maps into the CoreModels Graph](https://www.coremodels.io/connector/salesforce/t5-deep-dive): A drift audit is only as trustworthy as the mapping underneath it. If an import flattens your org into undifferentiated strings, the audit can only ever tell you undifferentiated things. So this article opens the hood on the CoreModels Salesforce connector: what each describe property becomes in the governed graph, which platform semantics survive the crossing, which are approximated — and how every approximation is declared rather than hidden.
- [Four Facts in a Line: What Hand-Copied Shapes Throw Away](https://www.coremodels.io/connector/shex/h1-need): Read one triple constraint out of a ShExC file: a predicate, a value constraint, a cardinality marker, a semicolon. It looks like a field declaration. It is denser than that.
- [Tuesday, 09:40: A Week in Which Shapes Are Just Another Export](https://www.coremodels.io/connector/shex/h2-outcomes): The clearest way to describe an after-state is to timestamp it. Here is a week in a team that has stopped maintaining a second copy of its model — where a partner's shapes are an input, the warehouse DDL is an output, and the return submission is a diff. Nothing here is heroic. That is the point.
- ["Success" Means It Ran: The Trust Contract Around a ShEx Conversion](https://www.coremodels.io/connector/shex/h3-governance): There is a sentence in our own transform documentation that we treat as a design constraint rather than a caveat: a successful response does not mean nothing changed — it means it ran.
- [Two Questions That Sound Alike: Where ShEx Sits, and Why We Take No Side](https://www.coremodels.io/connector/shex/h4-ecosystem): "What does this term mean?" and "what must a conforming record contain?" sound like one question. They are two, answered by different artifacts, and confusing them is why so many schema discussions go in circles.
- [Ask Where the Answer Came From: ShEx as an Agent's Source of Truth](https://www.coremodels.io/connector/shex/h5-agents): Ask an AI agent what values the status field can hold, and it will answer. The interesting question is not whether the answer is right. It is where the answer came from.
- [ShEx in Ten Lines: Your First CoreModels Transform](https://www.coremodels.io/connector/shex/t1-quickstart): The shortest useful thing you can do with CoreModels and ShEx takes one HTTP call, writes nothing to your project, and hands back three things: the converted schema, a replayable plan, and an honest ledger of everything the conversion could not carry across. This walkthrough runs that call twice — once into JSON Schema, once into Postgres DDL — and shows you how to read all three parts of the answer.
- [The ShEx HTTP Surface: Import, Export, Map, and Replay](https://www.coremodels.io/connector/shex/t2-api): Five HTTP endpoints carry ShEx through CoreModels, and they are the same five that carry every other schema format we support — nothing about ShEx is a special case on the wire. What changes is one string: the format key shex. This article is the contract reference for that surface: exact routes, request and response bodies, roles, options, and the honest statement of what each direction can and cannot do.
- [Agent-Driven ShEx Conversion with the transform_schema MCP Tool](https://www.coremodels.io/connector/shex/t3-mcp): "The ontology team published ShEx shapes for the product catalog. Give me the JSON Schema our validation service needs, and tell me exactly what didn't survive the trip."
- [ShEx in the Pipeline: Deterministic Transforms, Replayable Plans, Batch Conversion](https://www.coremodels.io/connector/shex/t4-automation): A schema conversion you cannot reproduce is a liability with a timestamp on it. If your ShEx shapes are converted to JSON Schema by hand, or by a script whose behavior depends on who runs it and when, then the day the outputs disagree you have no way to say *which* conversion was right. We built the CoreModels transform surface so that conversion can live in a pipeline like any other build step: deterministic outputs, a reviewable plan artifact you can commit next to your shapes, and a change report you can gate a build on. This article shows the working patterns for ShEx (format key shex).
- [Inside the ShEx Coder: The IR Map, the Extras Ledger, and What Round-Trips](https://www.coremodels.io/connector/shex/t5-deep-dive): Most schema formats name things locally: a SQL column is full_name, an Avro field is full_name, and any connection to the wider world has to be bolted on with annotations. ShEx arrives different. Its predicates and shape names are IRIs — schema:name *is* https://schema.org/name — which means a ShEx document carries its cross-standard identity in its bones. Our ShEx coder in CoreModels, by ARAMAI, is built around that fact, and this article is the full technical account of it: exactly what maps into our intermediate representation (IR), what rides in the preserved-extras ledger, every lossiness record the coder can emit, and precisely what survives a round trip.
- [Your Snowflake Schema Is Not a Contract](https://www.coremodels.io/connector/snowflake/h1-need): Picture a failure every data team has met. The revenue dashboard didn't crash. That would have been kinder. Instead it kept rendering, quietly wrong, for eleven days — because a column that had always carried a two-decimal number was rebuilt upstream as text, and everything downstream coerced, rounded, or dropped what it couldn't parse. No alert fired. No reviewer saw it coming. The warehouse did exactly what it was told, because a warehouse's job is to store structure, not to defend meaning.
- [A Week in the Life of a Governed Snowflake Estate](https://www.coremodels.io/connector/snowflake/h2-outcomes): Forget the sales pitch for a moment. Here is what an ordinary week looks like for a data engineer whose Snowflake estate is governed with CoreModels — nothing heroic, just the same work with the guesswork removed.
- [Read-Only by Design: The Trust Model Behind CoreModels for Snowflake](https://www.coremodels.io/connector/snowflake/h3-governance): Governance tools lose trust in predictable ways: they demand credentials to your most valuable system, they "helpfully" rewrite things nobody asked them to touch, they paper over what they couldn't represent, and one day they act on your infrastructure without a human in the loop. We designed the CoreModels Snowflake integration against that failure list, promise by promise. This article is the trust story, stated plainly enough to be falsifiable.
- [One Table, Five Tools: Where Snowflake Sits in a Governed Estate](https://www.coremodels.io/connector/snowflake/h4-ecosystem): Pick one table in your warehouse — say ANALYTICS.PUBLIC.ORDERS — and list everything that has an opinion about it. An ingestion tool like Airbyte landed its raw ancestor. A dbt model transformed and materialized it, and dbt's manifest describes it in dbt's vocabulary. Airflow schedules the job that refreshes it. A Kafka topic with an Avro schema in a Confluent registry mirrors half its fields to another team. Snowflake's own INFORMATION_SCHEMA describes its physical shape. Five tools, five metadata dialects, five partial and slowly diverging descriptions of one thing.
- [Stop Letting Your AI Agent Guess What Your Snowflake Columns Mean](https://www.coremodels.io/connector/snowflake/h5-agents): Ask a capable AI agent to "join orders to customers" in a warehouse it has never seen, and watch what it actually does: it reads column names and guesses. CUSTOMER_ID probably matches ID on the customers table. STATUS probably takes values like 'active'. That JSON blob in PAYLOAD probably has a user_id inside. The SQL it writes will be syntactically flawless and semantically hopeful — and hopeful SQL in an analytics pipeline is how confident wrong answers get made at scale.
- [From Snowsight to First Audit: Governing a Snowflake Schema with CoreModels](https://www.coremodels.io/connector/snowflake/t1-quickstart): You have a Snowflake schema and about thirty minutes. By the end of this tutorial you will have a governed model of that schema in CoreModels — tables as Types, columns as Elements with their native types preserved, declared keys as checks and references, object dependencies as lineage — and you will have run your first drift audit against it and read the result.
- [Every Endpoint: The CoreModels HTTP Surface for Snowflake](https://www.coremodels.io/connector/snowflake/t2-api): This is the reference walk through everything you can do with the Snowflake integration over plain HTTP — every route, its role requirement, its request body, and what comes back. The Snowflake connector declares all three capabilities — Import, Audit, and Generate — so every verb below is live for it.
- [An Agent Runs Your Snowflake Governance: The MCP Workflow](https://www.coremodels.io/connector/snowflake/t3-mcp): "Is our Snowflake estate still in sync with the governed model? If not, show me exactly what drifted, and draft the DDL to fix it." That is a sentence you can now say to an AI agent, and every step it takes to answer — discovery, audit, report, generation — runs through the CoreModels MCP server as first-class tool calls. This article walks the whole flow: how an agent connects, which integration tools it gets, the exact arguments each takes, and how large metadata extracts travel via the artifactUrls path.
- [Wiring a Snowflake Drift Gate: CI, the Badge, and the Rolling Trail](https://www.coremodels.io/connector/snowflake/t4-automation): Schema drift has two directions, and most teams only guard one. The warehouse can move away from the agreed model — a column retyped in a Friday migration, a table quietly dropped. But the model can also move away from the warehouse — someone tightens an allowed-value list in governance and nobody re-checks the estate. This article wires up automation for both directions against a Snowflake estate governed in CoreModels: a CI gate on the machine-to-machine API, a status badge, the rolling audit history, one-call re-audits, and the scheduled heartbeat that keeps the loop honest between changes.
- [Anatomy of an Import: How a Snowflake Estate Becomes a Governed Graph](https://www.coremodels.io/connector/snowflake/t5-deep-dive): Take one column — ORDER_TOTAL NUMBER(38,2) in ANALYTICS.PUBLIC.ORDERS — and follow it from an INFORMATION_SCHEMA row to a governed graph node. That single trace touches everything interesting about the Snowflake connector in CoreModels: how identity is minted, how native types map (and where they approximate), what rides the vendor-metadata mixin, how keys and dependencies become checks and lineage, which audit rules are Snowflake's own, and where the connector honestly declines to guess. This article is that trace, written for people who want to know exactly what the import does before pointing it at production metadata.
- [The Column Nobody Can Explain](https://www.coremodels.io/connector/sql/h1-need): A partner feed starts rejecting rows at two in the morning. The cause is one column: status. Someone runs a SELECT DISTINCT against production and gets six values back. The application's enumeration has five. The integration document the partner was handed lists four. The column is declared VARCHAR(32), so all six values are perfectly legal — the database was never told otherwise.
- [Four Requests, One Schema, Nothing Retyped](https://www.coremodels.io/connector/sql/h2-outcomes): Here is a realistic week for whoever owns the customer schema in a mid-sized data platform.
- [Who Signs Off on a Generated `CREATE TABLE`?](https://www.coremodels.io/connector/sql/h3-governance): A pull request lands. It contains a DDL file generated from a governed model, destined for a database real customers depend on. A reviewer has to decide whether to approve it.
- [SQL Is Everywhere, Which Is Exactly Why It Cannot Be the Center](https://www.coremodels.io/connector/sql/h4-ecosystem): Read enough data specifications and you notice how often they quote SQL inside themselves.
- [An Agent Can Write Perfect DDL for the Wrong Database](https://www.coremodels.io/connector/sql/h5-agents): Language models are unusually good at writing SQL DDL. They have read an enormous amount of it, the grammar is regular, and the output looks right immediately.
- [Your First DDL Transform Should Write Nothing: a SQL Quickstart](https://www.coremodels.io/connector/sql/t1-quickstart): 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.
- [Four Routes, One Envelope: SQL DDL on the CoreModels Transform API](https://www.coremodels.io/connector/sql/t2-api): | 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 |
- [Teaching an Agent to Read DDL: the transform_schema MCP Tool](https://www.coremodels.io/connector/sql/t3-mcp): 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.
- [Commit the Plan, Not the Guess: SQL Conversion Pipelines That Repeat](https://www.coremodels.io/connector/sql/t4-automation): 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.
- [No Annotation Slot: How the SQL DDL Coder Carries Meaning, and Where It Stops](https://www.coremodels.io/connector/sql/t5-deep-dive): 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.
- [The Constraint That Stopped Firing](https://www.coremodels.io/connector/synapse/h1-need): 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.
- [Three Artifacts by Five O'Clock, None of Them Typed](https://www.coremodels.io/connector/synapse/h2-outcomes): 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.
- [The Difference Between a Guess and a Record](https://www.coremodels.io/connector/synapse/h3-governance): 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.
- [Where a Schema Goes After You Export It](https://www.coremodels.io/connector/synapse/h4-ecosystem): 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.
- [An Agent That Can Say "Unconfirmed"](https://www.coremodels.io/connector/synapse/h5-agents): 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.
- [Your Data Model Outlives Its Toolchain](https://www.coremodels.io/connector/synapse/h6-schematic-migration): 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.
- [From JSON Schema to a Registration-Ready Synapse Schema in One Call](https://www.coremodels.io/connector/synapse/t1-quickstart): 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.
- [The Synapse Export, Route by Route: A CoreModels API Reference](https://www.coremodels.io/connector/synapse/t2-api): 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.
- [Synapse Schemas from an Agent: transform_schema over MCP, End to End](https://www.coremodels.io/connector/synapse/t3-mcp): Connect an MCP client — Claude Desktop, an IDE agent, your own orchestration — to a CoreModels deployment at https://go.coremodels.io/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.
- [Automating Synapse Schema Releases: Determinism, Plan Replay, and Version Discipline](https://www.coremodels.io/connector/synapse/t4-automation): 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.
- [Inside the synapse Coder: The Whitelist, the Ledger, and the Edge Cases](https://www.coremodels.io/connector/synapse/t5-deep-dive): 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.

## Guides
- [Airbyte guides](https://www.coremodels.io/guides/airbyte): Govern the catalog every sync trusts - before a silent type change lands in the warehouse.
- [Apache Airflow guides](https://www.coremodels.io/guides/airflow): Govern the scheduler that already knows your freshness, ownership, and lineage.
- [Confluent guides](https://www.coremodels.io/guides/confluent): Put meaning under every Kafka subject the Schema Registry already inventories.
- [Databricks guides](https://www.coremodels.io/guides/databricks): Give Unity Catalog something to check thousands of columns against.
- [Google BigQuery guides](https://www.coremodels.io/guides/bigquery): Turn INFORMATION_SCHEMA from an inventory into a contract you can audit.
- [JSON Schema guides](https://www.coremodels.io/guides/jsonschema): Stop asking a validator four questions it was only built to answer one of.
- [Salesforce guides](https://www.coremodels.io/guides/salesforce): Govern the org whose schema can change in forty seconds from Setup.
- [Snowflake guides](https://www.coremodels.io/guides/snowflake): Your Snowflake schema is not a contract. Generate one from the governed model.
- [dbt guides](https://www.coremodels.io/guides/dbt): Your dbt project already holds the definitions, copied into every accepted_values list that tests a column. Bring a manifest; we connect the copies into one vocabulary you govern — that your agents build on, operate across and answer from.
- [AWS Glue guides](https://www.coremodels.io/guides/glue): Stop treating a crawler snapshot as the meaning of your lake.
- [Apache Avro guides](https://www.coremodels.io/guides/avro): One governed reading of the schema that currently lives in four places.
- [JSON-LD guides](https://www.coremodels.io/guides/jsonld): Make the vocabulary you already trust executable downstream.
- [LinkML guides](https://www.coremodels.io/guides/linkml): Let the pipeline read the model that is already right.
- [MACH ODM guides](https://www.coremodels.io/guides/odm): Stop shipping a recollection of the standard as if it were the standard.
- [Microsoft Fabric guides](https://www.coremodels.io/guides/fabric): Catch the warehouse type change that never pages anyone.
- [Neo4j guides](https://www.coremodels.io/guides/neo4j): Write down the graph schema MERGE has been inferring for you.
- [ODCS guides](https://www.coremodels.io/guides/odcs): Make the contract a derived artifact of governed meaning, not a YAML twin of the table.
- [OWL guides](https://www.coremodels.io/guides/owl): Keep the ontology and the application schema from becoming two portraits of Person.
- [Open Semantic Interchange guides](https://www.coremodels.io/guides/osi): Put two revenue numbers next to the same definition.
- [Protocol Buffers guides](https://www.coremodels.io/guides/protobuf): Carry reserved field numbers with the meaning, not only with the .proto file.
- [REDCap guides](https://www.coremodels.io/guides/redcap): Diff the codebook so a study change is a review, not a memory.
- [SQL guides](https://www.coremodels.io/guides/sql): Give the column nobody can explain a definition your team governs and your agents act on.
- [ShEx guides](https://www.coremodels.io/guides/shex): Keep the four assertions in every shape constraint from dying in a hand copy.
- [Synapse guides](https://www.coremodels.io/guides/synapse): Record the constraints that die on the way to a registered schema.
- [cBioPortal guides](https://www.coremodels.io/guides/cbioportal): Govern the four comment rows that are the schema of your study.

## Q&A pages
- [Q&A](https://www.coremodels.io/q-a): Questions 1-100 of 1000
- [Q&A (page 2)](https://www.coremodels.io/q-a/2): Questions 101-200 of 1000
- [Q&A (page 3)](https://www.coremodels.io/q-a/3): Questions 201-300 of 1000
- [Q&A (page 4)](https://www.coremodels.io/q-a/4): Questions 301-400 of 1000
- [Q&A (page 5)](https://www.coremodels.io/q-a/5): Questions 401-500 of 1000
- [Q&A (page 6)](https://www.coremodels.io/q-a/6): Questions 501-600 of 1000
- [Q&A (page 7)](https://www.coremodels.io/q-a/7): Questions 601-700 of 1000
- [Q&A (page 8)](https://www.coremodels.io/q-a/8): Questions 701-800 of 1000
- [Q&A (page 9)](https://www.coremodels.io/q-a/9): Questions 801-900 of 1000
- [Q&A (page 10)](https://www.coremodels.io/q-a/10): Questions 901-1000 of 1000

## Legal
- [Terms of Service](https://www.coremodels.io/legal/terms): The agreement for CoreModels. Contracting entity: Ariesnet, Inc.
- [Data Processing Addendum](https://www.coremodels.io/legal/dpa): Processor commitments, subprocessors, and where data is processed.
- [Security Overview](https://www.coremodels.io/legal/security): Written for a buyer's security review: isolation, encryption, access control, certifications.
- [Service Level Agreement](https://www.coremodels.io/legal/sla): Uptime commitment, how it is measured, credits, and support response times.
- [Privacy](https://www.coremodels.io/legal/privacy): Who controls personal data on coremodels.io (Ariesnet, Inc.), and a link to the full privacy policy.
- [Refunds](https://www.coremodels.io/legal/refunds): Refund and cancellation terms for Builder, Team, and Enterprise plans.

## Markdown mirror
- [Mirror index](https://www.coremodels.io/mirror/index.md): every mirror file, by type (459 files)
- article: /mirror/article/en/<connector>--<slug>.md (271 files)
- changelogEntry: /mirror/changelogEntry/en/<slug>.md (25 files)
- connector: /mirror/connector/en/<slug>.md (26 files)
- faqItem: /mirror/faqItem/en/q-a-<n>.md (10 files)
- guide: /mirror/guide/en/<connector>.md (25 files)
- legalPage: /mirror/legalPage/en/<slug>.md (6 files)
- page: /mirror/page/en/<slug>.md (21 files)
- recipe: /mirror/recipe/en/<vendor>--<slug>.md (75 files)

## Optional
- [Full text](https://www.coremodels.io/llms-full.txt): this file, then every markdown page in full
- [Markdown sitemap](https://www.coremodels.io/sitemap.md): every page with its markdown link
- [XML sitemap](https://www.coremodels.io/sitemap.xml): every canonical page URL
- [Campaign preview: AI building (home)](https://www.coremodels.io/c/ai-building): An agent creates the model. It imports what exists, proposes the new types, and generates the schema, the SQL and the docs.
- [Campaign preview: AI building (agent-ready)](https://www.coremodels.io/c/ai-building/agent-ready)
- [Campaign preview: Structured-data operations (home)](https://www.coremodels.io/c/structured-data-ops): An agent runs the changes. Import dbt metadata, audit drift, find what a change breaks, write the contract back.
- [Campaign preview: Structured-data operations (agent-ready)](https://www.coremodels.io/c/structured-data-ops/agent-ready): We start from the structure your system already exports: a schema, a database definition or a content model. Old or custom systems usually work too.
- [Campaign preview: Grounding (home)](https://www.coremodels.io/c/grounding): An agent answers from the model. It reads the governed definitions before it writes a query or a reply.
- [Campaign preview: Grounding (agent-ready)](https://www.coremodels.io/c/grounding/agent-ready): More prompting will not fix this. Agents need your real structure to look up before they act.
- [Campaign preview: Research informatics (home)](https://www.coremodels.io/c/research-informatics): Govern the four comment rows that are the schema of your study. Diff the codebook so a study change is a review, not a memory.
- [Campaign preview: Research informatics (agent-ready)](https://www.coremodels.io/c/research-informatics/agent-ready)
- [Campaign preview: SAP (agent-ready variant) (home)](https://www.coremodels.io/c/sap): We map what your data means. Then we give agents governed MCP access to it, read-only by default.
- [Campaign preview: SAP (agent-ready variant) (agent-ready)](https://www.coremodels.io/c/sap/agent-ready): Now it calls an MCP endpoint. It gets the record with its meaning attached. Governed MCP access, read-only by default. MCP is the standard connection AI agents use.
- [Changelog: fix(cache): a corrected claim can no longer be served stale to agents for a day](https://www.coremodels.io/changelog#2026-10-24-0c11467): 24 October 2026
- [Changelog: feat(playground): /playground/dbt walkthrough on the jaffle_shop sample, linked from /connector/dbt](https://www.coremodels.io/changelog#2026-10-23-90614d9): 23 October 2026
- [Changelog: feat(agent-ready): LinkedIn Insight Tag partner id 9882738 as code default](https://www.coremodels.io/changelog#2026-10-19-14c452b): 19 October 2026
- [Changelog: feat(agent-ready): MCP server manifest + openapi.json; fix stale learn link (QA-02 r2)](https://www.coremodels.io/changelog#2026-10-18-c8cd90b): 18 October 2026
- [Changelog: feat(agent-ready): agent-consumability — actionable CTA links, explicit AI-bot robots policy](https://www.coremodels.io/changelog#2026-10-18-218dac1): 18 October 2026
- [Changelog: feat(agent-ready): add LinkedIn Insight tag, gated on NEXT_PUBLIC_LINKEDIN_PARTNER_ID](https://www.coremodels.io/changelog#2026-10-17-acef824): 17 October 2026
- [Changelog: feat(agent-ready): nav CTA routing, fix/partner intents, what-happens-next panel](https://www.coremodels.io/changelog#2026-10-17-95304a2): 17 October 2026
- [Changelog: feat(agent-ready): agent-ready services page, Services nav link, lead form](https://www.coremodels.io/changelog#2026-10-16-ff18d80): 16 October 2026
- [Changelog: feat(agent-ready): JSON-LD, agent-readable pricing/offers feeds, SKILL.md route](https://www.coremodels.io/changelog#2026-10-16-9a6e2de): 16 October 2026
- [Changelog: fix(links): LinkedIn footer link and the General guides no longer lead to a 404](https://www.coremodels.io/changelog#2026-09-28-51c55a4): 28 September 2026
- [Changelog: fix(copy): remove the partner program from the footer and the suite page](https://www.coremodels.io/changelog#2026-09-25-a3b4987): 25 September 2026
- [Changelog: fix(legal): security page states the present position only](https://www.coremodels.io/changelog#2026-09-25-9eb46fe): 25 September 2026
- [Changelog: feat(legal): on-domain /legal/privacy page](https://www.coremodels.io/changelog#2026-09-25-53b75b1): 25 September 2026
- [Changelog: fix(pricing): offer copy uses a seat count, not a date; FAQ states certification status](https://www.coremodels.io/changelog#2026-09-23-4ee36d2): 23 September 2026
- [Changelog: fix(seo): canonicals and sitemap name the serving host, q-a indexable, default share image](https://www.coremodels.io/changelog#2026-09-16-c633900): 16 September 2026
- [Changelog: fix(seo): keep the /q-a noindex, drop the page from sitemap.xml only](https://www.coremodels.io/changelog#2026-09-16-c133669): 16 September 2026
- [Changelog: fix(legal): remove draft residue from the security and SLA pages, and make the legal surface findable](https://www.coremodels.io/changelog#2026-09-12-2232426): 12 September 2026
- [Changelog: fix(seo): noindex /q-a until it is a short, maintained product FAQ](https://www.coremodels.io/changelog#2026-09-10-a1be55b): 10 September 2026
- [Changelog: feat(site): homepage copy + the CoreModels Solution Framework, linked from a rebuilt footer](https://www.coremodels.io/changelog#2026-09-08-ed97b4f): 8 September 2026
- [Changelog: fix(framework): end-of-page doors as two cards; the proof and Mayo history as C corrected them](https://www.coremodels.io/changelog#2026-09-08-74f44f6): 8 September 2026
- [Changelog: feat(home): one door to the Solution Framework near the bottom; footer tagline](https://www.coremodels.io/changelog#2026-09-08-2d1348f): 8 September 2026
- [Changelog: feat(legal,pricing): name Schematica as the suite and Ariesnet as the payer, where consent is taken](https://www.coremodels.io/changelog#2026-09-05-f01b9e0): 5 September 2026
- [Changelog: fix: stop the /features/mcp email CTA dead-ending, and wire GA4](https://www.coremodels.io/changelog#2026-09-05-4404a99): 5 September 2026
- [Changelog: fix(pricing,legal): offer copy follows the annual checkout, and the seat counter stops inventing a number](https://www.coremodels.io/changelog#2026-09-04-b705952): 4 September 2026
- [Changelog: feat(legal): IP indemnity/confidentiality/publicity, DPA notice periods, security trust narrative, dangling-fragment cleanup (v3 §A6/A8)](https://www.coremodels.io/changelog#2026-09-04-84ac481): 4 September 2026