G3: No native multi-tenant scoping — group_id must be property-filtered

G3: No native multi-tenant scoping — group_id must be property-filtered

Gap Description

The crate provides no native tenant-scoped graph. All filtering must be done adapter-side on every query.

Evidence

• group_id must be stored as a node property.
• Every read must filter WHERE (n.group_id = ?).
• Cypher queries have no WHERE clause support — no property filter in Cypher.

Use Case (Allura's governed memory)

Allura enforces tenant isolation at schema level. Every memory belongs to a group_id. Cross-tenant reads are security violations.

Proposed Fixes

Option A — Document and enforce adapter-side filtering (short term)

Current enforcement in ruvector-crate-adapter.ts filters every result.

Option B — Recommend per-tenant GraphDatabase.open (medium term)

Each tenant instantiates their own GraphDatabase.open(path).

Option C — Add native graph/workspace scoping (preferred long term)

Add create_workspace, select_workspace, delete_workspace.

Can Allura contribute a PR?

Yes — Allura can add workspace API to ruvector-graph crate.

Author: Brooks (Allura architect), Date: 2026-07-12

Start with ruvector-crate-adapter.ts, where current adapter-side filtering is described, and review GraphDatabase.open and the stated Cypher query limitations. Compare the three proposed scoping approaches; done requires a decided tenant-isolation design and an agreed implementation scope.