Neo4j

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.

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.

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.

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.

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.