Foundation · 08

Nebulo — Identity, Data & Semantic Memory

Nebulo is Essence's data management layer. It replaces files and databases with Aptivs — storing everything with embedded structure, access rights, and behavior. There are no external data stores: identity, relationships, and policies travel with the data itself.

No files. No databases.

In conventional systems, data lives in files or database tables that are separate from the logic that operates on them. Access control, versioning, and schema enforcement are added as layers on top. When systems evolve, those layers drift out of sync.

Nebulo removes this separation entirely. All data is stored in Aptivs. Structure, access rights, behavior, and policy are embedded in each unit — not managed externally. Nothing is governed by a file path or a table schema that exists independently of the data it describes.

Identity — 128-bit HashIDs

Every unit of information in Nebulo is assigned a 128-bit HashID. These identifiers support high-speed search, duplication prevention, and fuzzy matching across distributed systems. The address space supports up to 10³⁸ unique identifiers — sufficient for any foreseeable scale of objects, behaviors, or versioned states.

Every change to a value is tracked over time using hash-indexed trees, delta compression, and memory-aware distribution. This makes synchronization across devices, simulations, and forks deterministic and auditable — without requiring a central coordination service.

The Guard — access without locks

Every Thing (Dz) in Nebulo has a Guard: a cryptographically enforced access controller that regulates what can read, modify, or reference it. The Guard applies the Guard (Che) Meaning Coordinate to every object, embedding access policy into the data structure itself rather than relying on external permission systems.

Conventional access control uses locking or symbolic ACLs, which introduce performance bottlenecks under concurrency. The Guard avoids this entirely by using job-based scheduling — determining access eligibility through procedural validation rather than through mutex contention or role lookup tables.

Key property

Who can access, change, or even know a Thing exists is baked into the structure at creation time. There is no separate permission layer to configure, drift, or be exploited.

Core mechanisms

Nebulo's fourteen foundational mechanisms group into five functional areas.

Identity and lookup

Structure and synchronization

Relationships and behavior

Parallelism and execution

Rendering and sensory output

How Nebulo compares to object-oriented systems

Nebulo is not object-oriented programming, though it shares surface similarities. The distinctions matter for architects evaluating how it fits alongside or replaces existing data layers.

Concept OOP (C++ / Java) Nebulo
Structure unit Class with static type definition Idea (Jy) — semantic, dynamic; translatable between representations
Data unit Object with getters / setters Thing (Dz) — access-governed, distributed, timing-controlled
Identity Memory address or database key 128-bit HashID with level-of-detail access patterns
Behavior Methods compiled to fixed logic Meaning Coordinates translated to Qcode; contextually resolved at runtime
Modules Packages or namespaces Aptivs — handle media, data models, localization, and behavior flow
Global variables Permitted; common source of bugs None — all values use multilevel scope and "when" semantics for updates
Concurrency Threads, mutexes, semaphores Explicit scheduling; dependency-tracked; side-effects prevented by design
Type system Static signatures declared at compile time Inferred from structure, timing, and reduction at runtime
Parallelism Manual; error-prone Automatically safe via Meaning Coordinate dependency tracking
Practical Takeaway

Nebulo eliminates the boundary between data and the logic that governs it. Identity, access policy, relationships, and behavior are embedded in every unit at creation time — not layered on afterward. For architects evaluating Essence, Nebulo is the replacement for both the database and the ORM: it stores meaning, not rows.