For engineering and procurement teams / Evaluation guide
Testing access-controlled memory for private AI
A relevant memory is only useful when the requesting user is allowed to receive it.The problem
Similarity does not decide permission
An AI memory store can retrieve a highly relevant record that belongs to someone else or has expired. If a team only measures how relevant the top result looks, it can miss the more important failure: the record should never have been available to that request.
For a company or government R&D team investigating private AI, access decisions belong in the retrieval and storage path. Source access makes that path inspectable, including the ordering of checks, the handling of invalid records, and the evidence returned with a result.
The retained proof
Make the forbidden answer look more attractive
Yodi's August 9, 2026 bounded memory proof indexes four typed records. It applies owner, scope, and expiry filters before dense scoring. An other-owner record and an expired record are deliberately more similar to the query than the correct eligible answer. Neither is admitted, and the one-result query returns the permitted record.
The bounded GPU scoring path and CPU reference produce the same selected result. The result carries memory attribution, so the retrieval outcome is not counted as model-only intelligence. The fixture also checks rejection of duplicate IDs, malformed records, and capacity or byte-budget overflow before index mutation.
A separate DynaCapDB adapter adds durable storage and restart recovery. Its retained integration stores Yodi memory, restarts the database, and checks the same authorized top result while excluding other-owner and expired records. The public project pages describe these mechanisms and their current scope.
A repeatable evaluation
Test permission and persistence together
Create a synthetic fixture with two owners, a valid record, an expired record, and an out-of-scope record. Make the excluded records unusually attractive to the scorer. Query as each owner and inspect both the selected result and its attribution.
Then persist the fixture, stop the process, restart it, and repeat the queries. Compare the authorized result and provenance with the original run. Keep this test separate from retrieval-quality measurements so an improved similarity score cannot hide an access failure.
- A denied or expired record never enters the eligible candidate set.
- Each returned result identifies the memory source used.
- The authorized result survives the documented restart path.
- Malformed or over-budget input fails without a partial index change.
- A broader evaluation uses new records and queries beyond the small retained fixture.
What remains to evaluate
Keep the claim as narrow as the evidence
Four records are a useful contract test, not a large deployment. The original proof explicitly leaves encryption at rest, deletion and tombstones, larger held-out workloads, and calibration as open work. Confirm the state of these capabilities in the specific release you receive rather than assuming a later demonstration is included.
Your own evaluation may also need concurrent access, identity changes, backup handling, key management, data residency, or additional operational controls. Name those requirements before making an adoption decision. Local execution and source visibility alone do not establish an agency authorization or security certification.
Source access
Bring the memory contract your team needs
Yodi and DynaCapDB are candidates to study when an engineering or research team wants to inspect how memory eligibility, scoring, and durable storage fit together. An evaluation should start from the exact eligible source release and a bounded workload.
Tell us the intended use, deployment environment, and access rules you need to test. We can discuss the relevant membership and whether additional engineering is needed.
