Vrida Schema — Index

This document is the authoritative conceptual schema definition for Vrida: tables, columns, types, constraints, indexes, and foreign keys for every module schema.

It is populated incrementally — as each module's tables are designed, their definitions land here. Schemas marked "Tables pending design" carry only the placeholder for now.

When schema.prisma is later authored as the implementation artifact, this document becomes the conceptual layer (the design source) and the Prisma file becomes the execution source of truth. The Prisma file will be generated / hand-aligned with this document; CI checks may later be added to enforce alignment.

Cross-references — read these first

• docs/SCHEMA_CONVENTIONS.md — Naming (snake_case singular), required columns (id, tenant_id, created_at, updated_at, deleted_at, site_id), RLS pattern, soft-delete pattern, partial unique indexes for soft-deleted tables, currency storage (ISO + cents), timestamp UTC rule, indexes (always on tenant_id + FKs), cross-schema FK policy, migration file naming, snapshot storage. All tables in this document follow those conventions.
• docs/PROJECT_DECISIONS.md → "Database Infrastructure Decisions (Locked 2026-06-09)" — Connection strategy (direct 5432 / pooled 6543), Prisma multiSchema setup, NestJS TenantGuard + TenantInterceptor middleware, site-as-step-2 provisioning order, search_path = public rule, Prisma Migrate + raw SQL migration strategy, 10-phase migration dependency order.
• docs/PROJECT_DECISIONS.md → "Platform Module (Locked 2026-06-09)" — Source of truth for the Platform schema's 16 tables, listed below with their one-line descriptions.
• docs/ARCHITECTURE.md — Layered schema organization (Platform & Service Layers + nursery-facing modules); multi-site site_id rule; offline-first POS carve-out; signature infrastructure; audit hash-chain.
• docs/CROSS_MODULE_CONTRACTS.md — Service-class API rule (modules don't query other modules' tables directly), event isolation, MV invalidation strategy.
• docs/MODULE_INDEX.md — Module → schema mapping and dependency graph.

Sections (in migration dependency order)

Schemas appear below in the build order from PROJECT_DECISIONS "Database Infrastructure Decisions" → §6 Migration Strategy:

1. Phase 1 — Root: platform
2. Phase 2 — Reference data: shared
3. Phase 3 — Users / roles: identity
4. Phase 4 — Sites (needed for site_id): multi_loc
5. Phase 5 — Service layers: payments, integrations, ai
6. Phase 6 — Tenant config: admin
7. Phase 7 — Master data: crm, inventory
8. Phase 8 — Transactional: pos, orders, purchasing, billing
9. Phase 9 — Vertical: customer_app, production
10. Phase 10 — Cross-cutting: reporting, audit, notifications

---

---

Files in this folder

Module	Phase	Tables
platform	Phase 1	16
shared	Phase 2	7
identity	Phase 3	11
multi_loc	Phase 4	1
payments	Phase 5	8
integrations	Phase 5	9
files	Phase 5	3
ai	Phase 5	4
search	Phase 5	0
admin	Phase 6	11
crm	Phase 7	8
inventory	Phase 7	0
pricing	Phase 7	4
pos	Phase 8	19
orders	Phase 8	7
purchasing	Phase 8	16
billing	Phase 8	8
customer_app	Phase 9	0
production	Phase 9	0
reporting	Phase 10	3
audit	Phase 10	7
notifications	Phase 10	11
consumer	Consumer Layer (post-v1.0)	4
rewards	Consumer Layer	6
offers	Consumer Layer	4

Source: split from SCHEMA.md (Sprig-era reference). Not confirmed v2 design.