Slm Governance

slm-governance — Governed Workspace Behavior

SuperLocalMemory can run with named users and roles per workspace (company mode), keeps a compliance audit trail, applies a retention lifecycle, and ships GDPR export and erasure commands. This skill documents how an agent must behave in a governed workspace and what the governance tools really do. The MCP audit and retention tools are in the power tool set (see slm-profile).

Role model

By default SLM is single-user: whoever runs it is the owner and nothing asks for a login. Company mode adds named users, each with one role per workspace (profile). A role in one workspace grants nothing in another.

Agent behavior by role:

• Viewer: Only call recall, search, fetch, list_recent and other reads. Never call remember, update_memory, delete_memory or any write tool. If a write is refused, say so: "This workspace is read-only for my role."
• Member: May write memories, including scope="shared" and scope="global" when the user explicitly asks for them. May not delete memories or change users, roles or settings.
• Admin: Everything above plus deletion and user administration.

No MCP tool or slm command reports your role (only a signed-in dashboard session can ask the daemon, at GET /api/rbac/whoami). Do not guess it: attempt what the user asked and treat a permission refusal as final. Setting up users, roles and "Require login" is done in the dashboard under Settings → Access; there is no slm user or slm role command. The machine operator keeps user administration in every mode so a mistake cannot lock everyone out.

require-login

When login is required, every operation on memories needs a signed-in user, including the connection your assistant uses. SLM handles this at the daemon level; agents do not pass credentials in tool calls. If a tool call returns an authentication or permission error, you must:

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

In this mode, include_global=True and include_shared=True on recall are quietly turned off while the recall policy forbids cross-profile reads (the default), so an opt-in recall can come back with only personal facts. Do not try to work around it. See slm-scope.

Retention and lifecycle

Every memory moves through lifecycle states as it goes unused: active, warm, cold, archived. Two tools set and inspect that, and a third runs the forgetting cycle. They need the power tool set.

Set the thresholds

set_retention_policy(
  cold_after_days: int = 30,      # days of inactivity before a memory goes cold
  archive_after_days: int = 90,   # days before it is archived
)

It sets two thresholds and returns them. There is no profile_id argument and there are no named retention zones or per-tag policies; tagging a memory does not route it to a different policy.

Look at the state

get_retention_stats(profile_id="")
get_lifecycle_status(limit=50, profile_id="")

get_retention_stats reports, from the retention table, the count and average retention score per Ebbinghaus zone (active, warm, cold, archive, forgotten) and the totals. get_lifecycle_status counts the active, warm, cold and archived state of up to limit memories and returns up to ten short samples of each. Neither says when the next cycle runs.

Apply it

forget(dry_run=True)          # preview the decay cycle for the active profile
compact_memories(dry_run=True) # preview lifecycle-state transitions

The MCP forget tool is not a delete: it recomputes retention scores and moves memories between zones. compact_memories moves memories whose lifecycle state has become due (for example cold to archived); it does not merge duplicates. Both default to a dry run. Run the preview first, show it to the user, and only then pass dry_run=False. Do not run either without the user's say-so.