Skip to main content
Version: 1.0.0
Last Updated: 2026-01-15
Constitution Reference: Section 5 (Database Naming & Environment Guardrails)

Overview

This document defines standard column definitions, naming conventions, and data patterns used across the Encore OS platform. All database schema designs MUST follow these standards to ensure consistency, maintainability, and proper multi-tenant isolation. Related Documents:
  • constitution.md §5 - Database naming and guardrails
  • AGENTS.md - Database rules quick reference
  • specs/_templates/SPEC_TEMPLATE.md - Data Model section
  • specs/_templates/db-preflight.md - Database pre-flight checklist

Standard Column Definitions

Identity Columns

These columns are REQUIRED on all business entity tables: Usage Notes:
  • organization_id is ALWAYS required for multi-tenant isolation
  • site_id is required when data is site-specific (e.g., beds, rooms)
  • Both enable RLS policies for data isolation

Audit Columns

These columns track record lifecycle and are RECOMMENDED on all business entities: Update Trigger Pattern:

Extensibility Columns

When to Include custom_fields:
  • ✅ Business entity tables (employees, residents, invoices, forms)
  • ✅ Configuration tables that organizations might extend
  • ❌ Junction/mapping tables (e.g., hr_employee_skills)
  • ❌ Audit/log tables (e.g., pf_audit_logs)
  • ❌ Line item tables (use parent’s custom_fields)
  • ❌ System configuration tables
Required Comment Pattern:

Status Columns

Common patterns for tracking entity state: Prefer status TEXT over is_active BOOLEAN when entity has more than 2 states. Prefer deleted_at TIMESTAMPTZ over is_deleted BOOLEAN for soft deletes (enables audit trail).

Standard Enum Values

Common Status Values

Employment Status (HR)

Episode Status (RH)

Transaction Status (FA)


Column Naming Conventions

Standard Patterns

Foreign Key Naming

Index Naming


Reserved Column Names

These columns have platform-wide meaning and MUST NOT be repurposed:

Data Type Guidelines

Identifiers

Text Fields

Numeric Fields

Money Pattern:

Date/Time Fields

Always Use TIMESTAMPTZ (not TIMESTAMP) for timestamps to handle timezone correctly.

JSON Fields


Constraint Guidelines

CHECK Constraints

Use CHECK constraints for:
  • ✅ Enum-like values: CHECK (status IN ('active', 'inactive'))
  • ✅ Numeric ranges: CHECK (age >= 0 AND age <= 150)
  • ✅ String patterns: CHECK (email ~ '^[^@]+@[^@]+\.[^@]+$')
NEVER use CHECK constraints for:
  • ❌ Time-based logic: CHECK (expiry_date >= CURRENT_DATE) - Will fail as time passes!
  • ❌ Complex business rules - Use application-level validation
  • ❌ Cross-table relationships - Use foreign keys or application logic

Foreign Key Constraints

Unique Constraints


RLS Policy Patterns

Standard Policy Set

Every business table needs these RLS policies:
⚠️ CRITICAL: UPDATE policies MUST include WITH CHECK to prevent organization_id changes that could breach tenant isolation.

Security Definer Functions


Table Categories

Business Entity Tables

Primary data tables that represent core business objects. Requirements:
  • organization_id (required)
  • site_id (where applicable)
  • custom_fields JSONB (required)
  • ✅ All audit columns
  • ✅ RLS enabled with full policy set
Examples: hr_employees, rh_residents, fa_invoices, fw_forms

Junction/Mapping Tables

Tables that create many-to-many relationships. Requirements:
  • organization_id (required)
  • ✅ Composite primary key or unique constraint
  • custom_fields (not needed)
  • ✅ RLS enabled
Examples: hr_employee_skills, fw_form_assignments

Audit/Log Tables

Tables that record historical events for compliance. Requirements:
  • organization_id (required)
  • created_at (required)
  • updated_at, deleted_at (logs are immutable)
  • custom_fields (not needed)
  • ✅ Append-only (no UPDATE/DELETE policies)
Examples: pf_audit_logs, fa_journal_entry_lines

Configuration Tables

Tables that store module or organization settings. Requirements:
  • organization_id (required)
  • ✅ All audit columns
  • custom_fields (settings ARE the custom fields)
Examples: hr_module_settings, fa_module_settings

Versioning


See Also

  • constitution.md §5 - Database naming and guardrails
  • AGENTS.md - Database rules quick reference
  • specs/_templates/SPEC_TEMPLATE.md - Data Model section
  • specs/_templates/db-preflight.md - Database pre-flight checklist
  • specs/_templates/DATA_MODEL_TEMPLATE.md - Data model documentation template

Document Owner: Platform Foundation
Review Cadence: Quarterly
Next Review: 2026-04-15