The Platform Foundation provides the core infrastructure and shared services for the Encore Health OS platform.Documentation Index
Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt
Use this file to discover all available pages before exploring further.
π Table of Contents
- Architecture Overview
- Multi-Tenancy Model
- Authentication & Authorization
- Module Registry
- User Guides
Architecture Overview
Core Responsibilities
The Platform Foundation (PF) provides:-
Multi-Tenant Infrastructure
- Organization and site management
- Tenant isolation via RLS
- Cross-tenant security enforcement
-
Authentication & Authorization
- User authentication via Supabase Auth
- Role-Based Access Control (RBAC)
- Permission enforcement at data and UI levels
-
Shared Services
- Notifications (in-app, email, SMS)
- Document management
- Reporting engine
- Audit logging
- Form analytics
-
Developer Infrastructure
- Module registry for dynamic navigation
- Error handling and monitoring
- Testing utilities
- Shared UI components
Module Architecture
Multi-Tenancy Model
Organization Hierarchy
Tenant Isolation
Every business table includes:organization_id- Required, referencespf_organizationssite_id- Optional, referencespf_sites
Security Functions
has_org_access(user_id, org_id)
- SECURITY DEFINER function (bypasses RLS recursion)
- Checks if user has ANY role in the organization
- Used by all RLS policies for tenant isolation
has_role(user_id, required_role, org_id, site_id)
- Verifies user has required role level or higher
- Respects role hierarchy (platform_admin > org_admin > site_admin > manager > staff)
Authentication & Authorization
Authentication Flow
- User signs in via email/password or OAuth
- Supabase Auth creates session with JWT
- JWT contains
auth.uid()used by RLS policies - Userβs roles and permissions fetched from
pf_user_role_assignments(V2 permissions system)
Role Hierarchy
| Role | Access Level | Typical Permissions |
|---|---|---|
| platform_admin | All organizations | System configuration, user management |
| org_admin | Single organization | Org settings, user roles, module config |
| site_admin | Single site | Site operations, staff management |
| manager | Department/program | Workflow approvals, reports |
| staff | Daily operations | Data entry, form submissions |
Permission Checks
Backend (RLS):Module Registry
Dynamic Module Loading
Modules register themselves at app startup:Benefits
- β No hardcoded module lists
- β Role-based visibility
- β Lazy loading (performance)
- β Easy to add/remove modules
App Launcher
The App Launcher displays available modules based on:- Userβs role
- Moduleβs
requiredRole - Module enablement in org settings
User Guides
For End Users
- Notifications Guide - Managing notifications and preferences
- Document Management Guide - Uploading and organizing documents
- Reporting Guide - Creating and running reports
For Administrators
- Organization Setup - Configuring organizations and sites
- User Management - Adding users and assigning roles
- Module Configuration - Enabling/disabling modules per org
For Developers
- Testing Guide - Writing RLS security tests
- Integration Documentation - Cross-module communication
- Constitution - Architecture guardrails
Database Naming Conventions
All Platform Foundation tables follow these patterns:| Pattern | Example | Purpose |
|---|---|---|
pf_* | pf_organizations | Platform Foundation tables |
*_id | organization_id | Foreign key columns |
created_at, updated_at | Timestamps | Audit trail |
created_by, updated_by | User references | User tracking |
custom_fields | JSONB | Extensibility |
deleted_at | Nullable timestamp | Soft delete |
Key Technologies
- Backend: Supabase (PostgreSQL + Auth + Storage)
- Frontend: React + TypeScript + Tailwind CSS
- State Management: TanStack Query (React Query)
- Routing: React Router v6
- Forms: React Hook Form + Zod
- Testing: Vitest + Testing Library
Support & Resources
- Internal Documentation:
/docs/ - Specifications:
/specs/pf/ - Implementation Logs:
/specs/pf/IMPLEMENTATION_LOG.md - Test Coverage:
/tests/README.md
Security Best Practices
- Always use RLS policies - Never trust client-side checks alone
- Use SECURITY DEFINER functions - Avoid RLS recursion issues
- Validate all inputs - Use Zod schemas for API inputs
- Test multi-tenant isolation - Every table needs RLS tests
- Scrub PII/PHI from logs - No sensitive data in error messages
- Audit critical actions - All data changes logged in
pf_audit_logs
Version: 3.0.0
Last Updated: 2025-11-29