Data handling & retention
Where content lives, how long it stays, and what deletion does — and does not — promise.
Where content lives
| Content | Store | Notes |
|---|---|---|
| Messages, journals, membership | PostgreSQL | The durable record |
| Search index and embeddings | PostgreSQL | A projection, rebuildable |
| Document metadata, chunks | PostgreSQL | |
| Uploaded file bytes | Object store | Brokered through authenticated routes |
| Exports and artifacts | Object store | |
| Sandbox workspace snapshots | Object store | Per actor + conversation |
| Presence, leases, opaque platform run references | Valkey | Ephemeral, no persistence |
| Audit records | PostgreSQL | Append-only |
| External API source pointers and replay receipts | PostgreSQL | Metadata only; no schemas, arguments, results, or credentials |
| External OpenAPI documents | Process memory | Bounded shared metadata cache; never a durable Kaizen record |
| Use-once credential values | Browser and broker memory | Cleared after submission; NPE TLS files use temporary /dev/shm only |
| Explicitly remembered credential bundle | Kamiwaza DataHub/Catalog | Encrypted platform secret; Kaizen returns an opaque URN and has no read method |
Nothing about your identity is stored by Kaizen as a credential. The platform authenticates; Kaizen maps that to permissions per request.
Private by default
Your documents are private to you. They are indexed separately from the shared corpus and never exposed to other members through it.
Your sandbox workspace is private to you and to one conversation. Files, installed packages, environment values, processes, and output do not cross to collaborators.
Documents attached to a private chat, or explicitly requested from an authorized retrieval result for the current turn, may be mounted read-only for code execution. They are pinned by digest, bounded by count and aggregate bytes, and kept outside the saved workspace. The run audit records bounded identity and version metadata, never document contents or object-store keys.
Your Library — prompts, collections, artifacts, agents — is private until you share it deliberately.
Your preferences and compression statistics are member-owned and never visible to another member.
General assistant keeps its profile on the conversation rather than in a client-only label. A General turn uses only the text and retained history of that room. It may use a specifically approved public-web search operation. The server refuses document and artifact attachment, private tool selection, delegation, and task execution there; it removes saved instructions and private context before the model run. Retrying room creation cannot change an existing General room into another profile. Other assistant profiles use ordinary per-member and per-workroom permissions; a profile never grants data access by itself. If an administrator approves an operation while another assistant's turn is active, the server rechecks that operation before its next tool call and withholds it from that assistant.
Administrators can view bounded, content-free operational usage by member in the AI metrics Usage tab. That view can identify a member by display name and reports only active days, conversation and input counts, completion ratio, and model-call and token totals. It does not expose activity timestamps, prompt or answer content, conversation ids, source activity, tool arguments, raw platform subjects, or email addresses. Every view is separately role-gated and audited without copying the member rows into the audit record.
What sharing actually shares
| Action | Shares | Does not share |
|---|---|---|
| Share a chat | Retained messages, visible Thinking, artifacts, citations, linked resources, per-response agent/model/effort | Hidden model reasoning, your sandbox, files, packages, environment, credentials, unrelated Library items |
| Share a collection | The collection, re-checked against each recipient's own permissions | Anything the recipient could not already see |
| Link to a Project | A pointer; a document can also carry an explicit read-only Project grant | Ownership, global visibility, mutation rights, or unrelated items |
| Publish an artifact | A members-only link that still re-checks access | Your workspace |
Retention
Retention windows are a deployment policy, not a product constant. Ask your administrator for the specific windows in force.
What is structurally true regardless of the window:
- The journal is the retained record. It is append-only and is never edited to reflect a later access change.
- Deletion changes reachability, not history. Deleting a chat, unlinking a Project, or removing a participant ends future access. It does not rewrite what already happened.
- Content already seen cannot be clawed back. Removing a collaborator stops future access; it does not un-read what they read.
- Evidence outlives the live object. Occurrence, run, trace, notification, and audit history are retained under their own independent policies after a task is deleted.
- Notification retention is separate from task deletion. Mark-read is not deletion.
- Projections are disposable. Search passages and Project indexes are updated or tombstoned through a durable outbox and can be rebuilt. They never become access capabilities.
- Capability receipts are value-free evidence. They retain nonce, operation identity, schema digest, effect, and status so an uncertain write is not replayed. They never retain request arguments, bodies, credentials, or endpoint results.
What deletion does
| You delete | Immediate effect | Retained |
|---|---|---|
| A document | Removed from your library; retrieval stops | Derived records per policy |
| A chat | Access ends where policy permits deletion | Journal and audit per policy |
| A Project | Pointers removed; every chat survives with its original id | Audit of the deletion |
| A task | Future scheduling stops | Occurrence, run, trace, notification, audit |
| An artifact | Removed from your library | Immutable versions already promoted into a shared room follow room policy |
| An external capability source | Tool discovery stops for that pointer | Non-secret invocation receipts and audit evidence; remote data and separately remembered DataHub secrets are unaffected |
Deletion does not promise immediate evidence erasure. Where a deployment needs guaranteed erasure, that is a separate, reviewed operation applied in bounded batches with removed counts recorded — not a side effect of a member clicking delete.
Data minimisation in records
Two records are held to a strict denylist:
The audit trail never carries chat text, queries, answers, raw tool payloads, credentials, hidden reasoning, source snippets, ACL membership, or presence.
Task run traces never carry system or developer instructions, hidden
reasoning, credentials, auth headers, tokens, cookies, raw prompts or
completions, raw provider errors, unrestricted tool arguments or results, or
another member's inaccessible content. Source detail is re-authorized at read
time and can return redacted or payload_unavailable.
Delegated workload records contain only opaque platform identifiers and bounded evidence: grant, run, claim, effect, protected-resource revision, credential binding, correlation, revision digest, authority deadline, and fencing-token digest. They never contain material that can exercise those records.
What Kaizen does not retain at all
- Presence history. Heartbeats, tab counts, device details, IP addresses, typing text, and last-seen history are not monitoring data Kaizen keeps.
- Draft text. A typing indicator does not retain what was being typed.
- Machine-global compression history. Statistics are member-scoped and never imported from host state that could mix in other members' commands.
- Model credentials in member-reachable records. Task rows, queue payloads, logs, audit payloads, and member responses never carry them.
- Delegated authority material. Projected workload assertions, DPoP private keys and proofs, sender-constrained run/effect capabilities, one-use consumption tokens, credential-use leases, and broker handles are redacted, non-pickleable values held only in the trusted process that uses them. They cannot enter a queue, database field, cache value, log, trace, exception, or member response.
- Provider credentials. A registered credential broker resolves an opaque binding only for the reserved operation and destination. Raw secret values do not return to Kaizen, the worker, a package, the model loop, or Core's durable records.
- Use-once external credentials. They are never written to PostgreSQL, Valkey, object storage, DataHub, transcripts, tool arguments, or results. A failed submission must be entered again.
- Credential-shaped dynamic tool arguments. Core and external OpenAPI
operations that accept plaintext tokens, passwords, private keys, or
unstructured provider, connector, connection, authentication, or credential
containers are omitted before tool search. A generic non-secret
configobject may carry type-defined settings, but credential-shaped nested keys and credential-bearing URLs are rejected before dispatch. An invalid endpoint is quarantined without weakening or disabling unrelated operations.
Visible Thinking is different from hidden model reasoning. Kaizen retains a bounded member-visible Thinking trace with its completed assistant answer so it can be reloaded and shared under the room ACL. Internal reasoning that was not emitted for members remains prohibited from the conversation journal.
Backups
PostgreSQL and the object store are the two stores that must be backed up. Valkey is ephemeral by design, and the search index is a rebuildable projection. See Backup & disaster recovery.
Backups inherit the sensitivity of what they contain. Treat a PostgreSQL backup as equivalent to the live journal.