Skip to main content
Mandala stores durable product state in Supabase Postgres. The schema is migration-owned, tenant-scoped, and designed so that a run can be reconstructed from the versions, evidence, decisions, and receipts that existed at the time.

​
Tenant model

companies are the workspace boundary. company_memberships and related event tables bind users to one of these roles:
  • owner
  • admin
  • approver
  • member
  • viewer
  • agent
Most Mandala records carry company_id. Row-Level Security and role-checked database functions enforce tenant isolation. Managed CLI credentials are additionally bound to an authorized user, company, and session. The original pages, collections, collection_fields, collection_rows, and collection_views tables remain for the web workspace, but agent workflows use the company-scoped control-plane model below.

​
Core domains

​
Identity and policy

​
Connectors and capabilities

​
Agents and lifecycle

​
Runs, review, and execution

Sensitive decision receipts, queue snapshots, parser leases, and compiled-persistence receipts live in the workflow_private schema rather than the public API surface.

​
Context, memory, and operations

Context indexing uses workspace settings, versioned policy, outbox, job, ledger, event, audit, operation-control, and tombstone tables. These separate the source record from the derived external index and support retry, cleanup, and reconciliation. Additional tables cover governed memory candidates, feedback, follow-ups, escalations, monitoring events, evaluations, promotion checkpoints, provider usage, email delivery, and account deletion.

​
Version and hash strategy

Mandala avoids mutable meaning by persisting:
  • skill source and compiler digests;
  • connector, capability, schema, policy, mapping, and lifecycle versions;
  • expected versions on decisions and executions;
  • context and evidence snapshots;
  • idempotency keys; and
  • request and response hashes on execution receipts.
A stale client or changed catalog receives a conflict instead of silently applying an old decision to new data.

​
Database boundaries

RLS is necessary but not the only boundary. Security-sensitive transitions use role-checked SQL functions, compare-and-set versions, or RPCs that return safe projections. Anonymous callers cannot read workflow detail through the underlying tables. Schema changes belong in supabase/migrations. After local migrations, regenerate the typed client:
Database authorization and behavior tests live in supabase/tests and run with: