Databases & governed AI retrievalPublic field guide
DynaCapDB: records, search, SQL, and AI memory
DynaCapDB brings records, relationships, retrieval, and AI memory around a shared canonical store. Its central question is simple: can a team use the same governed information in several ways without keeping separate copies that gradually disagree? The current implementation offers bounded native proofs to investigate that question.
Start with a practical evaluationThe useful starting point
What DynaCapDB gives your team
A team can trace a search result, SQL row, or memory reference back to the same stored information and examine how permissions and recovery are applied.
Database engineers, application teams, and AI researchers dealing with provenance, multiple data views, and access-controlled retrieval.
- 01
Store a record
Keep content, properties, relationships, and provenance together.
- 02
Admit eligible data
Apply the relevant access and lifecycle rules before retrieval.
- 03
Read a useful view
Inspect records through supported search, graph, SQL, or memory paths.
One record, several useful views
The same business fact often appears in a table, a search index, a graph, and an AI context store. Every additional copy needs synchronization and its own interpretation of ownership and freshness. DynaCapDB explores several interfaces over a shared canonical record model.
The current native system includes text and vector retrieval, graph relationships, bounded context packs, and a read-only SQL view. That SQL surface has an explicit supported subset. Familiar query syntax does not imply compatibility with every SQL application or database extension.
Trust the recovery path, not just the first answer
Storage value becomes visible when work is interrupted. Write-ahead recovery, checksums, snapshot promotion, backups, and catalog rebuilding provide concrete mechanisms to examine. A trial should follow information through a restart and compare all relevant views.
Governed ingestion adds another useful question: can a team explain where an imported field came from and what happens when its source changes shape? Inspect mapping records, approvals, and lineage using a small synthetic import before considering a broad data migration.
Current public evidence
Verified native database slice
The Yeho-native executable proves ordered storage, WAL recovery, checksums, atomic promotion, backup, catalog rebuild, graph and hybrid retrieval, authorized read-only SQL, governed ingestion, and tenant transfer. Yodi independently proves identical authorized memory after a full restart while other-owner and expired records never enter ranking.
Explore the project and its evidenceTry one bounded question
Store once, query twice, then restart
A suggested evaluation for your team.
- Create a small synthetic dataset with two owners, one expired item, and explicit relationships.
- Query it through two supported interfaces and compare canonical identities.
- Confirm denied and expired records cannot become eligible retrieval candidates.
- Stop and restart the documented database path; compare the recovered records and results.
- Change an import field deliberately and inspect mapping, lineage, and approval behavior.
The same authorized information remains explainable across views and restart. Keep workload size, query subset, access rules, and recovery conditions in the evaluation record.
Before you go further
Common questions about DynaCapDB
Can DynaCapDB replace every database in our stack?
That needs workload-specific evidence. The current executable proves selected storage, retrieval, governance, and recovery contracts. Broad compatibility, large deployments, and operational requirements need their own evaluation.
What does permission before ranking mean?
A record must pass the relevant access and lifecycle checks before it can compete as a retrieval candidate. A high similarity score cannot grant access to an otherwise ineligible record.
Is the AI-memory restart result a scale benchmark?
No. It is a bounded integration proof with Yodi. It is useful for checking the contract, while capacity, concurrency, long-running behavior, and operational controls require separate trials.
From an idea to your first evaluation
Build on what you understand.
Start with DynaCapDB's public evidence. If it fits your team's problem, compare source memberships or tell us what you would like to evaluate.
These guides are free to read. Private source releases follow the membership license. Compare plans and team seats.