Skip to main content
Status: ✅ Active (GR-01–GR-08, GR-10, GR-11 implemented; GR-09 pending; GR-12 specified; GR-25-EN-01/GR-28/GR-29/GR-30/GR-31 grant-reporting specs 📝 Planned)
Last Updated: 2026-05-28
Constitution Reference: §1 Architecture & Module Boundaries — no direct core-to-core imports; all cross-core via Platform Integration Layer, events, or API contracts.

​
Overview

The GR (Governance & Compliance) module manages policies, compliance tracking, audits, risk, quality improvement, accreditation, incident reporting, contracts, and procedures. This document is the canonical anchor for all GR integration contracts, cross-core event publisher/consumer mappings, API contracts, and platform layer usage. Related documents:

​
Events Published by GR

Notes:
  • All GR trigger functions that publish to gr_events MUST use SECURITY DEFINER.
  • gr_incident_created is also documented in CL-GR-CLINICAL-INCIDENT-INTEGRATION.md; follow PHI payload restrictions there.

​
Events Consumed by GR

Security requirements for all GR consumers:
  • Server-side tenant isolation: validate organization_id against JWT claims before writing.
  • Use SECURITY DEFINER stored procedures for event-triggered writes.
  • Log all event consumptions to pf_audit_logs with user_id, organization_id, timestamp, correlation_id.
  • Implement exponential backoff retries; dead-letter queue for max-retry failures.

​
SAMHSA Grant-Reporting Specs (GR-25-EN-01, GR-28, GR-29, GR-30, GR-31)

The 2026-05-27 care-quality/grant gap memo adds the GR grant-reporting consumer surface. Boundary: CL captures/computes, GR reports. GR never imports CL types — it subscribes to CL events via the Platform Integration Layer. Full pipeline detail (event taxonomy, external submission surfaces, Part 2 gating) lives in CL-PM-GR-CARE-QUALITY-GRANT-INTEGRATION.md. Notes:
  • All grant-reporting tables (gr_grant_programs, gr_spars_submissions, gr_ppr_reports, gr_teds_records, gr_urs_tables, gr_synar_inspections) are RLS tenant-isolated on organization_id.
  • SUD-derived rows are DS4P-aware (CL-63) end-to-end; any payer/grantor-facing export of SUD data routes through CL-11 cl_check_sud_consent() per receiving entity and logs to the CL-11 disclosure log.
  • GR-28/GR-31 consume CL-51-EN-01 measure values verbatim — no recomputation; package values must equal CL-51-EN-01’s published values exactly (zero drift).
  • All jurisdictional variation (state TEDS elements, grant profiles, set-aside floors) is materialized through PF-96.

​
API Contracts

No GR-owned API contracts are currently defined. The following are candidates for future specification:

​
Platform Layer Usage

PF-15/16/17 adoption is tracked in PF_ADOPTION_STATUS.md.

​
Cross-Core Data References

GR does not hold foreign keys to other cores (per constitution §1 / ADR-002 restrictions). Cross-core linkage is by UUID reference columns:

​
Implementation Notes for GR-09 (Pending)

The GR-09 Incident Reporting implementation must:
  1. Create gr_incidents table with RLS, org isolation, and full audit trail.
  2. Subscribe to cl_safety_plan_activated and cl_restraint_event_documented to auto-create draft incidents.
  3. Publish gr_incident_created and incident_created on incident creation.
  4. Subscribe to it_security_incident_created and it_critical_vulnerability_detected for IT-originated incidents.
  5. Implement statutory deadline tracking for ARS 46-454, ARS 13-3620, AHCCCS AMPM 1620-O.
  6. Create gr_incident_regulatory_reports sub-table for state/AHCCCS report tracking.
  7. Add RLS tests for all new tables in tests/rls/.
  8. Add E2E tests in tests/e2e/gr-incident-workflow.test.ts.
See GR-09-incident-reporting.md for full spec.
See CL-GR-CLINICAL-INCIDENT-INTEGRATION.md for bridge implementation requirements.

​
Testing Requirements