Inherited Compliance Posture
JIL runs as Snowpark Container Services inside your Snowflake account. Your existing certifications cover the JIL detection engine at signing. No new audit boundary, no new vendor compliance review.
The structural claim
Every JIL pillar and vertical (except pre-clearance) deploys as a Snowflake-native container that reads your data, applies our detection logic, and writes findings back to your Snowflake schemas. Your data never leaves your Snowflake account. JIL's compute runs on Snowflake's certified infrastructure under your existing access controls.
This is not a marketing posture. It is the deployment architecture. If your Snowflake account holds your HITRUST or FedRAMP authorization, the same boundary covers the JIL container that we operate inside that account.
Certifications inherited at signing
| Certification | Snowflake holds | JIL inherits when you deploy |
|---|---|---|
| HITRUST r2 | Yes | Yes -- runtime inside your account |
| SOC 2 Type 2 | Yes | Yes -- runtime inside your account |
| HIPAA + BAA | Yes | Yes -- your BAA scope extends to the JIL container |
| FedRAMP Moderate | Yes (Snowflake GovCloud) | Yes for FedRAMP-tenant deployments |
| PCI DSS | Yes | Yes |
| ISO 27001 | Yes | Yes |
| HITRUST i1 | Yes | Yes |
What JIL owns under its own audit
JIL is responsible for the application-layer correctness of the detection logic itself: deterministic rule execution, statute-element coverage mapping, scienter scoring, damages computation, and the CourtChain anchoring of findings. These are JIL-owned and tested under our own quality regime.
- Application correctness -- rule execution + statute mapping + scienter scoring + damages methodology. Versioned and signed.
- FRE 902(13)/(14) authentication -- self-authenticating evidence certificates on every Court-Ready Evidence Bundle (CREB).
- CourtChain anchoring -- L1 cryptographic commitments on every classification, hashes only, no PHI.
- Hybrid post-quantum cryptography -- Ed25519 + Dilithium-III signing per CANONICAL_LOCK ยง06.
What crosses your account boundary
Nothing. The JIL container executes inside your Snowflake account. The only artifacts that leave your environment are cryptographic anchor hashes posted to the JIL L1 ledger -- no PHI, no PII, no claim payloads.
| Artifact | Leaves your Snowflake? |
|---|---|
| Claims data, member records, provider data | No |
| Detection findings + dossiers | No -- written to your Snowflake schemas |
| Court-Ready Evidence Bundles | No -- generated in your account, exported to your counsel |
| CourtChain anchor hashes (SHA-256 commitments, no payload) | Yes -- posted to JIL L1 for tamper-evident audit |
| Runtime telemetry (container health, execution counts) | Yes -- metrics only, no record-level data |
When inheritance does not apply: Path C (JIL Cloud)
Customers without a Snowflake account can deploy JIL via JIL Cloud, a multi-tenant Snowflake account JIL operates. In that model JIL is the principal certified party. JIL Cloud is on track for SOC 2 Type 2 Q4 2027; HITRUST i1 is mapped today. Per-customer segregation is enforced via row-access policies and per-tenant cryptographic keys.
Path C is the deployment we recommend for state SIU customers who do not run their own warehouse. Settlement and utilization-management workloads remain on Path A (customer Snowflake) regardless.
The one-line summary for your security review
JIL runs inside your Snowflake account. Your certifications cover us. We hold the cryptographic anchors; you hold the data.