Namespace isolation and control
MemQ enforces plan-aware namespace boundaries between individuals, teams, and governed shared knowledge. Private memory stays private, team memory stays inside the authorized team, and _commonsremains a separate shared layer.
Namespace boundaries
The foundation of MemQ governance is the Namespace. Every authenticated MCP session resolves to a primary namespace and a namespace scope from Billing Manager. MemQ uses that scope to decide which private memory can be written, searched, recalled, or reflected.
Boundary guarantees
Team plans: A team API key reads and writes only inside its authenticated org:<team> namespace. Requests that include a foreign ns:* tag are reduced to an empty private result instead of querying another team.
Individual plans: Personal memory is bound to the authenticated user:<id> or key namespace. Another user's namespace is not searchable through filters, recent-memory reads, or direct get_memory calls.
Shared commons: _commons is not mixed into private search. Clients read shared approved knowledge through explicit commons_search, while private search requires a private namespace scope.
Direct memory reads: get_memory checks the stored namespace tags before returning a record. If the memory belongs to a namespace outside the authenticated scope, MemQ denies the read.
How the runtime enforces it
Namespace enforcement happens server-side. Client-supplied metadata or tags can narrow a search, but they cannot expand access beyond the authenticated namespace scope.
- The handshake resolves one primary private namespace for the current credential.
- Private search, recent memory, hybrid retrieval, and reflection use that primary namespace tag as the effective private boundary.
- Foreign namespace tags are rejected before storage search, so the backend is not asked to rank another tenant's records.
- Reserved namespace tags such as
ns:_commonscannot be injected into private writes by a client request. - Use
namespace_infoto verify the namespace, namespace tag, readable scope, tier, and quota attached to the active API key.
Complexity scaling and governance
As agent ecosystems grow, so does the complexity of the memory fabric. MemQ uses autonomous complexity scaling to prevent "memory bloat" and ensure compliance standards are maintained.
- Automated Pruning: Low-reputation episodic memories that do not map to successful outcomes naturally decay over time to save compute and storage.
- Ledger Integrity: Every state change to a memory (creation, promotion, decay, or retraction) is recorded in an immutable journal format for compliance audits (e.g., ISO 42001).
The Redaction Protocol (Retraction)
When AI systems record inaccurate, sensitive, or prohibited information, it must be purged completely from the knowledge graph and vector indices while leaving a compliant audit trail.
# 1. Identify the rogue memory ID
query_memory (query: "sensitive project X")
# 2. Retract it from the Commons or specific Namespace
commons_retract (
id: "uuid-of-the-memory",
reason: "PII leak violation",
requested_by: "secops-admin-1"
)
What happens during retraction?
1. Vector Purge: The embedding is deleted from the WARM tier.
2. Graph Disconnect: The entity/relationship is tombstoned in the COLD tier, breaking any associative pathways to the memory.
3. Audit Tombstone: A permanent cryptographically signed tombstone ledger is written to the JOURNAL tier, proving the deletion occurred for regulatory compliance.