Track C2 / OpenViking OV-5 — qualify visibility, isolation and revocation #84

Goal

Execute OpenViking OV-5 visibility / isolation / revocation after OV-4 PASS (#83), governed by #63/#77/#81.

Candidate remains pinned to volcengine/OpenViking@234a2d9fe778a9512fd7ebe9807198e847c647ec unless an explicit pin change is justified before execution.

This is the decisive memory-governance gate before considering an OPENVIKING_ALONE Track C2 verdict.

Mandatory boundary

OpenViking memory remains contextual and non-authoritative. Visibility or revocation behavior MUST NOT grant authority, evidence truth, coordination ownership, or accepted-state semantics.

OV-5A — identity-scoped visibility

Using supported public SDK/API surfaces and synthetic identities, create memory under user A and prove:

• user A can resolve/read its memory;
• user B cannot resolve/read user A private memory through ordinary supported user-scoped APIs;
• namespace/identity evidence is explicit and canonical;
• no hard-coded storage mutation or private DB access is used.

If the pinned dev profile cannot enforce this, use the narrowest documented bounded auth profile that can be exercised deterministically. Do not manufacture isolation in the Yukh harness and attribute it to OpenViking.

OV-5B — peer/team visibility

Where supported publicly, exercise self/peer or equivalent scoped memory semantics with at least two actor peers. Prove what is shared, what remains private, and whether visibility is controlled by account/user/peer policy or merely namespace convention.

Record unsupported dimensions explicitly rather than inferring ACL semantics from URI shape.

OV-5C — revocation/deletion

Through a supported public seam, revoke/delete a previously visible memory or the identity/access path that made it visible. Then prove with a fresh process/client lifetime that the revoked memory is no longer readable/resolvable by the revoked scope.

Distinguish:

• content deletion;
• access revocation;
• identity/user removal;
• cache/index lag.

A deletion-only capability MUST NOT be reported as ACL revocation.

OV-5D — restart persistence of revocation

Restart OpenViking against the same storage after revocation and prove the revoked visibility does not reappear.

OV-5E — fail-closed authority behavior

Regardless of provider visibility/revocation state, prove an external accepted Yukh fact remains independently addressable and authoritative. Provider ACL availability must never become Yukh authority availability.

Evidence

Record at minimum:

• candidate revision;
• exact public identity/auth/ACL seams used;
• account/user/actor-peer mapping;
• canonical memory URI/ref and digest;
• visibility matrix before revocation;
• revocation operation and semantic class (delete vs access revoke vs identity removal);
• visibility matrix after revocation and after restart;
• separate client process IDs/lifetimes;
• bounded model configuration and precise model-egress claim (do not claim general egress observation unless instrumented);
• candidate-specific limitations/assumptions;
• external accepted-fact authority evidence.

Decision

• PASS — supported public seams provide the visibility/isolation/revocation semantics Yukh requires, with restart persistence and fail-closed authority behavior.
• PARTIAL — useful identity isolation exists but a required revocation/team dimension is missing or deletion-only.
• QUALIFICATION_GAP — deterministic qualification requires private APIs, direct storage mutation, production credentials, or an unbounded external dependency.
• FAIL — supported semantics allow cross-scope leakage or revoked access to reappear in a way incompatible with the mandatory boundary.

Only a PASS, together with prior OV gates and remaining #63 criteria, can support an OPENVIKING_ALONE verdict. A PARTIAL/GAP is the trigger to evaluate a complementary memory specialist rather than forcing OpenViking to own semantics it does not provide.

Guardrails

• no Cognee/TencentDB yet;
• no private APIs/database mutation;
• no production/personal data;
• no weakening identity isolation in the harness and calling it provider isolation;
• no conflation of delete with revoke;
• no new Yukh memory repository;
• memory remains context/proposal, never authority.

Related: #63, #77, #81, #83.