Core Dependency Graph

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)

Platform Foundation is the only shared base layer
- All cores depend on PF
- PF depends on none of the cores
Cores may NOT depend on each other
- No direct imports between cores
- No shared database tables between cores
- Integration via explicit contracts only
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:

Identify PF Dependencies:
- Which PF features does it need?
- Are they complete?
Identify Integration Points:
- What events will it publish?
- What events will it consume?
- What APIs will it expose?
- What APIs will it consume?
Document Contracts:
- Add to /docs/architecture/INTEGRATION_CONTRACTS.md
- Update this dependency graph
- Update ROADMAP.md
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)

Architecture

Development

Database

Testing

Migration

Operations

Governance & Security

Platform Internals

Dependency Rules

Hard Rules (Constitution Section 1.2)

Dependency Graph

Core Dependencies Detail

Platform Foundation (PF)

Forms & Workflow (FW)

Workforce & HRIS (HR)

Recovery Housing & Operations (RH)

Finance & Revenue (FA)

Governance, Compliance & Learning (GR)

Facilities, Inventory & Vendors (FM)

Clinical & EHR (CL)

Integration Pattern Usage

Pattern 1: Platform Integration Layer

Pattern 2: Event-Based Integration

Pattern 3: API Contracts

Dependency Matrix

Critical Path Analysis

Longest Dependency Chain

Integration Contract Summary

Events Published

APIs Exposed

Platform Integration Layers

Architectural Principles

1. Core Isolation

2. Integration via Contracts

3. Downstream Clinical

Evolution Strategy

Adding New Cores

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	✅	❌	❌	❌	❌	❌	❌	-

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	✅	❌	❌	❌	❌	❌	❌	-

Architecture

Development

Database

Testing

Migration

Operations

Governance & Security

Platform Internals

Documentation Index

​Dependency Rules

​Hard Rules (Constitution Section 1.2)

​Dependency Graph

​Core Dependencies Detail

​Platform Foundation (PF)

​Forms & Workflow (FW)

​Workforce & HRIS (HR)

​Recovery Housing & Operations (RH)

​Finance & Revenue (FA)

​Governance, Compliance & Learning (GR)

​Facilities, Inventory & Vendors (FM)

​Clinical & EHR (CL)

​Integration Pattern Usage

​Pattern 1: Platform Integration Layer

​Pattern 2: Event-Based Integration

​Pattern 3: API Contracts

​Dependency Matrix

​Critical Path Analysis

​Longest Dependency Chain

​Integration Contract Summary

​Events Published

​APIs Exposed

​Platform Integration Layers

​Architectural Principles

​1. Core Isolation

​2. Integration via Contracts

​3. Downstream Clinical

​Evolution Strategy

​Adding New Cores

Dependency Rules

Hard Rules (Constitution Section 1.2)

Dependency Graph

Core Dependencies Detail

Platform Foundation (PF)

Forms & Workflow (FW)

Workforce & HRIS (HR)

Recovery Housing & Operations (RH)

Finance & Revenue (FA)

Governance, Compliance & Learning (GR)

Facilities, Inventory & Vendors (FM)

Clinical & EHR (CL)

Integration Pattern Usage

Pattern 1: Platform Integration Layer

Pattern 2: Event-Based Integration

Pattern 3: API Contracts

Dependency Matrix

Critical Path Analysis

Longest Dependency Chain

Integration Contract Summary

Events Published

APIs Exposed

Platform Integration Layers

Architectural Principles

1. Core Isolation

2. Integration via Contracts

3. Downstream Clinical

Evolution Strategy

Adding New Cores

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	✅	❌	❌	❌	❌	❌	❌	-