> ## 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. # Core Dependency Graph > This document visualizes the dependency relationships between Platform Foundation and domain cores, showing integration points and architectural boundaries. **Version:** 1.0.0\ **Last Updated:** 2025-12-31\ **Constitution Reference:** Section 1.2 (Architecture & Module Boundaries) This document visualizes the dependency relationships between Platform Foundation and domain cores, showing integration points and architectural boundaries. *** ## Dependency Rules ### Hard Rules (Constitution Section 1.2) 1. **Platform Foundation is the only shared base layer** * All cores depend on PF * PF depends on none of the cores 2. **Cores may NOT depend on each other** * No direct imports between cores * No shared database tables between cores * Integration via explicit contracts only 3. **CL (Clinical) is architecturally downstream** * No core may depend on CL * CL built on top of operational/financial backbone *** ## Dependency Graph ``` ┌─────────────────────────────────────────────────────────────┐ │ Platform Foundation (PF) │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Auth │ │ Tenancy │ │ RBAC │ │ Audit │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Forms │ │ Notify │ │ Docs │ │ Reports │ │ │ │ Layer │ │ System │ │ Mgmt │ │ Engine │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ ▼ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ FW │ │ HR │ │ RH │ │ FA │ │ Forms │ │Workforce│ │Housing │ │Finance │ └────────┘ └────────┘ └────────┘ └────────┘ │ │ │ │ │ │ │ │ └──────────────┴──────────────┴──────────────┘ │ ▼ ┌────────┐ │ GR │ │Governance│ └────────┘ │ ▼ ┌────────┐ │ FM │ │Facilities│ └────────┘ │ ▼ ┌────────┐ │ CL │ │Clinical│ └────────┘ (Future) ``` *** ## Core Dependencies Detail ### Platform Foundation (PF) **Dependencies:** None (foundation layer) **Provides:** * Identity & Authentication (PF-01, PF-02) * Multi-tenancy (Organizations, Sites) * RBAC (Role-Based Access Control) * Audit Logging (PF-04) * Error Handling & Monitoring (PF-07) * Platform Integration Layers: * Forms Integration (PF-08) * Notifications System (PF-10) * Document Management (PF-11) * Reporting Engine (PF-12) **Status:** ✅ Complete (13/13 features) *** ### Forms & Workflow (FW) **Dependencies:** PF only * PF-01: Organizations & Sites * PF-02: RBAC * PF-04: Audit Logging * PF-08: Forms Integration Layer (provides integration for other cores) **Provides:** * Form Builder (FW-01) * Form Submissions (FW-02) * Automation Engine (FW-03) **Integration Points:** * **Exposes:** Forms via Platform Integration Layer (PF-08) * **Publishes Events:** `fw_form_submitted` (consumed by FW-03) **Status:** ✅ Complete (3/3 features) *** ### Workforce & HRIS (HR) **Dependencies:** PF only * PF-01: Organizations & Sites * PF-02: RBAC * PF-06: User Profiles * PF-10: Notifications (credential expiration alerts) **Provides:** * Employee Directory (HR-01) * Credentialing & Compliance (HR-02) * Onboarding/Offboarding (HR-03) - Planned * Scheduling & Capacity (HR-04) - Planned * Time & Attendance (HR-05) - Planned * PTO & Leave (HR-06) - Planned * Payroll Processing (HR-07) - Planned **Integration Points:** * **Publishes Events:** * `employee_created` → GR (policy assignments) * `employee_assigned_to_site` → RH (staff notifications) * **Exposes:** Employee lookup API (RLS-enforced) **Status:** 📝 Planning (2/7 specs written) *** ### Recovery Housing & Operations (RH) **Dependencies:** PF only * PF-01: Organizations & Sites * PF-02: RBAC * PF-08: Forms Integration (resident intake forms) * PF-10: Notifications (admission alerts) **Provides:** * Census & Beds (RH-01) - Planned * Programs & Phases (RH-02) - Planned * Safety Events (RH-03) - Planned * Program Participation (RH-04) - Planned * Discharge Planning (RH-05) - Planned * Incident Management (RH-06) - Planned * Compliance Tracking (RH-07) - Planned * Outcomes & Reporting (RH-08) - Planned **Integration Points:** * **Publishes Events:** * `resident_admitted` → FA (creates billing account) * `resident_discharged` → FA (finalizes billing) * `bed_assigned` → HR (staff assignment notifications) * **Consumes Events:** * `payment_received` ← FA (updates resident status) * **Consumes Data:** * HR: Employee lookup (staff assignments) * FA: Billing balance queries (via API) **Status:** 📝 Planning (0/8 specs) *** ### Finance & Revenue (FA) **Dependencies:** PF only * PF-01: Organizations & Sites * PF-02: RBAC * PF-04: Audit Logging (financial audit trail) * PF-12: Reporting Engine (financial reports) **Provides:** * Resident Subledger (FA-01) - Planned * Billing & Invoicing (FA-02) - Planned * Accounts Receivable (FA-03) - Planned * Payment Processing (FA-04) - Planned * General Ledger Integration (FA-05) - Planned * Financial Reporting (FA-06) - Planned **Integration Points:** * **Publishes Events:** * `payment_received` → RH (updates resident status) * `invoice_generated` → PF-10 (notifications) * **Consumes Events:** * `resident_admitted` ← RH (creates billing account) * `resident_discharged` ← RH (finalizes billing) * **Exposes APIs:** * `/api/v1/fa/resident-balance` (for RH queries) **Status:** 📝 Planning (0/6 specs) *** ### Governance, Compliance & Learning (GR) **Dependencies:** PF only * PF-01: Organizations & Sites * PF-02: RBAC * PF-08: Forms Integration (policy acknowledgments) * PF-11: Document Management (policy storage) **Provides:** * Policy Management (GR-01) - Planned * Training & CEU Tracking (GR-02) - Planned * Compliance Auditing (GR-03) - Planned * Learning Management (GR-04) - Planned **Integration Points:** * **Consumes Events:** * `employee_created` ← HR (assigns default policies) * **Consumes Data:** * HR: Employee records (policy assignments) **Status:** 📝 Planning (0/4 specs) *** ### Facilities, Inventory & Vendors (FM) **Dependencies:** PF only * PF-01: Organizations & Sites * PF-02: RBAC * HR: Employee lookup (technicians) **Provides:** * Work Order Management (FM-01) - Planned * Inventory Management (FM-02) - Planned * Vendor Management (FM-03) - Planned * Maintenance Scheduling (FM-04) - Planned **Integration Points:** * **Consumes Data:** * HR: Employee lookup (technician assignments) **Status:** 📝 Planning (0/4 specs) *** ### Clinical & EHR (CL) **Dependencies:** PF only * PF-01: Organizations & Sites * PF-02: RBAC * PF-04: Audit Logging * PF-08: Forms Integration (clinical assessments) * PF-11: Document Management (clinical documents) **Provides:** * Clinical Documentation (CL-01) - Future * Orders & Prescriptions (CL-02) - Future * Outcomes Tracking (CL-03) - Future * Clinical Reporting (CL-04) - Future **Integration Points:** * **No cores depend on CL** (architecturally downstream) * **Consumes Data:** * RH: Resident records (clinical context) * HR: Employee records (clinical staff) **Status:** 🚫 Future (2027+) *** ## Integration Pattern Usage ### Pattern 1: Platform Integration Layer **Used By:** * PF-08 Forms: All cores use forms via platform layer * PF-10 Notifications: All cores send notifications via platform layer * PF-11 Documents: All cores manage documents via platform layer **Example:** RH uses `@/platform/forms` to embed resident intake forms ### Pattern 2: Event-Based Integration **Used By:** * RH → FA: `resident_admitted` event creates billing account * FA → RH: `payment_received` event updates resident status * HR → GR: `employee_created` event assigns policies * HR → RH: `employee_assigned_to_site` event notifies staff **Example:** RH publishes event, FA subscribes asynchronously ### Pattern 3: API Contracts **Used By:** * FA → RH: Billing balance queries (synchronous) * HR → RH: Employee lookup (synchronous) **Example:** RH calls `/api/v1/fa/resident-balance` to get current balance *** ## Dependency Matrix | Core | Depends On PF | Depends On FW | Depends On HR | Depends On RH | Depends On FA | Depends On GR | Depends On FM | Depends On CL | | ------ | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | ------------- | | **PF** | - | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | **FW** | ✅ | - | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | | **HR** | ✅ | ❌ | - | ❌ | ❌ | ❌ | ❌ | ❌ | | **RH** | ✅ | ❌ | ❌ | - | ❌ | ❌ | ❌ | ❌ | | **FA** | ✅ | ❌ | ❌ | ❌ | - | ❌ | ❌ | ❌ | | **GR** | ✅ | ❌ | ❌ | ❌ | ❌ | - | ❌ | ❌ | | **FM** | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | - | ❌ | | **CL** | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | - | **Legend:** * ✅ = Allowed dependency * ❌ = Prohibited dependency * * \= Self (not applicable) *** ## Critical Path Analysis ### Longest Dependency Chain **Path 1: HR → GR (via events)** * HR-01 creates employee * Publishes `employee_created` event * GR-01 subscribes and assigns policies * **Length:** 2 steps (HR → GR) **Path 2: RH → FA → RH (circular via events)** * RH-01 admits resident * Publishes `resident_admitted` event * FA-01 creates billing account * FA-01 receives payment * Publishes `payment_received` event * RH-01 updates resident status * **Length:** 4 steps (RH → FA → FA → RH) **Note:** Circular dependencies via events are allowed (asynchronous, loose coupling) *** ## Integration Contract Summary ### Events Published | Event | Publisher | Subscribers | Status | | --------------------------- | --------- | ----------- | ------------- | | `fw_form_submitted` | FW | FW-03 | ✅ Implemented | | `resident_admitted` | RH | FA | 📝 Planned | | `resident_discharged` | RH | FA | 📝 Planned | | `payment_received` | FA | RH | 📝 Planned | | `employee_created` | HR | GR | 📝 Planned | | `employee_assigned_to_site` | HR | RH | 📝 Planned | ### APIs Exposed | API | Provider | Consumers | Status | | ------------------------------ | -------- | --------- | ---------- | | `/api/v1/fa/resident-balance` | FA | RH | 📝 Planned | | Employee Lookup (RLS-enforced) | HR | RH, FM | 📝 Planned | ### Platform Integration Layers | Layer | Provider | Consumers | Status | | --------------------------- | -------- | --------- | ---------- | | Forms Integration (PF-08) | PF | All cores | ✅ Complete | | Notifications (PF-10) | PF | All cores | ✅ Complete | | Document Management (PF-11) | PF | All cores | ✅ Complete | | Reporting Engine (PF-12) | PF | All cores | ✅ Complete | *** ## Architectural Principles ### 1. Core Isolation Each core owns its domain completely: * Own database tables (prefixed: `hr_*`, `rh_*`, `fa_*`) * Own business logic * Own UI components * No shared ownership ### 2. Integration via Contracts Cores interact only through: * Platform Integration Layer (Pattern 1) * Domain Events (Pattern 2) * API Contracts (Pattern 3) ### 3. Downstream Clinical CL (Clinical) is built last and depends on: * Stable operational backbone (RH) * Stable financial backbone (FA) * Stable workforce foundation (HR) No core depends on CL (prevents clinical complexity from contaminating operations) *** ## Evolution Strategy ### Adding New Cores When adding a new core: 1. **Identify PF Dependencies:** * Which PF features does it need? * Are they complete? 2. **Identify Integration Points:** * What events will it publish? * What events will it consume? * What APIs will it expose? * What APIs will it consume? 3. **Document Contracts:** * Add to `/docs/architecture/INTEGRATION_CONTRACTS.md` * Update this dependency graph * Update ROADMAP.md 4. **Verify No Core Dependencies:** * No imports from other cores * No shared tables * Only PF dependencies *** **Last Updated:** 2025-11-24\ **Next Review:** After HR-01 implementation (Q1 2026)