EnterGenni: a Knowledge Graph Compiler for the AI era.

Enterprises that scaled on relational databases now face a structural requirement of the AI era: systems, models, agents, and retrieval pipelines must reason over relationships, not only rows. Graph technology is the natural lens for that shift — but hand-built graph layers are slow to create, brittle under schema change, and rarely stay aligned with the systems of record.

EnterGenni is a Knowledge Graph Compiler. It takes a SQL schema or Excel domain model as input and compiles a validated, deterministic platform — schema, application code, sync services, APIs, clients, traversals, diagrams, ontology exports, and an operational run report — packaged as a deployable ZIP. Customers keep their relational source of truth; EnterGenni produces and regenerates the graph backbone as the domain evolves.

For decades, relational schemas correctly modeled business structure using foreign keys, join tables, and naming conventions — and that design remains the system of record for most enterprises. What changed is consumption: RAG needs multi-hop context, not single-table lookups; agents need impact paths ("what else breaks if this changes?"); analytics and compliance need hierarchy, lineage, and dependency views; fraud, entitlement, and org intelligence require connected semantics.

The relationships already exist, buried in FK definitions. The gap isn't ignorance of the domain — it's the cost of making those relationships first-class, queryable, and maintainable alongside production SQL. Teams that hand-build graph layers typically get a snapshot, not a platform: something that worked for a proof-of-concept and then diverged from the living relational model as schema changed, labels were reinvented per service, and sync from SQL was bolted on ad hoc.

Decision makers need a repeatable transformation from schema to graph application stack, with determinism (same model yields same artifacts), evolution (regenerate when the domain model changes), low migration risk (no requirement to rip out SQL or connect production credentials for a first run), and honesty about what is derived from structure versus invented business semantics. EnterGenni is designed against that checklist.

One sentence: upload your schema, and compile a deployable knowledge-graph platform — databases, APIs, sync, clients, traversals, and documentation — from a single validated domain model.

The pipeline: SQL DDL / Excel / JSON → a validated domain model (IR) → an optional semantic rule layer → 16 structural generation passes plus conditional ontology → a ZIP plus RUN-REPORT (HTML / Markdown) → deployment into the customer's stack plus Neo4j. EnterGenni is the compiler in that chain — it does not replace the customer's ERP or warehouse, and it does not host the graph as a managed DBaaS. It compiles the missing application and database layer so teams can start, and keep starting again when the model changes.

As a compiler it validates input (pre-flight diagnostics reject invalid models before generating code), produces deterministic output (same IR yields the same files, golden-testable), emits multiple artifacts (roughly 17 passes producing 100+ files for a mid-size domain), reports on every run (a human-readable run report ships in every ZIP), and supports incremental evolution (schema diff / migration artifacts when a prior schema baseline is supplied).

Inputs: SQL DDL is the primary enterprise path (Postgres, MySQL, SQL Server, Oracle, Supabase-style dumps); an Entities.xlsx spreadsheet gives a human review/edit gate after schema mapping, or direct authoring; a JSON EntityModel gives an API/CI path using the same intermediate representation. Upload mode does not require live production database credentials — teams export DDL offline and compile safely.

A single canonical intermediate representation (EntityModel) carries entities, scalar fields, and enums; relationships (direction, target, navigation name, labels); project metadata and optional Neo4j settings; optional previous schema statements for evolution; and an optional semantic overlay from rule packs. Every generator reads this IR — no generator silently invents domain facts outside validation and optional rule packs.

A typical compile produces a layered stack under GraphDB/ (and optional Ontology/): node POCOs and relationship type constants; repository interfaces and Cypher-backed implementations; MVC and REST API controllers with DI/context wiring; constraints, indexes, an initializer, and a native Neo4j import bundle; relational-to-graph sync services and seeders; an insights repository (hierarchy, impact, shortest path, orphans) and traversal query library; Swagger setup, a Postman collection, and a TypeScript client; Mermaid/GraphViz diagrams; ontology JSON and semantic coverage when enabled; and a RUN-REPORT.html/.md. Neo4j is the default graph engine — an implementation detail of the current codegen target, not the product category; alternative graph targets are a stated roadmap item, not a current claim.

Clean layering: input adapters (SQL/Excel, I/O at the edges) produce the EntityModel IR, a validator with no I/O checks it, and 16+ pure, deterministic generators emit the ZIP and report. Generation.Core has no I/O — filesystem, HTTP, and database access live in adapters, API, or packaging sinks — which makes the engine testable, embeddable, and safe to run in constrained environments.

Structural compilation always runs: foreign keys become edges, and generators emit merge keys, repositories, APIs, and FK-derived traversals. Semantic compilation is optional and plan-gated: deterministic rule packs (not LLM guesses) match entity and relationship signals to domain types — for example REPORTS_TO or HOLDS_ROLE — and can emit traversal intents and an ontology export. This is deliberate product honesty: EnterGenni does not invent purchase lifecycles, fraud rings, or approval workflows that aren't present in the model or rule packs.

Schema evolution is a first-class pass: it compares current constraint/index statements to a previous baseline. On a first compile there's nothing useful to diff yet, and the run report marks that pass Skipped with an explanation. On regeneration with a baseline, teams receive schema-diff.md and schema-migration.cypher, and the rest of the stack regenerates from the updated IR so APIs, sync, and traversals stay synchronized.

Run reports list each generation pass with status (Included / Skipped / Not enabled), file counts, and a plain-language contribution to delivery for stakeholders who will never open the Cypher. Representative passes include node models, relationship types, repositories, web controllers, context and DI wiring, schema constraints and indexes, schema evolution, a TypeScript client, architecture diagrams, relational-to-graph sync, seeders, insight queries, Swagger/OpenAPI, a Postman collection, a traversal query library, a native Neo4j bundle, and domain ontology export when enabled.

Separately, the report groups output by path-based categories (node models, repos, APIs, native bundle, ontology, and more), each documenting its contribution, description, how to use it, and a file list for audit — closing the gap between the marketing claim of "17 passes" and the engineering reality of "here are the folders you actually deploy."

A canonical sample (a ContosoErp HR/org model) is compiled continuously under a max-features profile — structural generators, semantic packs, ontology, and queries — with verification asserting file presence, content spot checks, semantic coverage, and run-report completeness. That same sample drives the public sandbox download and live report.

Design goals: domain-aware relationship names via rule packs matched from schema signals; measurable coverage (mapped FK edges versus typable edges); golden schemas with minimum coverage thresholds for known domains such as Contoso ERP HR; exportability via ontology.json and semantic-coverage.json for catalogs and GraphRAG tooling; and plan-controlled toggles for the semantic layer, traversal intents, ontology generation, and pack selection.

What semantics are not: not large-language-model inference over the schema, not a substitute for industry ontology consulting on undocumented processes, and not natural-language-to-Cypher (that remains on the roadmap). With semantics off, the platform still compiles with structural labels and FK-derived intelligence; with semantics on, generators consume the overlay for types, intents, and ontology where wired.

Time and risk: traditional graph buildup means a multi-week specialist engagement for an initial skeleton, an early production DB connection, manual rework on every schema change, and fragmented tooling. EnterGenni compresses that to minutes from DDL to ZIP for a validated mid-size schema, offline DDL upload for first value, regeneration plus optional schema diff on change, and one validated model driving all artifacts.

Who benefits: a CTO or VP Engineering gets a lower risk of a stranded graph initiative and a clearer cost than permanent specialist headcount for boilerplate; an enterprise architect gets consistent labels, sync keys, and API surfaces across teams; a data or platform engineer gets an import bundle, seed order, and schema scripts ready for ops; an AI or RAG builder gets a traversal library and APIs as relationship-native context sources; and an SI or consultancy gets repeatable client delivery via API or Excel-gated review.

Packaging is directional: plans meter generations and gate advanced semantic outputs such as queries, ontology, and live Neo4j features. Stripe billing may still be completing wiring, with entitlements enforced in product code. A public sandbox provides a full sample ZIP and run report without signup friction.

Compared to a hand-written Neo4j application layer, EnterGenni delivers a complete, deterministic stack from one model. Compared to generic ORM-to-graph utilities, it delivers an opinionated deliverable — APIs, sync MERGEs, clients, native import, and reports. Compared to modeling-only Neo4j tooling, it produces application code the customer can own in their own repo. Compared to full-data migration vendors, code generation comes first, the customer keeps SQL as the source of truth, and data load is optional and customer-run. Compared to low-code hosted graph apps, it's a developer-owned source download, not a lock-in runtime.

The moat is encoded mapping knowledge — FK-to-edge conventions, seed topology, MERGE sync patterns, native import layout, and report taxonomy — maintained under characterization and ContosoErp verification, not tribal knowledge in a slide deck.

Recommended first 30 days: export DDL from a non-production or representative schema; analyze it via the public schema endpoint or UI and fix validation issues; review the generated Entities.xlsx to confirm entity names, features, and relationships; generate a ZIP under the appropriate plan toggles (semantic on for HR/org or similar packs); read RUN-REPORT.html for stakeholder and implementer detail; stand up Neo4j via the native bundle or a customer instance and apply schema.cypher; wire AddNeo4jGraphDb and smoke-test Swagger, Postman, and the TypeScript client; pilot one sync path — for example, an employee change triggering a graph MERGE — before broad cutover; and on the next schema change, regenerate with the prior schema baseline to exercise evolution.

Success criteria: a validated compile with zero error diagnostics; deployed constraints and at least one CRUD plus traversal smoke test; an agreed owner for the regeneration cadence when DDL changes; and, optionally, semantic coverage meeting an internal golden threshold for the domain pack.

In product today: multi-dialect DDL-to-IR-to-Neo4j-platform ZIP generation; Excel/JSON paths; validation; semantic rule packs; ontology/toggle gates; a run report with passes and contributions; a public sandbox; and cloud deployment of the compiler API.

The enterprises that dominated their markets on relational systems face an AI-era question: can your backend expose relationships, not just records, to modern intelligence? Graph stores answer that question technically. Compilers answer it operationally. EnterGenni turns schema knowledge into a regenerable platform: validated input, deterministic multi-artifact output, optional semantic enrichment, and governance reports that non-technical stakeholders can understand.

Compile once to start. Compile again to evolve. Keep SQL as the source of truth. Own the graph layer as code.

Product / live MVP: entergenni.intrologics.com. Document version 1.0, dated June 2026. Audience: CTOs, enterprise architects, data/platform leaders, and AI engineering teams. This white paper describes product capabilities as of the stated date — features and pricing may change, and engineering specs remain authoritative for implementation detail.