# Governance and retention

Read the current governance posture for retention, deletion, export, data boundaries, and audit evidence.

- Canonical: https://docs.xmemo.dev/docs/concepts/governance-retention
- Locale: en-US
- Content-Locale: en-US
- Canonical-Content-Digest: 64872f32f2fa2549e9b806845665721e6289a5b6fe5d9e8dc96165599625c17b
- Edition-Digest: 3ff42eb1a645166cc028cd220777f0ac2d9f37abddf7d31a89fc26a39e654c5a
- Source-Revision: sha256:47f2eb881bc452bf2c7284e56f7b3ce65901de5335e31c6b20f6047355dc4f40

## Retention is managed by the service today

The current MeGovernanceResponse reports retention.status=operator_managed and retention.available=false. Automated retention rules are not configurable per account; archive, forget, and clear actions require explicit account action. This page describes the implemented posture, not a promise of an automatic retention schedule.

```json
{
  "retention": {
    "status": "operator_managed",
    "available": false
  },
  "delete": {
    "status": "self_service",
    "available": true
  }
}
```

## Deletion and export have separate postures

Individual memory deletion is self-service. Account-level closure revokes access and queues a Personal purge workflow; the response contract says team-shared data remains with the Team. Export is either self-service download or request-only depending on the runtime configuration, and prepared artifacts expire automatically.

- delete — self-service individual memory deletion is available.
- export — status is self_service_download only when the runtime enables it; otherwise request_only.
- data_boundary — account-scoped; no cross-account access is permitted.

## Governance actions leave audit evidence

The governance response reports audit.status=enabled and describes account actions as emitting audit events; audit-log access and self-service audit export remain managed by the service team. Memory deletion also records mode, reason presence, and target references in the memory audit outbox without retaining forgotten content in the public result.

```json
{
  "data_boundary": {
    "status": "account_scoped",
    "available": true
  },
  "audit": {
    "status": "enabled",
    "available": true
  }
}
```

## Check the effective posture before choosing a mode

Security mode and governance posture are separate controls. Cloud mode permits server-side processing; Keyguard uses customer key wrapping with audited temporary decrypt; Vault keeps memory bodies client-encrypted and normally requires local recall. Choose retention, deletion, and security handling based on the current response contracts rather than assuming one setting controls all three.

```text
retention  = operator_managed
delete     = self_service
audit      = enabled
security   = resolve the effective Cloud, Keyguard, or Vault mode
```

## ChatGPT user

Give ChatGPT durable access to your XMemo preferences, project facts, decisions, and TODOs without pasting bearer tokens into a chat.

Connect the hosted XMemo MCP server through the ChatGPT/OpenAI app OAuth flow, then approve the memory:read and memory:write grant for your XMemo account.

Save a synthetic preference or project note, start a new chat, then ask ChatGPT to recall it through XMemo before continuing work.

If OAuth fails or tools do not appear, sign out of the MCP server in the host app, reconnect the XMemo server URL, and retry before creating direct tokens.

## Copilot / Codex developer

Carry repo decisions, coding conventions, bug-fix notes, and task history between IDE and CLI agents.

Use OAuth for VS Code / GitHub Copilot and Gemini CLI when available. For Copilot CLI, Codex, Cursor, or other direct MCP clients, keep XMEMO_KEY in the local environment or secret store and set a stable XMEMO_AGENT_INSTANCE_ID.

Record a codebase decision or bug fix, then ask the next IDE or CLI agent to recall the relevant XMemo context before editing.

If recalls are empty, verify the selected MCP config path, the XMEMO_KEY environment variable for direct clients, and any stale OAuth credential in the host app.

## Team / enterprise pilot owner

Evaluate shared memory with account controls, source attribution, export/delete workflows, and reviewer-safe setup evidence.

Create or enter the protected XMemo workspace, invite approved users, then connect each client through OAuth or a scoped direct credential according to the readiness badges.

Have a pilot member save a synthetic team memory, confirm source attribution in XMemo, then review delete/export and support paths.

If a member cannot connect, check role permissions, OAuth approval, client readiness status, and support guidance before issuing a new token.

## Autonomous agent operator

Let headless or scheduled agents record progress, retrieve prior decisions, and keep a stable non-secret instance identity.

Fetch /api/v1/mcp/config/autonomous-agent. Prefer auth_modes.oauth when the runner supports OAuth + custom headers; use auth_modes.xmemo_key with XMEMO_KEY from a secret store only for fully headless runners.

Run one synthetic task that writes progress to XMemo, restart the runner, and confirm it recalls that progress using the same XMEMO_AGENT_INSTANCE_ID.

If attribution changes or recalls split across instances, persist XMEMO_AGENT_INSTANCE_ID outside git and verify the runner is not regenerating it on every start.