POLE+O: The 5-Type Ontology That Solves the Hardest Part of Building a Knowledge Graph

Full Stack Developer

June 15, 2026

8 min read

Neo4j’s Create Context Graph ships with a universal starting schema. Here’s why starting with 5 node types beats starting from scratch.

image from create-context-graph homepage (https://create-context-graph.dev/)

The blank canvas problem

Every knowledge graph project starts the same way. Someone opens a whiteboard and asks: “So… what are our entities?” What follows is a multi-day debate about whether a “meeting” is a node or a relationship, whether “location” deserves its own type or is just a property, and whether the schema should mirror the source database or represent some idealized domain model.

The problem isn’t a lack of domain knowledge. It’s that there are too many valid ways to model a domain and no anchor to start from. Every option looks reasonable. None of them is obviously wrong. So the debate loops.

There’s an anchor that solves this. It’s been around for decades in intelligence analysis, and Neo4j just made it easy to use.

What POLE+O actually is

Neo4j Labs recently released Create Context Graph, a CLI tool that scaffolds full-stack AI agent applications with graph-based memory. The tool is interesting, but the most reusable thing in the project isn’t the CLI. It’s the ontology underneath.

POLE+O defines five base entity types:

Type           What it covers                Examples
Person         Any human entity              Patient, employee, developer
Organization   Groups and companies          Hospital, startup, team
Location       Places, physical or logical   Office, region, facilicy
Event          Things that happen            Sprint, transaction, incident
Object         Everything else               Document, product, file

The name comes from law enforcement and intelligence analysis, where POLE (Person, Organization, Location, Event) has been used for decades to connect disparate data across agencies. The “+O” extends it with Object to cover the rest of the world. If your entity doesn’t fit the first four, it’s an Object.

If your entity doesn’t fit any of the five — congratulations, you’ve discovered a sixth category of existence. I’d love to hear about it, leave the comment!

Domain mapping in practice

The power of POLE+O isn’t the five types themselves. It’s how domain-specific types layer on top using Neo4j’s multi-label system.

In a healthcare domain:

CREATE (:Person:Patient {name: 'Jan Kowalski', dob: '1985-03-15'})
CREATE (:Person:Provider {name: 'Dr. Nowak', specialty: 'Cardiology'})
CREATE (:Event:Diagnosis {code: 'I25.1', date: '2026-05-10'})
CREATE (:Object:Prescription {drug: 'Aspirin', dosage: '100mg'})

In a software engineering domain:

CREATE (:Person:Developer {name: 'Alice', github: 'alice-dev'})
CREATE (:Organization:Team {name: 'Platform'})
CREATE (:Event:Sprint {number: 42, start: '2026-05-13'})
CREATE (:Object:Issue {key: 'PLAT-1234', status: 'In Progress'})

Notice the pattern: :Person:Patient, :Event:Sprint, :Object:Issue. The base type is always there. The domain type adds specificity.

This gives you two things you don’t get with flat schemas.

First, you can always query at the base level:

MATCH (e:Event)
WHERE e.date > date() - duration('P30D')
RETURN labels(e) AS types, e.name, e.date
ORDER BY e.date DESC

This returns every event in the last 30 days — sprints, diagnoses, incidents, transactions — regardless of which domain they came from.

Second, when you connect data from multiple sources, entities unify at the base level automatically. A :Person from your HR system and a :Person from your project tracker are already in the same bucket. Matching them by email or ID becomes a merge, not a migration.

Why this beats starting from scratch

POLE+O doesn’t answer every modeling question. But it answers the first one: “What are my top-level categories?”

That question is deceptively expensive. Teams spend days on it because there’s no wrong answer — only trade-offs. POLE+O skips the debate by giving you a classification that works across domains. Not because it’s perfect, but because it’s good enough to start.

And starting matters. A knowledge graph you can query in week one teaches you more about your domain than a schema you’ve been debating for a month.

Once you start writing Cypher queries against real data, the model fixes itself. You notice that “meeting” shouldn’t be a relationship — it should be an Event, because you need to attach participants, locations, and outcomes to it. The queries tell you.

POLE+O gets you to that moment faster.

Where POLE+O fits — and where it doesn’t

Good fit:

Domains with concrete, real-world entities: healthcare, logistics, software engineering, legal. People, places, organizations, and things that happen — POLE+O maps naturally.
Multi-source integration: when you’re merging data from different systems, the shared base types gives you automatic unification points.
Rapid prototyping: when you need a queryable graph in days, not weeks.

Less obvious fit:

Abstract or conceptual domains: financial instruments, business rules, policies, mathematical models. These often don’t map cleanly to Person/Organization/Location/Event. Object becomes a catch-all, and a catch-all that holds everything holds nothing.
Deeply hierarchical domains: if your entities need 4+ levels of type inheritance, POLE+O’s flat five-type layer may feel too thin. You’ll end up doing most of the modeling work in the domain layer anyway.
RDF/OWL environments: POLE+O is a property graph pattern. If your organization already uses formal ontologies (SNOMED, FIBO, schema.org), layering POLE+O on top adds a classification system that may conflict with existing upper ontologies.

The honest take: POLE+O is a starting framework, not a complete ontology. It prevents the blank-canvas problem and gives you momentum. But the real modeling work — defining relationships, cardinality, temporal patterns — still happens after you pick your five buckets.

If you’re using LLMs to help design graph schemas, POLE+O works well as an anchor. It gives both you and the model a framework instead of a blank page. The conversations shift from “invent an ontology” to “refine this POLE+O model for my domain.”

Three memory types — built on the same ontology

Create Context Graph doesn’t just use POLE+O for static data. It builds a three-layer memory architecture on top of it:

Short-term memory — conversation history, current session context
Long-term memory — persistent entity relationships modeled as a POLE+O knowledge graph
Reasoning memory — decision traces that capture why an agent did what it did

The reasoning memory is worth looking at. When an agent makes a decision, it creates a :DecisionTrace node linked to :TraceStep nodes — each recording a thought, an action, and an observation.

MATCH (p:Patient {name: 'Jan Kowalski'})-[:RECEIVED]->(t:Treatment)
      -[:DECIDED_BY]->(d:DecisionTrace)-[:HAS_STEP]->(s:TraceStep)
RETURN s.thought, s.action, s.observation
ORDER BY s.order

You can’t traverse a reasoning chain in a vector store. You can in a graph. “Vector stores give you recall, graphs give you understanding” is a line from the Neo4j team, and this architecture makes it concrete.

Try it yourself

If you want to experiment with POLE+O without installing anything, grab a Neo4j Aura free instance and create a small graph manually:

CREATE (p:Person {name: 'You'})
CREATE (o:Organization {name: 'Your Company'})
CREATE (l:Location {name: 'Your Office'})
CREATE (e:Event {name: 'First Graph Model', date: date()})
CREATE (obj:Object {name: 'This Article'})

CREATE (p)-[:WORKS_AT]->(o)
CREATE (o)-[:LOCATED_IN]->(l)
CREATE (p)-[:PARTICIPATED_IN]->(e)
CREATE (e)-[:PRODUCED]->(obj)

Then map your own domain. Take 10 entities from your current project and classify each one as P, O, L, E, or O. Add domain labels. Start querying. The model will evolve — and that’s the whole point.

For the full scaffolded experience, Create Context Graph supports 27 domains and also lets you describe custom ones in plain English.