Introduction
You built three shapes on one fictional repair chain. The shapes, however, do not depend on auto repair - or on any one warehouse.
In this lesson, you will see how to port the shapes to your own lakehouse, and the decision that travels with them: derive versus federate.
Swap the source, keep the shapes
Each shape is sourced once and then never cares where it came from:
| Shape | What changes when you move platform |
|---|---|
Connections |
neocarta can connect to more than just BigQuery. This is a growing list, so see the GitHub repo for the full list |
Tables of Contents / Themes |
The document parser’s input path, plus the link and containment parsing format; the graph and GDS are unchanged |
The estate answers |
The SQL dialect your agent writes when it federates; the join paths still come from the connections graph |
The decision that travels: derive vs. federate
It’s not just shapes, but also where each shape should live:
-
ETL into a graph where you own the data or nothing else structures it - the documents (tables of contents, themes).
-
Federate where a system of record already owns the rows - the warehouse. Migrate only its metadata (the connections graph); query the rows in place if possible.
That rule is what keeps the pattern honest at scale: you get graph reasoning where it pays, without copying a warehouse you would only have to keep in sync.
Re-skin the domain
The pattern fits any business with manuals plus assets - documents that describe things, and records of what happened to those things, sharing IDs:
-
Manufacturing - equipment manuals + maintenance logs, joined on model and error codes
-
Pharma - protocols and regulatory filings + batch records, joined on compound and lot numbers
-
Financial services - policies and procedures + transactions and cases, joined on product and account identifiers
-
IT operations - runbooks and postmortems + incidents and deploys, joined on service names and error codes
The questions port too: "what does the documentation say applies to this asset, and what actually worked on assets like it?"
Where the shapes slot into an agent stack
You built it already - the skill is the stack:
-
Connections → the neocarta MCP: grounded SQL routing where Text2SQL guesses
-
Tables of Contents → your navigation tools: grounded browsing - and proving what is and is not there - instead of similarity guessing
-
Themes → your theme cards: the whole estate covered and clustered in one prompt-sized view
-
Shapes together → the finale’s move: ground in the document shapes, then read the live warehouse the connections shape routes - one answer, nothing copied
Vector search still has a seat - "find me a passage about X" - and works better here, because every hit carries its tree position and theme as context.
Keep building
-
This course - revisit any module self-paced; every query is in the lessons
-
neocarta - the connector library for the connections shape over your own warehouse
-
Neo4j Agent Skills - the skills catalog your agent gained from
neo4j-cli skill install -
Next courses - Neo4j & GenAI Fundamentals for retrievers and GraphRAG, Community Detection to go deeper on Leiden and Louvain
Summary
In this lesson, you saw how the pattern ports:
-
Swap the source - the shapes are platform-agnostic; neocarta and the parser take a new source
-
Derive vs. federate - the portable decision: graph what you own, federate what a warehouse owns
-
Agent stack - connections, tables of contents, themes, and federation become tools alongside vector search
One knowledge check to go.