Most of JIL Sovereign does not touch PHI.
By architecture, not by promise. Pre-Settlement Attestation, Retroactive Tier 1 with Ava, Wallet Intelligence, and Asset Intelligence operate on hashed identifiers, public datasets, and non-health PII. JIL never sees a member name on these paths. PHI enters the workflow only when an authorized buyer explicitly escalates a flagged case to Tier 2 or Tier 3, and even then it runs in an isolated PHI enclave with a separate access boundary. This document describes the architecture, the two-track BAA structure that fits it, and the sections 164.308 through 164.316 controls that apply when PHI is in scope.
JIL was architected to invert the all-or-nothing BAA. PHI does not enter the workflow until a buyer authorizes a specific case to escalate.Doc JIL-HIPAA-2026.05 - Effective 02 May 2026
Five products. One data architecture. PHI in only two places.
The honest way to read JIL's HIPAA posture is product-by-product. Each row in the table below shows what data the product receives, what HIPAA pathway it operates under, and which BAA scope is required to engage. The rows marked No PHI do not handle PHI by architecture. The rows marked Full BAA handle PHI explicitly, on buyer-authorized cases.
| Product | Non-PHI PII | PHI / ePHI | HIPAA pathway | BAA scope |
|---|---|---|---|---|
| Pre-Settlement Attestation /pillars/pre-settlement |
Yes - counterparty, beneficiary, bank fingerprint | None | Not applicable. Operates outside Part 164 scope when no PHI is exchanged. | Limited (defensive) |
| Retroactive Tier 1 (Ava) /adaptive-validation-engine |
Hashed - claim IDs, NPIs, TINs, amounts, dates, bank fingerprint | None | Limited Dataset under section 164.514(e), or Safe Harbor de-identification under section 164.514(b)(2). Buyer holds the re-identification key. | Limited |
| Retroactive Tier 2 (case investigation) /adaptive-validation-engine#tier-2 |
Yes | Case-level PHI | Active PHI handling under the Privacy and Security Rules. Engaged only on buyer-authorized case escalation. | Full |
| Retroactive Tier 3 (CREB hand-engaged) /pillars/retroactive-verification |
Yes | Full case file | Active PHI handling, court-ready chain of custody under FRE 902(14). Sealed CREB output. | Full |
| Asset Intelligence /pillars/asset-intelligence |
Yes - financial PII, public records, court records | None typically | Not applicable in normal operation. PHI may be incidentally present in court records; treated under the Full BAA when so. | Optional |
| Wallet Intelligence /pillars/wallet-intelligence |
Limited | None | Not applicable. On-chain analysis; no health data exchanged. | Not required |
How Pre-Settlement, Retroactive Tier 1, and Wallet Intelligence run without PHI.
The Tier 1 path is engineered around the HIPAA Minimum Necessary standard at section 164.502(b), the Limited Dataset definition at section 164.514(e), and the Safe Harbor de-identification standard at section 164.514(b)(2). Buyers ship JIL the hashed identifiers and analytic features required for the check, not the eighteen direct identifiers under section 164.514(b)(2)(i). JIL holds no re-identification key. A breach on the JIL side cannot expose your members.
De-identified by design.
The buyer's data engineering team runs the hash and tokenization on the buyer side. JIL receives only the hashed claim IDs, hashed member identifiers, provider NPIs and TINs (which are public reference data), claim amounts, service dates, and bank fingerprints. JIL never receives names, addresses, MRNs, full DOBs, or any of the eighteen Safe Harbor identifiers.
- 1. Buyer hashes and ships analytic-feature-only payload
- 2. JIL Ava processes - no PHI in prompt context
- 3. Ava returns hashed-ID verdict and risk score
- 4. Buyer re-identifies on its side, acts on flagged cases
- JIL holds no re-identification key. Architecturally cannot decrypt member identity.
- Ava inference logs, embedding stores, and prompt context contain no PHI.
- 17-minute audit of 49.87M Medicare records ran entirely on this path.
- A JIL-side breach cannot expose member identity. The blast radius is bounded to your hashed identifiers, which are useless without your salt.
PHI on case escalation only.
When Tier 1 returns flagged cases and the buyer authorizes investigation, the case file (which may include PHI) is transmitted to JIL's isolated PHI enclave. The enclave is a separate runtime environment with its own access controls, its own audit log, its own retention policy, and a CoreWeave-side boundary that does not co-mingle with Tier 1 inference paths.
- 1. Buyer authorizes Tier 2/3 on a specific flagged case
- 2. Case file routes to isolated PHI enclave
- 3. Investigation runs - audit-logged at field level
- 4. Sealed CREB evidence delivered to buyer's counsel, SIU, FWA
- Tier 2/3 PHI is never co-mingled with Tier 1 infrastructure.
- Separate access provisioning per case. Default-deny.
- Field-level audit log under section 164.312(b) for every PHI access.
- 15-plus year sealed retention for the resulting CREB record.
The contractual instrument matches the architecture.
Most BAA templates were drafted for the all-or-nothing case: PHI is either flowing or it isn't, and the BAA covers the everything-on path. JIL's architecture supports a cleaner pattern. The Limited BAA covers the operational baseline for Pre-Settlement and Retroactive Tier 1, where no PHI is in scope. The Full BAA covers Tier 2 and Tier 3, where PHI handling is explicit. Procurement can execute the Limited BAA in days, get to a live Tier 1 scan, and stage the Full BAA for case escalation.
| Attribute | Limited BAA - Tier 1 scope | Full BAA - Tier 2 / Tier 3 scope |
|---|---|---|
| Timing | Executes in days. Counsel review is narrow. | Stages on Tier 1 sign. Activates on first case escalation. |
| Covers | Pre-Settlement, Retroactive Tier 1 (Ava), Wallet Intelligence | Retroactive Tier 2, Tier 3 CREB, Asset Intelligence when PHI present |
| PHI in scope | None in normal operation | Yes, on per-case authorized basis |
| Data path | Limited Dataset under section 164.514(e); Safe Harbor de-identification under section 164.514(b)(2) | Active PHI handling under sections 164.308 through 164.316. Field-level audit log. |
| Re-id key / Enclave | Re-id key held exclusively on buyer side. JIL has no key access. | Isolated runtime; separate access controls, separate audit, separate retention |
| Breach scope / notification | Hashed identifiers only. No direct identifier exposure on JIL side. | 4-hour internal triage; section 164.410 60-day ceiling; section 164.410(c) elements |
| Audit rights | Annual self-assessment; SOC 2 Type II evidence on request under NDA | Annual on-site; quarterly evidence package; right of inspection |
| Subprocessors | Disclosed; flow-down BAA enforced where any PII is touched | Full subprocessor BAA register provided; written notice on material change |
| Sign-off | Director, Compliance Lead, or VP signoff threshold | Chief Privacy Officer, Chief Compliance Officer, or General Counsel |
Where the AI runs. And what it sees.
JIL's agentic AI workloads (Ava and adjacent inference paths) run on CoreWeave Cloud. CoreWeave maintains SOC 2 Type II and ISO 27001 alignment at the infrastructure layer, operates a published Shared Responsibility Model, signs a HIPAA Business Associate Agreement on request, and has a publicly disclosed HITRUST CSF program in flight. The allocation below is precise about what data each tier sends to CoreWeave and what does not leave JIL's PHI enclave.
Ava on CoreWeave is a no-PHI path. Tier 2/3 PHI runs in JIL's enclave.
Both parties' obligations are reflected in the executed BAA chain. CoreWeave is accountable for the underlying physical, network, and platform safeguards. JIL Sovereign retains accountability for application-layer Administrative, workforce-Physical, and Technical safeguards under sections 164.308 to 164.316.
| Tier / Workload | What runs on CoreWeave | What is in the prompt / inference context | PHI? |
|---|---|---|---|
| Tier 1 - Ava analysis | Agentic reasoning over Tier 1 verdict outputs and signal traces. Pattern detection, anomaly clustering, narrative generation. | Hashed identifiers only. Analytic features. No member names, addresses, MRNs, or DOBs. | NO PHI |
| Pre-Settlement | 148-check verdict engine. Counterparty and beneficiary attestation. | Counterparty identifiers, bank fingerprints, transaction metadata. Non-health PII only. | NO PHI |
| Wallet Intelligence | 42-signal on-chain analysis. UBO graph, contamination scoring. | Wallet addresses, transaction graphs, public registry data. | NO PHI |
| Tier 2 / Tier 3 | Investigation occurs in JIL's isolated PHI enclave. Where AI assistance is required, requests route through a controlled gateway with PHI redaction or tokenization before any external inference call. | By policy, no raw PHI is sent to CoreWeave inference endpoints. Pre-redaction or tokenization occurs at the enclave boundary. | NO RAW PHI |
The security baseline. Whether or not PHI is in scope.
The controls below operate continuously across all JIL infrastructure, regardless of which tier or product is active. They constitute the security hygiene that meets HIPAA expectations whether or not a given workflow is touching ePHI. They also map cleanly to SOC 2 Type II Trust Services Criteria and the NIST CSF 2.0 self-assessment.
| Standard | Citation | JIL control and evidence | Status |
|---|---|---|---|
| Access Control | section 164.312(a)(1) | Unique user ID via JIL IAM (SCIM, OIDC, SAML federation). MFA-gated. Least privilege. Quarterly access reviews. Break-glass procedure for emergency access. | Operational |
| Audit Controls | section 164.312(b) | Hash-chained immutable audit trail. Every compliance decision, identity check, and settlement event is signed and stored with cryptographic integrity. No retroactive modification. | Operational |
| Integrity | section 164.312(c)(1) | SHA-256 sealed records. Ed25519 plus Dilithium-III hybrid signatures. ML-DSA-65 and Kyber KEM for forward-quantum resistance. Verifiable on the record's face under FRE 902(14). | Operational |
| Transmission Security | section 164.312(e)(1) | TLS 1.3 in transit. mTLS plus HMAC for API integrations. AES-256-GCM at rest. MPC 2-of-3 threshold signing; JIL never holds single-party signing capability. | Operational |
| Assigned Security Responsibility | section 164.308(a)(2) | Designated Security Officer and Privacy Officer; reporting line into the CIO. | Operational |
| Workforce Security | section 164.308(a)(3) | Authorization, clearance, and termination procedures in onboarding/offboarding runbooks. Background checks for personnel with any access to non-public data. | Operational |
| Risk Management Process | section 164.308(a)(1) | Annual risk analysis under section 164.308(a)(1)(ii)(A); current self-assessment maps to NIST CSF 2.0 with quarterly delta reviews. Risk management plan and sanction policy maintained by the Security Officer. | Operational |
| Contingency Plan | section 164.308(a)(7) | Multi-jurisdiction validator fabric (20 active plus 20 standby across 13+ jurisdictions) survives 6 simultaneous validator failures with zero operational impact. Backup and DR plans documented. Annual test scheduled. | Test Q3 2026 |
| Workstation and Device | section 164.310(b)-(d) | Full-disk AES-256 encryption, MDM, MFA, no local persistence of any production data. Cloud-native; no removable media in production path. | Operational |
Additional controls that activate when a PHI case is authorized.
The controls below are gated to PHI engagement. They activate at the moment a buyer authorizes a Tier 2 or Tier 3 case escalation and remain active for the duration of the case plus the BAA-defined retention period. They sit on top of the standing safeguards in Section 05, not in place of them.
| Control | Citation | JIL control and evidence | Status |
|---|---|---|---|
| PHI enclave isolation | section 164.308(a)(4), section 164.312(a) | Tier 2/3 PHI runs in a network-isolated environment with separate VPC, separate IAM scope, separate observability stack. No production overlap with Tier 1 paths. | Operational |
| Per-case access provisioning | section 164.308(a)(4)(ii)(B) | Default-deny. Case-specific access grants. Just-in-time elevation for investigators with an approved engagement scope. Access auto-expires on case closure. | Operational |
| Field-level PHI audit log | section 164.312(b) | Every PHI field access generates a structured audit event: who, what, when, why, case ID, signed and hash-chained. Exportable to the buyer on request. | Operational |
| Minimum Necessary enforcement | section 164.502(b) | The case file ingest pipeline applies tokenization or redaction to fields outside the case scope before storage. The BAA defines the field-level scope per case type. | Operational |
| Security awareness and training | section 164.308(a)(5) | Annual HIPAA workforce training; quarterly phishing simulations; targeted Privacy Rule training for personnel with PHI enclave access. Training register maintained by the Security Officer. | Roadmap Q3 2026 |
| Security incident procedures | section 164.308(a)(6) | 4-hour internal triage SLA. Documented incident response plan. Continuous SentinelAI fleet inspection with hash-chained immutable audit trail. | Operational |
| Breach notification | sections 164.400 to 164.414 | Four-factor risk assessment per section 164.402(2). Notification to affected Covered Entity or upstream BA without unreasonable delay and no later than 60 calendar days, per section 164.410(b). Includes the elements required by section 164.410(c). | Operational |
| PHI enclave subprocessor binding | section 164.502(e)(1)(ii), section 164.314(a) | Any subprocessor with access to the PHI enclave is bound by an executed BAA before access is provisioned. Register maintained by the Security Officer; available under NDA. | Operational |
| Retention and disposition | section 164.316(b)(2)(i) | Case PHI is retained per the BAA-defined schedule. Sealed CREB evidence artifacts retained 15+ years. Cryptographic erasure on key destruction is the primary disposal method (NIST SP 800-88 Rev. 1). | Operational |
| Annual evaluation | section 164.308(a)(8) | Periodic technical and non-technical evaluations. Current evidence base includes 512M+ certified test cases across SOC 2, NIST CSF 2.0, OWASP, FIPS 140-3, and adjacent frameworks. SOC 2 Type II audit currently engaged. | SOC 2 Q3 2026 |
What JIL does not ingest, even on Tier 2/3.
The Full BAA scope for Tier 2 and Tier 3 cases is bounded by the case-type field schedule. JIL does not need (and does not request) the data classes below for any product, on any tier. Where these classes appear incidentally in a case file, the ingest pipeline applies tokenization or redaction before storage.
Out-of-scope data classes.
- Clinical notes, full medical records, imaging, lab results.
- Genetic information under section 164.501 and the Genetic Information Nondiscrimination Act.
- Substance Use Disorder records under 42 CFR Part 2.
- Psychotherapy notes under section 164.501.
- Full member Social Security Numbers (hashed or last-4 only, where required).
- Member contact data (full address, phone, email) unless specifically required for a Tier 3 case under documented Minimum Necessary justification.
The vendors that may touch ePHI, and how each is bound.
Each subcontractor below is bound by an executed BAA under section 164.502(e)(1)(ii) where ePHI may be in scope. The full register, including BAA execution dates and most recent attestation evidence, is available to counterparty counsel under NDA.
CoreWeave Cloud
Hosts JIL's agentic AI workloads, including Tier 1 Ava analysis. CoreWeave maintains SOC 2 Type II and ISO 27001 alignment, operates a published Shared Responsibility Model, signs a HIPAA Business Associate Agreement on request, and has a publicly disclosed HITRUST CSF program in flight.
By tier: Tier 1 Ava runs with no PHI in prompt context, embedding stores, or inference logs (Section 02). Tier 2/3 PHI does not leave JIL's enclave; where AI assistance is needed, requests route through a controlled gateway with PHI redaction or tokenization before any external inference call.
Allocation: CoreWeave is accountable for underlying physical, network, and platform safeguards under the Shared Responsibility Model. JIL Sovereign retains accountability for application-layer Administrative, workforce-Physical, and Technical safeguards under sections 164.308 through 164.316.
BAA: Executed under NDA. Reviewed annually.
Identity proofing partners
Third-party identity-document proofing and biometric liveness providers, integrated via a pluggable compliance-api gateway. Each provider is selected per-jurisdiction and is bound by an executed BAA where ePHI may be in scope. No raw PII is stored on-chain.
BAA: Per-vendor. Maintained in BAA register.
Operational subprocessors
The complete JIL subprocessor list, including each vendor's HIPAA posture, executed BAA date, and most recent SOC 2 / ISO 27001 / HITRUST attestation, is maintained by the Security Officer and shared under NDA with counterparties during diligence. Material additions or substitutions trigger written notice under the standard BAA.
BAA register: Available under NDA.
The frameworks that govern CMS and federal-program work.
For engagements under CMS Medicare Advantage organizations, Medicaid managed care, the federal Task Force to Eliminate Healthcare Fraud, and adjacent federal-payer programs, JIL aligns to the following frameworks in addition to the HIPAA baseline above.
CMS ARS 5.1
Acceptable Risk Safeguards 5.1 (Moderate baseline). NIST SP 800-53 Rev. 5 control families mapped through the JIL self-assessment.
NIST CSF 2.0
Six core functions (Govern, Identify, Protect, Detect, Respond, Recover) self-assessed at Tier 1 to Tier 4 with documented Respond and Recover roadmap items.
CMS 60-Day Rule
Tier 1 detection plus Ava is engineered to bring an MCO inside the section 1128J(d) safe harbor with documented identification and reporting timelines.
HHS-OIG CPG
Compliance Program Guidance elements (designated Compliance Officer, code of conduct, training, auditing and monitoring) reflected in JIL's internal program.
MARS-E 2.2
Minimum Acceptable Risk Standards for Exchanges, applied where ACA Exchange data is in scope. Subset of CMS ARS controls; mappable through the same NIST 800-53 control catalog.
FedRAMP
FedRAMP Moderate is on the JIL roadmap for engagements that require federal government deployment. Current path is partner-fronted with JIL controls inherited.
The third-party attestations that move JIL beyond self-assertion.
Self-attestation is a starting point, not a destination. JIL is engaged on the following independent assessments and certifications, sequenced to deliver the strongest assurance to MCO and CMS-facing buyers in the shortest realistic timeline.
External engineering review
Independent engineering review by Emerging Technologies LLC and BlockChainX covering protocol, MPC, and verification layers.
SOC 2 Type II
Type II examination engaged. Mapping covers Security, Availability, and Confidentiality Trust Services Criteria. Evidence base anchored on 512M+ certified test cases.
ISO 27001:2022
Information Security Management System certification, sequenced after SOC 2 to leverage shared evidence and control mappings.
HITRUST CSF e1 then i1
Stepped HITRUST CSF certification, beginning with e1 (essentials) and progressing toward i1. SOC 2 evidence is portable into the e1 control set.
HITRUST CSF r2 (target)
Full r2 validated assessment, the gold standard for healthcare PHI assurance. Most MCOs accept r2 in lieu of bespoke vendor security questionnaires.
FedRAMP Moderate
Triggered by federal CMS engagement. Partner-fronted path compresses authorization timeline from 18-24 months to 60-120 days where the prime carries an existing ATO.
The signed statement.
JIL Sovereign Technologies, Inc. attests that the data-tier architecture described in this document is in effect as of the date below; that Pre-Settlement Attestation, Retroactive Tier 1 with Ava, Wallet Intelligence, and Asset Intelligence operate without PHI ingress in normal operation; that PHI engagement on Tier 2 and Tier 3 cases is gated by explicit buyer authorization and runs in an isolated enclave under the Full BAA; that the standing and PHI-engagement safeguards described in Sections 05 and 06 are operational with the noted roadmap items under active management; and that any material change to JIL's HIPAA posture will be reflected in a versioned update to this document and communicated to counterparty Covered Entities and upstream Business Associates per the executed BAA. This attestation is made in good faith based on documented evidence and is subject to ongoing third-party verification through the assurance roadmap above.
JIL Sovereign Founder
Founder and CEO
JIL Sovereign Technologies, Inc.
Joshua McCarley
Chief Operating Officer
JIL Sovereign Technologies, Inc.
Stanley Byrne
Chief Information Officer - Security Officer
JIL Sovereign Technologies, Inc.