Organization Memory
Motif can keep short durable notes so later chats in the same organization can respect stated preferences and lab corrections. This page describes the implemented store (knowledge.organization_memory), HTTP APIs, chat injection budget, and the dashboard manage surface. It is not legal advice.
Product star ratings (InlineFeedbackRating / product feedback) are a separate store. They are not written into organization memory.
Manage in the product
Signed-in members manage visible rows at Dashboard → Settings → Memory : list preferences and lab corrections, edit content/category, delete one row, or clear all personal preferences.
On Enterprise, editing or deleting lab corrections (visibility=org) is limited to organization owners and admins. Members can still create corrections via chat (correct) and manage their own preferences.
What is stored
| Type | Visibility | Meaning |
|---|---|---|
preference | user (always) | Personal durable preference for that user in the organization (formatting, citation habits, ontology preference). |
correction | org (always) | Lab-shared scientific or operational correction intended for the whole organization. |
Each row holds short text content, optional category, optional embedding for retrieval, optional confidence, optional expiry, and supersession linkage. Writes go through the authenticated API (POST /api/v1/memory) or the chat tools remember / correct. Content is sanitized against common prompt-injection marker strings before storage and capped at max_org_memory_content_chars (default 2 000 characters). Retrieved memories are injected into the model context inside delimited untrusted-data markers.
Chat inject packs every active visible row the caller can see (own user preferences plus org org corrections), ordered for fill priority, until the configured memory token budget is full. The default budget is 24 000 tokens (max_org_memory_tokens). There is no separate top-N row truncate before packing (a high safety ceiling applies only as a query bound).
Motif does not silently mine whole chat turns into this store. Writes are tool- or API-mediated and attributable to the authenticated user.
Visibility
userrows are visible only to the owning user within the organization.orgrows are visible to members of that organization.- Rows with
superseded_byset, or withexpires_atin the past, are not retrieved for injection.
HTTP API (authenticated session)
| Endpoint | Effect |
|---|---|
GET /api/v1/memory | Lists rows visible to the caller (own user + org org), capped for display (default 100). Returns id, user_id, visibility, memory_type, category, content, created_at. |
POST /api/v1/memory | Creates a row. memory_type must be preference or correction (visibility is forced to user / org respectively). Response shape matches list items. |
PATCH /api/v1/memory/{memory_id} | Updates content and/or category with the same ownership rules as erase; re-embeds when content changes. With allow_org=true, also allows editing an org-visibility correction — on Enterprise, only owners and admins. |
DELETE /api/v1/memory/user | Deletes the caller’s visibility=user preference rows in the current organization. |
DELETE /api/v1/memory/{memory_id} | Deletes one user-visibility row owned by the caller. With allow_org=true, also allows deleting an org-visibility correction — on Enterprise, only owners and admins. |
Dashboard Settings proxies list/edit/delete through /api/memory (same cookie session forwarded to the agent). Create remains chat tools or direct agent POST.
Successful erase responses report delete counts or {deleted: true} without returning memory content. Server logs record memory id / org / delete counts for audit — not the memory text.
Retention
- There is no fixed calendar TTL on every row. A row may carry an optional
expires_at; once past, it is excluded from retrieval. - A newer memory may supersede an older one (
superseded_by); superseded rows remain in the table until deleted but are not injected. - Organization deletion / broader account-deletion effects follow the Privacy Policy §5 retention table for identity and organization lifecycle. This page only documents the memory-specific erase paths above.
Erasure (GDPR Art. 17–oriented paths)
Use the dashboard Memory page or the DELETE endpoints in the table above. Erasure of other categories of personal data (account identity, conversations, library files) remains under Privacy Policy §5–§6.
Separation from product feedback
Five-star message ratings feed Motif’s product feedback sink. They do not create, update, or delete organization memory rows.