IDs and Ownership

Evolutionary Neural Memory (ENM) is the next-generation database Actor at the core of Pod-OS. Each Evolutionary Neural Memory Actor is its own, stand-alone, instance. Nothing is shared between ENM instances the way tables are shared inside a single SQL server.

That isolation is powerful, but it creates two questions we need to understand:

1. How do I name things so I can find them again? (IDs)
2. Who created or owns a piece of data? (Ownership)

This page explains both, in plain language.

Two Different Kinds of Identity

Pod-OS uses two identity layers. They answer different questions and must not be confused.

When you deploy an Actor through the dashboard, log in, or manage data with an SDK, ownership is what records who did it. Your login maps to a stable account ID like user:your-domain.com:yourname. That ID is stored on each Event Object you create.

The connection name (ClientName / From address) is only for routing messages on the wire. A sensor or mobile app may reconnect with a different connection name every time — that is normal. Ownership should always use a durable principal ID, not the connection name.

Event Object IDs: Two Forms

Every Event Object in an ENM has:

Unique ID — your stable name

A Unique ID is a string you choose (or your application chooses) before the data is stored. You use it to find the same record again later, link to it, and update it.

Examples:

Unique IDs are defined by you. Prefer them in application code and in the dashboard.

Event ID — assigned at storage time

When an Event Object is first stored, the ENM also assigns an internal Event ID derived from timestamp and location (for example +1783092980.946966…TERRA47.614…-122.335…). You rarely set this yourself; however, setting it yourself defines a powerful context tool for you.

The Event ID primitive enables powerful and novel retrieval capabilities. Succinctly, the Event ID allows you to search and collect events using time and/or location. The use of time and location is one key method of collecting context (we support multiple implicit and explicit contextual relations) without explicitly defining relationships. Imagine you manage a network of manufacturing sensors across large area. Sensor events are hierarchically aggregated in a network of ENM instances.

For day-to-day work: use Unique ID. Treat Event ID as an internal address the system gives you back in responses.

Ownership: Who Created or Owns the Data?

Every Event Object carries an owner — the entity responsible for creating it. Ownership answers who, not what.

There are two wire fields (you set one or the other):

• owner — references an internal Event ID, or the special platform value $sys
• owner_unique_id — references another Event Object by Unique ID

Three classes of owner

In practice, ownership falls into three classes:

1. Platform (Class 1) — $sys

Used for bootstrap data, system configuration, and first-time creation of a record when no user context exists yet. The platform administrator is represented by $sys. It always resolves inside every database.

2. User-driven (Class 2) — user:<domain>:<username>

Used when a person (or their account) initiates an action: deploying an Actor, updating registry tags, adding data through the dashboard, changing roles, and so on.

Your dashboard login resolves to a Unique ID like user:acme.com:alice. That ID is your canonical account record in the Account Actor (account@zeroth.<platform-domain>).

3. Experiential / locational (Class 3) — another Event Object in the same database

Used when data logically belongs to something already in the graph:

• A sensor reading owned by the sensor's Event Object (device:…)
• A link owned by its source entity
• A payload update owned by the target event itself (self-ownership)

This is the natural model for IoT, provenance chains, and graph-native data.

Service and device principals

For long-running services and hardware, Pod-OS reserves typed prefixes:

Use a stable service: or device: Unique ID as the owner when writing from SDKs or edge clients, even if the network connection rotates.

The Golden Rule: Owners Must Be Local

Because each Actor has its own database, an owner reference must point to an Event Object that exists in the same database as the data being written.

There are no cross-database foreign keys. If you store an actor registration in actor_registry@zeroth and set owner_unique_id=user:acme.com:alice, the ENM must be able to find user:acme.com:alice inside actor_registry — not just in the Account Actor.

Your canonical user record always lives in Account. Other databases learn about you through an owner reference record: a lightweight Event Object with the same Unique ID (user:acme.com:alice), type owner reference record, and tags pointing back to Account (memory_of_record=account@zeroth…).

The Pod-OS dashboard materializes these reference records automatically when you deploy gateways, add actors, ingest data, or perform other writes — so ownership resolves correctly without manual setup.

Account Actor (canonical)          actor_registry ENM (local copy)
┌─────────────────────────┐        ┌─────────────────────────────┐
│ user:acme.com:alice     │        │ user:acme.com:alice         │
│ (full profile, roles)   │ ─────► │ (owner reference record)    │
└─────────────────────────┘        └─────────────────────────────┘
                                              │
                                              ▼
                                     acme.com:zeroth:my-enm
                                     owner_unique_id=user:acme.com:alice ✓

If the local reference is missing, updates that attach tags or payload to an existing Event Object (for example marking an actor status=deployed) will fail with an error like Missing owner ID in tag_store_batch.

Common Unique ID Formats (Platform Services)

These formats appear across the Pod-OS platform. You do not need to memorize them all — but recognizing the pattern helps when reading logs or the registry.

Gateway registry entries use <domain>:<gateway>:<gateway> (gateway name repeated). Actor entries use <domain>:<gateway>:<actor>.

Create vs Update: Different Owner Rules

Ownership rules depend on the operation:

That is why actor deployment succeeds in two steps: first the registry creates the actor event (with $sys), then it updates tags (with your user as owner). The dashboard ensures your user reference exists locally before the update.

What You Should Do in Practice

Dashboard users

• Your ownership is handled automatically from your login session.
• Deploy actors, add data, and manage accounts without setting owner fields manually.
• If you see an ownership error during deployment, it usually means a local owner reference was not created yet — retry after gateway init completes, or contact support if it persists.

SDK and integration developers

1. Pick stable Unique IDs for entities you create (article:…, device:…, user:…).
2. Set owner_unique_id to a durable principal (user:, service:, or device:) on creates — not to the connection client name.
3. On updates (tags, payload, links), ensure the owner Unique ID already exists in the target ENM, or materialize an owner reference record first.
4. Use self-ownership when updating an event's own payload: set owner_unique_id equal to the target event's Unique ID.
5. Use endpoint ownership for links: own the link with the source entity's Unique ID (the unique_id_a endpoint).

IoT and edge devices

• Register each device once with a Unique ID like device:your-domain.com:sensor-12.
• Use that same ID as owner_unique_id on every reading you store.
• Connection identity may change on every reconnect; device ownership must not.

Lifecycle and Account Changes

When the platform materializes your user into a new database, it records a materialized_in tag on your account event. That ledger drives operations like disabling an account across every database where your reference exists — without blindly scanning the entire platform.

If you rename or deprovision principals in custom integrations, plan to update or mark reference records in each ENM that holds them.

Quick Reference

Previous: How do I structure data in my ENM? — entities, tags, and relationships.

Next: How do I query data in my ENM? — retrieving and traversing your graph.