Skip to main content
Org Memory extends Velixar’s personal memory system to teams and organizations. Instead of memories being siloed per-user, teams can share knowledge that persists across all members.

​
Architecture

┌─────────────────────────────────────────────┐
│                Organization                  │
│  ┌─────────────┐  ┌─────────────┐           │
│  │   Team A    │  │   Team B    │           │
│  │ ┌─────────┐ │  │ ┌─────────┐ │           │
│  │ │Workspace│ │  │ │Workspace│ │           │
│  │ └─────────┘ │  │ └─────────┘ │           │
│  └─────────────┘  └─────────────┘           │
└─────────────────────────────────────────────┘
Organizations contain teams, which contain workspaces. Each level has its own memory scope.

​
Scope Model

Memories flow upward through promotion:
ScopeCreated byVisible toPromotion
workspaceAny team member via commitTeam membersSubmit → manager approves
orgManager/admin promotesAll teams in orgFinal scope
A typical flow:
  1. Developer commits a memory to their team workspace (“Our auth tokens expire after 24h”)
  2. Team lead submits it for promotion
  3. Org admin approves — now all teams can search for it

​
Vector Storage

Each scope maps to a separate Qdrant collection:
  • team_{team_id} — workspace and team-scoped memories
  • org_{org_id} — promoted org-wide memories
When you search via /retrieve, all collections you have access to are queried in parallel. Results are merged, deduplicated, and ranked by cosine similarity. Embeddings use OpenAI text-embedding-3-small (1536 dimensions) and are generated automatically when memories are committed or promoted.

​
Database Schema

The org memory system uses 6 tables in Supabase:
TablePurpose
organizationsOrg metadata, owner, plan
teamsTeams within an org
org_workspacesWorkspaces within teams
membershipsUser ↔ org/team/workspace mapping + role
org_memoriesThe memories themselves (content, scope, tags, qdrant_point_id)
promotion_queuePending promotion requests
org_audit_logImmutable audit trail of all org memory operations
All tables have Row-Level Security (RLS) policies — users can only access data within their own organization.

​
Audit Trail

Every org memory operation is automatically logged:
  • memory.commit — logged by Postgres trigger on insert
  • memory.delete — logged by Postgres trigger on delete
  • promotion.approve / promotion.reject — logged by trigger on queue status change
  • member.invite / member.remove — logged by the dashboard
The audit log is visible to managers and admins in the Org Dashboard.

​
Usage Limits

Org memory counts toward your plan’s memory limits:
PlanOrg Memory Limit
Free100 total
Pro10,000
Power250,000
Team5,000 per seat
See billing plans for details.