slm-governance

name	slm-governance
description	Enterprise compliance and governed workspace behavior for SuperLocalMemory. Covers role-based access (admin/member/viewer), retention policies, audit trail, GDPR data export/erase, and how agents must behave when operating under workspace governance. Requires power MCP profile for audit/retention tools. Agents must never bypass governance controls.
when_to_use	- "What can I do in this workspace?" (role check) - "Set a 90-day retention policy on this memory" - "Show the audit trail for recent memory operations" - "Export my data for GDPR compliance" - "Delete all memories for user X (right to erasure)" - "Configure require-login for this workspace" - Enterprise deployment with multi-team shared SLM - Compliance, audit, or data governance task
allowed-tools	audit_trail, set_retention_policy, get_retention_stats, get_lifecycle_status, recall, search, remember, Bash

slm-governance — Enterprise Compliance and Governed Workspace Behavior

SuperLocalMemory supports enterprise deployments with role-based access control, retention policies, audit logging, and GDPR compliance tooling. This skill documents how agents must behave when operating in a governed workspace and how to use the governance MCP tools (available in the power profile).

---

Role model

Governed workspaces have three roles:

Role	Read	Write personal	Write shared/global	Admin operations
viewer	Yes	No	No	No
member	Yes	Yes	Yes (within access list)	No
admin	Yes	Yes	Yes (unrestricted)	Yes

Agent behavior by role:

• Viewer: Only call recall, search, fetch, list_recent. Never call remember, update_memory, forget, or any write tool. If a write is attempted, fail gracefully: "This workspace is read-only in viewer mode."
• Member: May write personal facts and shared facts with permitted profiles. May NOT write scope="global" facts without explicit admin authorization. May NOT call set_retention_policy, audit_trail, or compact_memories.
• Admin: Full access including governance tools in the power profile.

An agent operating in a governed workspace must check its role before any write operation. Role information is visible in workspace configuration or via slm status --json (the role field, if present).

---

Retention policies

Retention policies control how long facts are stored before they become eligible for decay. Available in the power MCP profile.

Set a retention policy

set_retention_policy(
  profile_id: str = "",   # "" = active profile
  days: int = 90,         # facts older than this become decay-eligible
  zone: str = "default",  # retention zone name
)

Retention zones let you apply different policies to different fact categories:

# Standard facts: 90-day retention
set_retention_policy(profile_id="", days=90, zone="default")

# Security findings: 365-day retention (compliance requirement)
set_retention_policy(profile_id="", days=365, zone="security")

Tag your facts with the zone name to route them to the right policy:

remember(content="Critical auth bypass in v2.1", tags="security,cve,finding", ...)

Check retention statistics

get_retention_stats()

Returns zone distribution, average fact age, and decay-eligible counts. Use this to verify policies are working as expected.

Check lifecycle status

get_lifecycle_status()

Reports the state of the retention and decay subsystem — whether decay cycles are running, when the next cycle runs, and any backlog.

---

Audit trail

audit_trail is available in the power profile. It returns a structured log of recent memory operations (writes, reads, profile switches, policy changes).

audit_trail(
  limit: int = 50,          # number of entries to return
  operation: str = "",      # filter by operation type (e.g. "remember", "forget")
  profile_id: str = "",     # filter by profile; "" = active profile
)

Use this for:

• Compliance reviews ("what data was written in the last 30 days?")
• Investigating unexpected memory changes
• Generating audit reports for data controllers

The audit trail covers MCP and CLI operations. It does not record the content of facts by default — only operation type, timestamp, agent ID, and fact ID.

---

GDPR compliance

Data export

SLM does not have a dedicated MCP export tool. For GDPR data subject access requests, use the CLI:

# Export all memories in a profile to JSON
slm status --json     # confirm active profile
slm list --limit 9999 --json > export.json

For a complete export including entity graph data, run:

slm status --json

Contact your workspace admin to arrange a full database-level export if the CLI output is insufficient for compliance purposes.

Right to erasure

To erase all memories for a subject or project:

# Step 1: preview what will be deleted (ALWAYS do this first)
slm forget "<subject or project name>" --dry-run --json

# Step 2: review the preview, then execute
slm forget "<subject or project name>" --yes --json

For targeted deletion by fact ID:

slm delete <fact_id> --yes --json

For data reconstruction prevention: after erasure, confirm the fact is gone by running slm recall "<content>". A successful erasure returns no results. Never attempt to re-derive erased content from other stored facts.

---

require-login

When require_login is enabled in workspace configuration, agents must authenticate before any memory operation. SLM handles authentication at the daemon level — agents do not need to pass credentials in tool calls. If an agent receives an authentication error from any MCP tool, it must:

1. Stop the current operation immediately.
2. Report the authentication requirement to the user.
3. Never cache, retry, or work around the authentication block.

---

Scope enforcement in governed workspaces

In a governed workspace, scope restrictions are enforced server-side:

• Viewers cannot write any fact regardless of scope parameter.
• Members cannot write scope="global" unless their access list includes the global scope — attempts return a permission error.
• Admins can write any scope.

Agents must not attempt to work around scope restrictions by splitting a global fact into multiple shared facts to accumulate equivalent visibility.

---

Compact memories (admin-only)

compact_memories deduplicates and consolidates stored memories. This is an admin operation — it can change fact IDs and remove content.

compact_memories(
  profile_id: str = "",   # "" = active profile
  dry_run: bool = True,   # ALWAYS true first — inspect before running
)

Always run with dry_run=True first and review the impact report. Never run compaction without admin authorization.

---

Consistency check (admin-only)

consistency_check(profile_id: str = "")

Verifies data integrity of the memory store — checks for orphaned entities, broken references, and index-database mismatches. Use after migrations or unexpected shutdowns. Returns a structured report.

---

Agent checklist for governed workspaces

Before each write operation:

• Confirm my role allows writes (viewer → skip; member/admin → proceed)
• Confirm scope is appropriate for my role (member → no global)
• Set correct tags including zone name if retention policy applies
• Pass session_id for full audit attribution

Before running any destructive operation (forget, compact_memories):

• Admin authorization confirmed
• Ran with dry_run=True and reviewed output
• GDPR: confirmed the subject or controller authorized the erasure

---

Related skills

• slm-scope — scope model details (personal/shared/global)
• slm-profile — workspace isolation and profile switching
• slm-remember — fact storage reference (includes scope parameters)
• slm-recall — retrieval reference (includes scope read flags)
• slm-mesh — mesh tools (full/power profiles)

---

SuperLocalMemory v4.1.11 · Qualixar · AGPL-3.0-or-later