Track C2 / Memory governance complement — Cognee vs TencentDB-Agent-Memory #87

Goal

Evaluate whether a complementary memory-governance specialist materially closes the only concrete gap left by OpenViking OV-5 PARTIAL (#86), without replacing OpenViking as the qualified Context Plane + base persistent memory foundation.

Governed by #63/#77. OpenViking baseline is fixed by #80/#83/#86.

Missing contract to close

A candidate is relevant only if it can prove, through supported public APIs in a bounded self-host profile:

1. granular visibility on memory / namespace / collection objects;
2. explicit grant/share/revoke between active users or teams;
3. revocation without deleting the user or the memory object;
4. revocation persistence across restart/replication;
5. auditable ACL/provenance evidence;
6. deterministic identity mapping and fresh-client enforcement;
7. clean coexistence with OpenViking and Yukh authority boundaries.

User deletion, namespace convention, metadata tags, or application-side filtering alone do not count as ACL/revocation.

Candidates

Cognee

Evaluate current public repo/docs for identity, dataset/collection sharing, permissions, tenant isolation, explicit revoke semantics, and self-hostability.

TencentDB-Agent-Memory

Evaluate current public repo/docs for memory scopes, users/teams, access control, sharing/revocation semantics, storage/runtime dependencies, and self-hostability.

OpenViking baseline/control

No new OpenViking qualification unless upstream exposes a public granular grant/revoke seam that directly addresses the missing contract. Existing OV-5 remains the control: strong user isolation + durable identity revocation, but no proven standalone per-memory/team ACL revoke.

Phase 1 — falsifiable seam discovery

For each specialist record:

• exact public APIs / SDK calls;
• semantic object being protected (memory, dataset, collection, namespace, graph, etc.);
• subject model (user/team/role/service principal);
• grant/share operation;
• revoke operation;
• enforcement point;
• persistence model;
• audit/provenance surface;
• auth/identity assumptions;
• required external services;
• whether the semantics are provider-native or must be implemented by the Yukh adapter.

If no native public grant/revoke exists, mark the candidate NO-GO FOR GOVERNANCE COMPLEMENT rather than broadening the scope.

Phase 2 — executable qualification

Only candidates surviving Phase 1 get a bounded executable gate:

• create active users A/B;
• create memory/object M owned by A;
• B denied initially;
• explicit grant M→B;
• fresh B process reads M;
• explicit revoke M→B while A, B and M remain alive;
• fresh B process is denied;
• restart same storage/runtime;
• B remains denied;
• A remains able to read;
• Yukh accepted fact remains external/non-authoritative to memory provider.

Decision

• COMPLEMENT_PASS — materially closes the OV-5 gap with native supported semantics and bounded operational cost.
• PARTIAL — has useful sharing/tenant features but does not fully close grant/revoke semantics.
• NO-GO — lacks native public semantics, requires private storage mutation, or duplicates OpenViking without closing the gap.

Do not select a specialist simply because it is a good memory system. The burden of proof is that it closes this exact governance gap with less complexity than implementing the policy layer in Yukh itself.

Related: #63, #77, #81, #84, #86.