Nodes

A node is the atomic unit in HyperMemory. Every piece of knowledge — a fact, a person, a decision, a preference — is stored as a node with these fields:

Field	Type	Description
key	str	Unique identifier you choose and reuse (e.g. person_sarah_chen, decision_jwt_auth)
description	str	Human-readable text that should stand alone — searched by BM25 and vector similarity
data	dict	Optional structured JSON for fields you want to filter or pattern-match
node_type	str	Classification of the node (e.g. person, decision, concept)

Node types

Types are divided into two categories:

Axiom types (protected — cannot be removed from the system):

Type	Use for
user	The primary user (singleton user_profile)
person	People — teammates, contacts
organization	Companies, teams, departments
location	Cities, offices, regions
group	Groups, committees
product	Products, services
asset	Files, images, resources
document	Documents, reports, specs
URL	Web URLs, links

Extendable types (can be added to):

Type	Use for
component	Software components, services, libraries
event	Meetings, launches, incidents
concept	Ideas, patterns, abstract topics
project	Projects, initiatives
tool	Development tools, utilities
technology	Languages, frameworks
preference	User preferences and settings
fact	Verified facts, data points
skill	Skills, expertise, capabilities
decision	Architecture choices, policy decisions
artifact	Configs, repos, outputs

New types are created on the fly by the server’s ontology canonicalizer — the system auto-manages an onto_type catalog.

Key format

Use the {type}_{name} convention: person_alice, decision_jwt_auth, tech_redis.

The user_profile singleton

A special user_profile node is auto-created on first hm_store call. It represents the graph owner and is updated automatically by the enrichment pipeline.

Example node

{
  "key": "decision_q3_api_perf",
  "description": "Q3 org priority: reduce API p95 latency under 100ms",
  "node_type": "decision",
  "data": {
    "quarter": "Q3-2026",
    "sponsor": "platform",
    "status": "in_progress"
  }
}

Creating nodes

Use hm_store:

{
  "key": "initiative_phoenix",
  "description": "API modernization for checkout service",
  "data": {"squad": "platform", "phase": 2}
}

After storing, the server triggers background enrichment — an LLM pass that expands the description, extracts structured data, creates new entities and edges, and updates the user_profile.

Updating and deleting

• hm_update modifies fields on an existing node. Re-embeds the vector on description changes.
• hm_forget deletes a node with optional cascade of connected edges.

Best practices

Next steps

Edges & hyperedges

How relationships are stored

hm_store

API reference