🌐 Multi-Group / Multi-Holon Schema Design Pattern
This pattern ensures your system can support many independent organizations, each with their own:
Governance proposals and votes All isolated and scoped by tenant.
🧱 Core Schema Additions
🔹 tenants table
Stores organization-level config and identity
sql
CopyEdit
CREATE TABLE tenants (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
name TEXT NOT NULL,
slug TEXT UNIQUE, -- for subdomain or route-based identification
branding JSONB, -- logo, colors, etc.
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
🔹 Extend all existing tables with tenant_id
For example, update holons:
sql
CopyEdit
ALTER TABLE holons ADD COLUMN tenant_id UUID REFERENCES tenants(id);
Do the same for:
Every query now scoped to tenant_id.
🧩 Holonic Hierarchy
To support nested holons (e.g., local → regional → global), you already have parent_id logic.
Add optional fields to make this more expressive:
sql
CopyEdit
ALTER TABLE holons ADD COLUMN type TEXT; -- team, node, org
ALTER TABLE holons ADD COLUMN path TEXT; -- e.g., "global/regional/local"
This allows for:
Filter by holon type within a tenant 🔐 User-Tenant Binding
If using Supabase Auth:
sql
CopyEdit
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
auth_uid UUID UNIQUE,
tenant_id UUID REFERENCES tenants(id),
role TEXT -- 'admin', 'viewer', 'member'
);
Now:
Each user is scoped to a tenant_id Role-based access defines visibility/edit rights You can enforce row-level security like:
sql
CopyEdit
-- Only allow users to access holons from their own tenant
CREATE POLICY "Tenant isolation"
ON holons
FOR SELECT USING (
tenant_id = (SELECT tenant_id FROM users WHERE auth_uid = auth.uid())
);
🧠 Benefits of This Pattern
Infinite scaling of holonic organizations Full support for white-labeling Centralized or decentralized deployment