Home
Wallet

Sovereignty

Wallet

Security

Trust Architecture

Layer-1

Enterprise

Resources

Learn

Support

FAQ

Company

Contact

Enter JIL Wallet
JIL Sovereign
JIL Sovereign Technologies, Inc.
A Delaware Corporation · jilsovereign.com

Protected Health Information Data Flow

Effective: May 3, 2026
Owner: Office of the Chief Information Security Officer
Audience: Customer counsel, Customer security teams, vendor risk reviewers

1. Overview

The Company offers three deployment options for processing Customer Protected Health Information ("PHI"). Each option moves the PHI trust boundary differently. Customer counsel should select the option whose trust boundary is acceptable to the Customer's privacy and security posture, and the option is recorded in the Customer's vendor profile.

ModeWhere PHI livesWho controls keysBest for
Mode A - JIL TenantJIL's AWS account (account 884135110852, us-east-1)JIL (under AWS BAA)Customers who prefer that JIL operate the full stack and have signed the JIL <-> Customer BAA.
Mode B - Customer VPCCustomer's own AWS accountCustomer (KMS CMK in customer's account)Customers who require PHI never leave their own cloud account; JIL operators assume a cross-account role with ExternalId.
Mode C - Hybrid Edge TokenizationCustomer's on-prem environment for raw PHI; JIL operates only on tokens.Customer (tokenization vault on-prem)Customers with the strictest residency posture; PHI is tokenized at the Customer edge before any JIL service sees it.

2. Diagram

Customer trust boundary JIL trust boundary AWS BAA-covered subprocessor boundary

3. Trust-Boundary Walkthrough

3.1 Ingress

Raw PHI arrives at the Tokenization Vault. In Mode A, the Vault runs in JIL's AWS account behind a private VPC endpoint with TLS 1.3 enforced; in Mode B, the Vault runs in the Customer's own AWS account; in Mode C, the Vault runs on the Customer's premises and only tokens cross the boundary into JIL.

3.2 Tokenization

The Vault uses format-preserving encryption (FF3-1 / FPE-AES) to convert each PHI element into a token of the same shape. The crosswalk is held in a KMS-encrypted store (Mode A: JIL KMS; Mode B and Mode C: Customer KMS). The crosswalk is never copied outside the Vault.

3.3 Analytical pipeline

The AVA™ Pro pipeline operates on tokenized data only. Each agent's invocation is logged to CourtChain™ with a SHA-256 hash of the input, the model card (model id, prompt hash, region), and the SHA-256 of the output. PHI does not appear in any log line.

3.4 CREB™ output

The Drafter produces a sealed Court Ready Evidence Bundle. At the output boundary, and only there, the bundle is re-identified for delivery to the authenticated Customer. The re-identified bundle is encrypted to the Customer's public key (or PGP equivalent) before transit.

3.5 Audit trail

Every step is anchored. The audit-log retention is fifteen (15) years (S3 Object Lock Compliance) which exceeds the HIPAA Security Rule six-year minimum and aligns with FRE 902(14) self-authentication windows.

4. Inheritance from AWS

The Company inherits AWS's SOC 2 Type II, ISO 27001, FedRAMP Moderate, FedRAMP High, and HITRUST CSF Common Security Framework attestations for the AWS-managed components shown in the AWS BAA Subprocessor boundary. The AWS audit reports are available to the Company upon request and may be summarized for Customer review under the Customer-JIL non-disclosure agreement.