The POLE+O data model

POLE+O is the default entity classification in Neo4j Agent Memory. Its broad categories provide a common vocabulary for extracted knowledge while leaving room for domain-specific detail.

The shared categories do not make configuration identical across backends. Both backends refine POLE+O with versioned ontologies, but a Bolt client applies its ontology to local extraction and resolution, while NAMS applies the workspace’s active ontology server-side. See Backend capabilities and Bolt and NAMS.
POLE+O entity model: Person, Object, Location, Event, and Organization categories with example subtypes
Figure 1. POLE+O entity model: Person, Object, Location, Event, and Organization categories with example subtypes

What is POLE+O?

POLE+O stands for Person, Object, Location, Event, and Organization. It separates who or what a statement concerns from the statement itself.

For a fictional example, Maya Chen (PERSON) attends a robotics workshop (EVENT) at a Denver laboratory (LOCATION) hosted by Northstar Robotics (ORGANIZATION), bringing a sensor prototype (OBJECT). The categories make these records comparable without forcing every application to use the same domain vocabulary.

Entity types and subtypes

  • PERSON describes people or identified personas. A name or role alone may still be ambiguous.

  • OBJECT covers physical and digital items, such as a device or document.

  • LOCATION covers places and geographic areas. Coordinates are additional data, not a prerequisite for identifying a place.

  • EVENT describes something that happens, such as a meeting or transaction.

  • ORGANIZATION describes companies, institutions, and groups.

A subtype refines the broad category. For example, OBJECT with subtype VEHICLE retains its object classification while allowing more specific queries. A subtype is classification, not proof that two entities are identical.

A domain may need distinctions beyond these defaults; that is a reason to model the domain explicitly, not to overload a name field.

Subtypes that become labels

On Bolt, the query builder turns a subtype into a node label only when it is a known subtype of the POLE+O type. The known subtypes are:

Type Subtypes

PERSON

INDIVIDUAL, ALIAS, PERSONA, SUSPECT, WITNESS, VICTIM

OBJECT

VEHICLE, PHONE, EMAIL, DOCUMENT, DEVICE, WEAPON, MONEY, DRUG, EVIDENCE, SOFTWARE, PRODUCT

LOCATION

ADDRESS, CITY, REGION, COUNTRY, LANDMARK, FACILITY, COORDINATES, GEOPOLITICAL, GEOGRAPHIC

EVENT

INCIDENT, MEETING, TRANSACTION, COMMUNICATION, CRIME, TRAVEL, EMPLOYMENT, OBSERVATION, DATE, TIME

ORGANIZATION

COMPANY, NONPROFIT, GOVERNMENT, EDUCATIONAL, CRIMINAL, POLITICAL, RELIGIOUS, MILITARY, GROUP

Any other subtype on a POLE+O type is still stored in the entity’s subtype property, but it adds no label: ORGANIZATION with subtype RESTAURANT gets :Entity:Organization, not :Entity:Organization:Restaurant. Custom (non-POLE+O) types accept any valid label identifier as a subtype. An extractor can propose a subtype outside this list; check the table before relying on a subtype label in a query.

An ontology adds its own labels on top. Every ontology entity type maps onto a POLE+O pole_type, and on Bolt a node also gets the label the client’s ontology declares for its exact pole_type/subtype pair, in PascalCase that keeps the label’s own capitals. A Customer label declared with pole_type: PERSON and subtype: CUSTOMER is stored as :Entity:Person:Customer, although CUSTOMER is not in the table; a Product label declared as OBJECT:PRODUCT is stored as :Entity:Object:Product, its subtype label and ontology label being the same.

Classification in the graph

On Bolt, a managed entity carries the :Entity label and a type property, with type and known subtype labels added for querying. For example, an OBJECT with subtype VEHICLE can carry :Entity:Object:Vehicle.

The labels describe the node; relationships describe how it connects to other nodes. Message extraction links :Message to :Entity with :MENTIONS. Extracted relationships can be represented as :RELATED_TO with a property identifying the relation. Do not assume that a conceptual employment relation is always stored as a physical :WORKS_AT edge.

See Schema objects and Long-term memory API for the stored shapes and operations. Existing domain graphs can retain their own labels and relationships through graph adoption.

Choosing the classification scope

A narrow extraction vocabulary reduces irrelevant candidates, while a broader vocabulary can preserve unexpected entities. The appropriate scope depends on what the application needs to retrieve later.

Keep configuration separate from this conceptual choice. Follow Configure extraction and drive extraction from an ontology for the Bolt procedures, and Use ontologies for NAMS. The configuration reference defines the actual settings and defaults.

When the defaults are insufficient

A domain schema may need types such as a research study or a device fault, with properties and relationships that the five categories do not fully describe. A custom model makes those distinctions explicit.

On Bolt, every schema configuration path converges on one ontology document that the client resolves when it connects. SchemaModel.CUSTOM with entity_types builds an ad hoc document, mapping each name onto POLE+O. custom_schema_path and ontology_path load a file that can hold either a legacy EntitySchemaConfig or an ontology document. A version activated through client.ontology is stored in your own database. The resolved document drives the extractors, relation validation, entity resolution and the strict write paths. On NAMS, an ontology refines the common categories through versioned workspace definitions and validation modes applied server-side. These mechanisms have different ownership and validation behavior; activating an ontology on one backend does not activate it on the other.

See Ontologies, Schema configuration, and Use extraction schemas.

Classification and identity are different

Type filters help retrieve the right class of entity. Identity resolution asks whether two records denote the same individual thing. Both are needed: two PERSON records named Maya Chen are not necessarily duplicates.

The two interact on Bolt. Since 0.7.0, message ingestion resolves extracted mentions by default, and resolution never compares entities across POLE+O types: "Apple" as an ORGANIZATION and "Apple" as an OBJECT stay separate even when their names and embeddings match. A wrong type therefore produces a duplicate that resolution cannot find.

Stable identifiers and provenance can resolve ambiguity that names and types cannot. Resolution and deduplication explains those decisions; Work with entities provides the storage and retrieval procedure.

How extraction reaches the common vocabulary

Extractors start with different representations. A spaCy model has trained labels, GLiNER2.5 reads configurable labels together with their descriptions as zero-shot annotation guidelines, and an LLM uses a response schema and prompts. Mappings translate the relevant output into the entity vocabulary. An ontology label carries its own pole_type and subtype, so it maps directly; bare lowercase labels such as company fall back to a built-in label mapping.

A mapping is not semantic validation. A model can assign the wrong label, and a broad fallback category can hide a missing domain distinction. Inspect representative output when changing schemas. See Extractors, Domain schemas, and the extraction pipeline.

Keeping a useful vocabulary

Use consistent names and keep the source of an assertion. Add subtypes or custom types when they express a meaningful distinction needed by the application. Avoid treating product variants, subsidiaries, or same-name people as aliases solely to simplify the graph.

The model should follow retrieval needs: a distinction that matters for a query must survive ingestion. No general performance advantage follows merely from choosing a subtype over a custom type.

See also