Put more information to work.
Connect records, documents, relationships and vectors in applications that understand their context. Make sensitive knowledge useful while keeping its owner’s rules part of the design.
8DB / Security & governance
Keep control as your data
becomes intelligence.
8DB brings native data models, cryptography and governance into one embeddable engine. Our vision is protection that follows information through storage, search, AI context and recovery.
Useful information.Lasting control.One shared foundation.
01 / Information becomes more valuable when it connects
A document becomes a relationship.
Context becomes an answer.
The next generation of applications will work across all of these forms. We are building 8DB so that each transformation can carry the source’s rules forward, alongside the knowledge it creates.
- 01
Document
The original knowledgeA record with a source and an owner.
- 02
Relationship
The connections that matterLink information to people, assets and events.
- 03
AI context
The knowledge in useFind the evidence an application needs.
- 04
Stored answer
The knowledge createdKeep the result connected to its sources.
Keep security decisions effective.
Design permission changes to reach stored derivatives and cached results. Recovery should preserve the decisions that determine who can see what.
Build on security you can reuse.
Bring protection, authority and recovery into the data engine. The goal is a common foundation that application teams can integrate, test and explain across products.
02 / The moments that matter
A backup should restore your work
without undoing your security decisions.
Ask the current authority.
A useful answer may draw on several sources. The design must connect those dependencies to the access decision, including when an earlier result is already in a cache.
Recover a coherent state.
Protected data, its index and its authority must agree. The foundation is designed to recover a consistent state or refuse the read when that agreement cannot be established.
Make freshness explicit.
Plan how the device learns which permissions and keys are current. That policy connects local availability, reconnection and the treatment of restored copies.
03 / The foundation we are building
One architecture for useful data
and lasting control.
The shared protection foundation brings three responsibilities together beneath the application. It connects the bytes on disk to the rules for using them and the state recovered after a failure.
Physical protection
Protect stored structures, bind them to an authenticated map and detect altered or mismatched data before exposing it.
Follow the storage design →Semantic control
Keep permissions and source dependencies meaningful as information becomes documents, graph relationships, vectors and saved results.
Inspect the authority and cache result →Coherent recovery
Publish data and authority as a consistent state. Establish the trust needed to reopen it, and refuse incompatible state rather than return an apparently valid answer.
Inspect interrupted-write behavior →For products such as CodeGraph, this vision extends beyond code: connect source material, its relationships and AI context on the same governed foundation.
04 / Follow the evidence
Inspect the behavior behind the design.
The September 29 engineering collection records Linux experiments on authority after cache reuse, interrupted protected writes and startup file handling. Each result is tied to its source revision, configuration and observed boundary.
Explore the dated evidence →Existing capabilities and implementation detail
Who can open the next message?
The inspected channel path encrypts a message body once and wraps its content key for the current recipient list. Removing someone from the sender’s list excludes them from newly sealed recipient slots. Membership agreement after restart, replay handling and previously received content require separate checks. This source review is distinct from the qualified lexical node-exchange path.
Read the dated implementation summary →Protected reuse for repeated documents
The inspected Vault consumer stores repeated blob content as encrypted chunks and retrieves it through a sealed manifest. This creates a practical evaluation for document-heavy applications: measure complete stored bytes and interrupted-write recovery. The current route commits chunks and manifests separately and has a whole-blob fallback; earlier in-memory ratios do not measure this durable path.
Read the dated implementation summary →Key custody and recovery
Identify the key material, derivation inputs, recovery authority and backup responsibilities in the selected profile. “No external KMS required” is not a claim that recovery needs no secrets or operational controls.
Permissions and revocation
Specify who can read, modify or receive data. Test changes against offline and restored devices. Revoking future access cannot retract plaintext a recipient already copied.
Erasure and retained evidence
Our erasure research examines how a system can preserve necessary history while retiring access to protected content. Define the data, copies, legal retention and recovery boundaries before treating an erasure operation as complete.
Read the erasure article →Cryptographic change
The published encryption reference covers migration evidence and constraints. Ask how algorithm identifiers, older data, compatibility, rollback and resource limits are handled in your selected release.
Inspect the cryptographic path →Standards and assurance
Algorithm choices, tested implementation, validated cryptographic modules and regulatory approval are different kinds of evidence. Agree on the assurance your organization needs; this page does not claim a compliance certification.
Where application and deployment decisions enter the design
Source permissions govern the operations and stored derivatives brought under this foundation. An authorized reader can see plaintext; plaintext exported outside the system cannot be recalled. Disconnected devices need an explicit authority-freshness policy. Root-secret custody, trusted endpoint software and protection against rollback of the entire host or trust anchor belong in the deployment’s threat model.
The linked evidence identifies tested components and conditions. Full application workflows, additional platforms and formal certifications require their own qualification.
Build the next useful application