You give an AI assistant access to a project folder. It extracts passages, builds a search index, connects people and events, and saves a useful answer. Later, a contractor leaves the project. Removing access to the folder is only the beginning. The information has acquired a second life.
We’re building 8DB around a clear ambition: keep control of information as it becomes intelligence. The documents, relationships, search representations and stored answers that support AI should remain connected to their sources and conditions of use. That would let organizations put more of their knowledge to work with a clearer account of who can use it and what happens when circumstances change.
Follow the information beyond the file
Consider an engineering team investigating a recurring equipment fault. A supplier report describes a defect. An inspection record identifies affected machines. A maintenance assistant combines both and recommends which equipment needs attention.
Each step adds value. Each also creates a new responsibility. The search representation must lead back to the correct source version. An extracted relationship needs to distinguish a documented fact from an interpretation. The recommendation needs to show which evidence supports it. Access to the original report and permission to receive the resulting answer need an explicit relationship.
A confidential report can remain confidential after it has been summarized. A changed inspection can undermine a previously reasonable recommendation. A cached answer can outlive the permission under which it was created. These are ordinary events in a working system, and they belong in its design.
| Transformation | What the next step needs to retain |
|---|---|
| Report to searchable passages | Source identity, exact version and applicable access rules |
| Passages to relationships | Supporting passages and the difference between observation and inference |
| Relationships to a recommendation | Required evidence, assumptions and permitted audience |
| Recommendation to stored AI context | Dependencies and a rule for review when evidence or authority changes |
This is the contract we want the complete workflow to fulfil. Putting these objects in one database creates an opportunity to coordinate that contract. The transformations still need to record their dependencies and preserve the properties their next operation requires.
Give the database more of the responsibility
8DB is an omnimodal database: an engine built to work with different kinds of data and their native structures. Its evidence machinery includes operations for reading values with recorded lineage, maintaining confidence indexes with updates, and evaluating evidence conditions. Those capabilities make a stronger foundation for AI than leaving every application to invent its own conventions for origins, support and change.
Our protection work brings a related question into the engine: does the caller still have authority at the point the data is released? In a bounded Linux test of the entity read cache, a read that had previously succeeded was denied after the relevant grant was revoked, before the cache or backend returned data. Separate killed-writer tests exercised recovery at defined publication boundaries. The public evidence explains the tested paths and outcomes. [1]
Those results address two practical concerns: an old permission should not become a permanent entitlement, and an interrupted update should not leave recovery guessing which state to trust. Our wider goal is to carry that discipline through the complete path from source material to AI context.
Make change understandable
Imagine the supplier withdraws its report. In the workflow we are working toward, an authorized reviewer could see which recommendations depended on it, which have independent support, and which need to be rebuilt. The historical answer would remain explainable while its suitability for current use changes.
The same principle applies when access changes. The system needs to re-evaluate the stored material it controls and the operations that expose it. An answer already delivered to someone or copied to an outside service has crossed another boundary; control there requires that destination’s own safeguards. This makes the decision about what to send to an AI provider part of the product, alongside the decision about what the assistant may read.
For an integrator, the opportunity is less repeated engineering to reconcile identity, evidence, permissions and recovery across services. For a customer, it is a more useful answer to a simple question: can we still rely on this, and who may use it now?
Build intelligence that remains accountable
There are capable databases, knowledge platforms and authorization systems already doing important parts of this work. The case for 8DB is the combination we are pursuing: rich native operations, evidence that participates in those operations, and protection close to the point of use. The value will come from making that combination easier to adopt and maintain in real applications.
CodeGraph gives this direction a concrete product expression. A software change can affect a requirement, a test and a customer promise. Beyond software, a changed document can affect a project plan, a recommendation and the context supplied to an assistant. Keeping those connections useful gives people a way to benefit from AI while retaining a say in how their knowledge travels.
Choose one workflow where a changed fact or permission would matter. Bring its sources, the answer people need and the conditions that should stop that answer being used. We can use that example to define a focused evaluation of 8DB, including the work your team would need to own. [2]
Continue the series
Sources
- [1] Protection lifecycle evidence and tested scope
- Native data structures and the 8DB architecture
- How current authority relates to protected data access
- [2] Define an 8DB evaluation
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work