- Shipped
- 2 Agosti 2026, 18:48 UTC
- Author
- Kamo
- Commit
- 6211c93
The keystone of the HIPAA compliance boundary: a per-organization flag plus a guard deciding which modules that organization may reach. Everything downstream keys off it — which integrations are disabled, whether MFA is forced, which sessions get the stricter timeout, what the audit spine has to cover. Organization gains HANDLES_PHI (BOOL DEFAULT FALSE) and PHI_EFFECTIVE_DATE, following the existing **************** pattern. Defaults false, so this is inert for the existing mortgage and CRM book. Three properties the design is built around: - Fails closed. PhiModule's constructor requires a PhiDisposition and a reason, so a module added later cannot inherit permission by omission — it will not compile without a decision, and anything other than PERMITTED denies. That is the specific failure mode a compliance boundary has to survive: a module ships, nobody thinks about PHI, a clinic starts using it. - Not bypassable. The decision is a pure function of (organization, module) with no caller, session, right or god-mode parameter, so there is nothing to elevate. "Our support staff can turn it off" is the answer that fails a covered entity's review. - Denials carry a reason, because a bare "denied" is not usable by a support engineer or a customer. Dispositions follow the scoping analysis in kamo-internal **************** Permitted today: CRM, contacts, document vault, self-hosted email, e-sign, notes, tasks, calendar, internal chat, the in-cluster transcription/translation stack, and MLOS. Blocked with no obtainable BAA: social messaging, Canva, e-commerce sync, MCP gateway. Blocked pending named work: the AI router, RAG search, meeting recordings, VOIP recordings, marketing campaigns, analytics export. Schema note: HANDLES_PHI and PHI_EFFECTIVE_DATE materialize on the next KamoInitializer run, after CI publishes this shared-library build. Nothing reads the flag yet, so the ordering is safe.