How Do I Structure Data in My Evolutionary Neural Memory?

Structuring data in an Evolutionary Neural Memory (ENM) requires a shift in thinking from relational tables, key-value, document or wide-column schemas to densely connected graphs. The good news: graph-native thinking is often closer to how you naturally think about your domain.

Think in Entities, Tags, and Relationships

The first step is to identify:

1. What are the things? — these become nodes (e.g., an event of type Person, Product, Sensor, Order). We call these Event Objects.
2. How are they connected? — these become edges (e.g., works-at, purchased, reads-from, contains). We call these Links (Links are a native implementation of an Event Object providing all the EO properties and behaviors to the developer).
3. What do I know about them? — these become properties on nodes and edges. We call these Tags.

Example: An E-Commerce Domain

In a relational database you might have:

customers table → orders table → order_items table → products table

In an ENM, this becomes:

Customer <--placed--> Order <--contains--> Product
Customer <--reviewed--> Product
Product <--belongs-to--> Category

Notice that Customer <--reviewed--> Product is a bi-directional relationship. In a relational model, you might need a join table. In a graph, it is a natural edge.

Design Principles

1. Favor Connections Over Duplication

In relational design, you might denormalize data into multiple tables for query performance. In ENM, create a single node and connect it to everything that references it.

Instead of:

Order { customer_name: "Alice", customer_email: "alice@example.com" }

Use:

Customer(name: "Alice", email: "alice@example.com") <--placed--> Order(date: "2025-01-15")

The Customer node exists once. Every Order, Review, and Support Ticket connects to it. Update Alice's email in one place, and every relationship reflects the change (table stakes behavior).

In document or key-value design you might normalize data into standalone, static descriptions. This method is easy but challenging because new field names or value types require code changes across your stack. Moreover, integrating the same data, but in different schemas, from across diverse system is a never-ending pain point and nearly always results in information loss. Instead of: {name: "Alice", email: "alice@example.com", "date": "2025-01-15", "order": [{"item_id": "1234", "amount": "1.00"}]}

Use: Customer(name: "Alice", email: "alice@example.com") <--placed--> Order(date: "2025-01-15") <--ordered--> Item("item_id": "1234", "amount": "1.00")

In Vector Design you might...

However, each example above gives us an opportunity to demonstrate a crucial, and powerful, difference in ENM design. You can retrieve the state of the connected objects for a specific time. Alice's first order used an e-mail address of 1234@domain.com. Alice's next order uses an e-mail of abcd@domain.com, and the order following that uses ab12@domain.com.

2. Name Edges with Verbs

Edge types should describe the relationship as a verb or verb phrase:

Avoid generic names like related-to or has — they lose meaning as your graph grows.

3. Use Node Types as Categories

Node types serve as a built-in categorization system. Choose types that represent real-world concepts in your domain:

Person, Company, Product, Order, Sensor, Location, Event

Types are flexible — you can introduce new types at any time (the evolutionary property), and you can query across types or within a single type.

4. Put Time, Location and Context Everywhere

When a relationship has context — when it started, who created it, under what conditions — put that information on the edge, not on the nodes:

// The "works-at" edge carries employment-specific information
{
    "from": "alice-node-id",
    "to":   "acme-node-id",
    "type": "works-at",
    "properties": {
        "since": "2024-01-15",
        "title": "Senior Engineer",
        "department": "Platform"
    }
}

If Alice leaves Acme and joins another company, you create a new works-at edge to the new company. The old edge remains as a historical record. The node properties (name, email) stay constant.

5. IDs and Owners

Coming soon — guidance on identity assignment and ownership models is in progress.

6. Start Simple, Evolve Gradually

One of ENM's greatest strengths is its evolutionary nature. You do not need to design a perfect schema up front:

1. Start with the nodes and edges you need today
2. Add new properties as requirements emerge — no migration needed
3. Introduce new node types when your domain expands
4. Add new edge types to capture newly discovered relationships

Old data remains valid. New data coexists alongside it. Queries against old structures continue to work while new queries leverage the evolved structure.

Common Patterns

Hub-and-Spoke

A central node connected to many related nodes:

                 +-- Sensor A
                 |
Gateway Node ----+-- Sensor B
                 |
                 +-- Sensor C

Good for: IoT deployments, organizational hierarchies, catalog categories.

Chain

Nodes linked in sequence:

Event 1 --> Event 2 --> Event 3 --> Event 4

Good for: Audit trails, workflow steps, time-series events.

Bipartite

Two distinct node types connected by a single edge type:

Users --- purchased ---> Products

Good for: Recommendation engines, marketplace transactions, access control.

Densely Connected

Many-to-many relationships between nodes:

Person A --knows--> Person B --knows--> Person C
Person A --knows--> Person C
Person B --works-at--> Company X
Person C --works-at--> Company X

Good for: Highly connected domains, social networks, and knowledge graphs.

Anti-Patterns to Avoid

Embedding Arrays Where Edges Belong

Avoid:

Person { name: "Alice", skills: ["Go", "Python", "Kubernetes"] }

Prefer:

Person(name: "Alice") --has-skill--> Skill(name: "Go")
Person(name: "Alice") --has-skill--> Skill(name: "Python")
Person(name: "Alice") --has-skill--> Skill(name: "Kubernetes")

With edges, you can traverse from any Skill back to all People who have it. With embedded arrays, that reverse query is expensive.

Creating "God Nodes"

Avoid nodes with thousands of properties that try to represent everything. Break them into focused nodes with relationships:

Avoid: User { name, email, address_street, address_city, address_zip, company_name, company_size, ... }

Prefer: User --lives-at--> Address, User --works-at--> Company

You now have the conceptual foundation and practical tools to build with Pod-OS. The best way to learn is to start building: deploy an ENM, add some data, run some queries, and see how the graph grows. For a deeper look at how IDs and ownership work across databases, see IDs and Ownership. Return to the Welcome page to review any concepts, or explore your deployment through the dashboard.