CoreModelsCoreModels

Confluent

Put meaning under every Kafka subject the Schema Registry already inventories.

Quickstart · Get it working.
Confluent Schema Registry to CoreModels: Zero to First Audit
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.
API · Drive it from the Integration API.
The Complete HTTP Surface for Confluent Schema Registry Governance
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.
MCP · Drive it from an agent.
Ask Your Agent Whether the Kafka Schemas Drifted: Confluent Governance over 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.
Automation · Put it in CI.
Failing the Build Before the Consumer Breaks: A CI Drift Gate for Confluent Schema Registry
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.
Deep dive · Understand what it does.
Anatomy of a Governed Streaming Estate: How the Confluent Connector Maps Subjects into the Graph
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.

Why this matters

The case for Confluent — the problem it fixes and what changes when it is fixed — is on coremodels.io.

Read the Confluent guides →