Track C2 / Cognee — executable governance complement qualification #89

Goal

Execute Cognee as a governance complement candidate under #87/#88, not as an OpenViking replacement.

Pin: topoteretes/cognee@690c0ec023719a2a277dc893cdecfec1ca8012cc.

Normalized gate

Using public supported API surfaces with backend access control enabled:

1. create active synthetic users A and B in one tenant;
2. A creates dataset M and writes a synthetic memory/object into it;
3. fresh B search/read of M is denied (Cognee may intentionally return empty results rather than 403; evidence must distinguish this from an empty dataset);
4. A explicitly grants B read on M through POST /permissions/datasets/{principal_id};
5. fresh B process can retrieve M;
6. A explicitly revokes B read through DELETE /permissions/datasets/{principal_id} while A, B and M all remain alive;
7. fresh B process can no longer retrieve M;
8. restart the bounded Cognee stack against the same storage;
9. B remains denied and A remains allowed;
10. inspect public permission/provenance evidence where available.

Required semantic checks

• share is the permission authorizing grant/revoke;
• no direct ACL table mutation;
• no application-side filter counted as provider ACL;
• dataset granularity must be recorded honestly: this qualifies a dataset/collection governance complement, not per-atom ACL;
• Yukh/OpenViking authority boundaries remain external.

Decision

• COMPLEMENT_PASS if grant/revoke enforcement and restart persistence pass through public supported seams with bounded self-host operation.
• PARTIAL if ACL works but operational/deployment or granularity constraints materially weaken the complement value.
• NO-GO if public grant/revoke cannot be exercised deterministically or enforcement is not provider-native.

Related: #63, #77, #87, #88, #86.