Guiding / Research

Database Architecture

I have been exploring a question that keeps showing up across everything I build: what should a database become when software, AI agents, users, files, code, memory, and validation all need to live together? Most databases are built around one shape of information, rows, documents, objects, vectors, graphs, or files, but modern AI native systems increasingly need many shapes at once, plus the ability to know where information came from, how it changed, why something matched, and whether it can be trusted. I am calling the current direction NexusDB. It is not finished, and I do not want to present it as if it is. This is an active research and architecture project, currently at the Genesis level. After about six months of research, the core evidence kernel has just come into focus.

Guiding / Research

Exploring evidence native databases, semantic storage, and NexusDB

Why this mattered

Most databases store data. NexusDB is exploring storing evidence. A real AI native system may need to store raw files, decoded meaning, search history, model outputs, user context, relationships, validation results, contradictions, operational events, backups, and long term memory, and it needs to keep them connected. Traditional databases can store parts of that, but the architecture usually gets split across object storage, SQL, vector DBs, logs, search indexes, graph stores, file storage, analytics, and agent memory. The question driving this work is whether those pieces can be unified into one evidence native substrate where every record can answer: where did it come from, why did it match, what supports it, what changed, was it validated, and can an agent safely use it.

Current status

Active architecture research and exploration. This page describes the questions and direction; it does not claim a finished database product, benchmark result, or production deployment.

What Gordon explored

Raw Evidence as the anchor. Everything starts with raw evidence, files, blobs, documents, code, logs, chats, images, records, scientific data, or app data. The raw source should not disappear after a summary, label, or model output is created. The raw evidence is what every later interpretation traces back to.

BraidRecords as the bridge between raw data and structured meaning. A BraidRecord can hold the identity of the original evidence, decoded concepts, structural information, metadata, tenant context, lifecycle state, and the decoder version that produced the interpretation. The goal is to make evidence durable and traceable.

A semantic understanding layer where raw data becomes searchable before it is perfectly labeled. Instead of treating information only as plain text chunks or opaque vectors, the system decodes data into layers of meaning, low level structure, format patterns, concept edges, motif relationships, labels and candidate labels, validators and refutations. The important principle: semantic output should not automatically become truth, it should become evidence that can be validated, challenged, promoted, or rejected.

OTP style search and traversal. UDU / TIE / Braid makes evidence understandable; OTP makes that evidence searchable. A query becomes weighted concept seeds that move through concepts, relationships, validators, labels, and evidence records. Stronger, more validated paths carry more relevance. The goal is search that can explain itself, not just 'this result is similar' but 'this result was reached through these concepts, these relationships, this validator, this source evidence, and this permission scope.'

Security and trust inside the evidence model itself, not just a login screen on top of it. The current mental model: BraidHash gives integrity, Nexus Caps give authority, Raw Vault and KMS give confidentiality, validators give evidence discipline. Together this forms the early shape of what I think of as the Nexus Trust Fabric, covering tenant isolation, capability based access, content identity through hashes, encrypted raw storage, key management, hydration permissions, audit logs, validation trails, plugin safety, and agent scoped access.

Plugin based domains so the core stays generic. A code plugin might understand repositories, symbols, functions, files, dependencies, and patches. A docs plugin might understand sections, citations, summaries, policies, and claims. A science plugin might understand observations, samples, instruments, measurements, and validations. The core stores evidence; plugins add domain meaning.

A thermal version lineage to organize how the architecture grows over time: Genesis → Lava → Magma → Plasma → Zero Disk. Genesis is the first foundation where the database starts becoming evidence native instead of just app storage. Lava is the active flow layer where evidence enters and becomes usable. Magma is the deeper storage engine direction, WAL, memtables, SSTables, compaction, snapshots, native indexing, durability. Plasma is the intelligent optimization horizon, heat aware placement, semantic confidence, probability flow, validation weight. Zero Disk is the object store native, cloud scale persistence horizon. The current work is at Genesis.

Proof at a glance

After about six months of research, the core evidence kernel has come into focus, the idea that the database should store evidence, not just data, and that raw source, decoded meaning, relationships, validation, and memory should stay connected inside one substrate.
An early Genesis level architecture direction in active development: a Rust based NexusDB runtime direction, blob centric data flow, decoder backed evidence records, labeled and unlabeled search, compare as data foundations, BraidRecord architecture, concept indexes, a plugin registry direction, code and docs plugin proof directions, operational stats, backup/export/import evidence surfaces, object storage smoke evidence, and an agent / dogfood memory loop direction.
A working language for the architecture, Raw Evidence, BraidRecords, semantic understanding, OTP style search, Nexus Trust Fabric, plugin based domains, and the Genesis → Lava → Magma → Plasma → Zero Disk lineage, that makes it possible to reason about the system, share it with collaborators, and tell which pieces are working foundation, which are prototype direction, and which are still research horizon.
Many open questions remain around storage engine design, scale, cost, durability, permission checks, query planning, developer ergonomics, and how much should live in the core versus in plugins. The current goal is not to claim NexusDB is finished, it is to keep developing the architecture, test the assumptions, build useful slices, and find the right path toward an evidence native database that can support real AI native systems.

Project record reviewed August 30, 2026. Where no public source is listed, the page identifies first person or internal evidence explicitly instead of implying independent verification.