JIL on Snowflake.
Technical Design Document.

This document specifies how JIL's six product lines deploy and execute inside a customer's Snowflake account using Snowpark Container Services. It identifies the precise Snowflake objects that hold JIL's images, services, and operational state. It defines the trust boundary between the customer's Snowflake account and JIL's sovereign network. It enumerates the IP protection layers that prevent a sophisticated customer ACCOUNTADMIN from extracting JIL's verdict logic, rule packs, or cross-customer intelligence. It is intended as the architectural reference that engineering, security, and legal counsel can all work from.

Document ID	JIL-TDD-SF-001
Revision	1.0 · 2026.05
Status	Reference Architecture
Classification	Confidential, internal and approved counsel
Owner	Office of the CTO · JIL Sovereign Technologies, Inc.

Section 01Executive Summary

JIL deploys to Snowflake as a set of signed, encrypted, attestation-gated container services that execute inside the customer's own Snowflake account, against the customer's own data, with no copies leaving the account.

The design has three architectural commitments. First, customer data never leaves the customer's Snowflake account. Verdicts are computed in place. Second, JIL's intellectual property — the 175 verdict checks, the rule packs, the model weights, the Bad Actor Registry — is protected by defense in depth even though the engine runs on infrastructure the customer controls. Third, the cross-customer evidence and intelligence layers (CourtChain™, the Bad Actor Registry, the Authority Server) live in JIL's sovereign network outside the reach of any single customer.

The result is an architecture in which the customer can prove, to their general counsel, their CISO, their auditor, and their regulator, that JIL never sees their data — while JIL can prove, to its own investors and to its own legal counsel, that the customer can never see JIL's intellectual property. Both statements are true at the same time, and the rest of this document explains how.

Section 02Reference Architecture

The diagram below shows every object that lives in the customer's Snowflake account, every object that lives in JIL's sovereign network, and every flow that crosses the trust boundary between them.

Section 03Component Inventory

Every Snowflake object, every JIL service, and every JIL sovereign component shown in Figure 01, with its purpose, location, and ownership.

Object	Type	Location	Purpose
JIL_DB	Snowflake Database	Customer Account	Top-level container for all JIL-managed objects in the customer account.
JIL_DB.JIL_REPO	Schema · Image Repository	Customer Account	OCI image registry for signed JIL containers. Push-controlled by JIL service account.
JIL_DB.JIL_SVC	Schema · Service Definitions	Customer Account	SERVICE specifications (YAML) for each JIL container. Version pinned by image digest.
JIL_DB.JIL_AUTH	Schema · Secrets & Tokens	Customer Account	OAuth tokens for the JIL Authority Server. Snowflake-managed; values not exposed.
JIL_POOL	SPCS Compute Pool	Customer Account	Dedicated Kubernetes pool that runs JIL service containers. Customer-billable.
PRE_SETTLEMENT_SVC	SPCS Service	Customer Account	Real-time verdict engine. Sub-800ms verdicts on inbound claims and wires.
RETROACTIVE_SVC	SPCS Service	Customer Account	Forensic sweep engine. Generates CREB™ packages on settled claims.
PRE_CLEARANCE_SVC	SPCS Service	Customer Account	Attestyx grant clearance engine. Pre-flight grantee diligence.
ASSET_INTEL_SVC	SPCS Service	Customer Account	Counterparty graph engine. UBO, sanctions, PEP resolution.
WALLET_INTEL_SVC	SPCS Service	Customer Account	On-chain wallet attribution and laundering pattern detection.
UTILIZATION_MGMT_SVC	SPCS Service	Customer Account	UM evidence consistency and peer-norm outlier proof. No clinical decisioning.
JIL_NETWORK_RULE	External Network Rule	Customer Account	Strict egress allow-list. Four FQDNs only. All other outbound denied.
Authority Server	JIL Sovereign Service	JIL Network	Image attestation, key issuance, audit. The gate that controls runtime activation.
Bad Actor Registry	JIL Sovereign Service	JIL Network	Cross-customer knowledge graph. Read-only over the wire. Never copied to customers.
CourtChain™ L1	JIL Sovereign Network	5 Vaults	Layer 1 ledger anchoring verdicts and CREBs. BFT consensus across 20 validators.

Section 04Image Lifecycle · Build to Production

Images are built, encrypted, and signed at JIL infrastructure, then pushed into the customer's Snowflake image repository. Snowflake never sees the plaintext rule packs. Customer ACCOUNTADMIN can enumerate the image but cannot decrypt or run its contents without an active attestation key from the Authority Server.

4.1 · Build (Stages 01 to 04)

Performed entirely on JIL CI infrastructure (GitHub Actions, JIL-controlled runners, JIL KMS).

• Compile. Rust source compiled with cargo build --release, optimization level 3, link-time optimization on, and panic-abort. Symbols stripped via strip --strip-all. Result is a native shared library (.so) with no debug information and no readable function names.
• Encrypt. Rule packs (the 175 checks, model weights, threshold tables, jurisdictional policy packs) encrypted with AES-256-GCM. Keys generated and held exclusively in JIL's HSM-backed KMS. Per-version key rotation prevents one-time leaked key from compromising future releases.
• Package. Multi-layer OCI image built with the stripped binary, the encrypted blobs, and a thin Light Client that handles attestation, registry queries, and CourtChain™ bridging. Base image is a minimal distroless Linux to reduce attack surface.
• Sign. Image signed with cosign. SHA-256 digest captured in SLSA provenance. Signature verified by Snowflake at pull time and by the Authority Server at attestation time.

4.2 · Push (Stage 05)

JIL maintains a service account in each customer's Snowflake account with WRITE on JIL_DB.JIL_REPO.IMAGES. Push happens over Snowflake's authenticated image registry API. After push, the image is stored as a Snowflake-managed binary in customer storage, and Snowflake assigns it a content-addressable URL.

-- Customer ACCOUNTADMIN runs once at deployment
CREATE IMAGE REPOSITORY JIL_DB.JIL_REPO.IMAGES;
GRANT WRITE ON IMAGE REPOSITORY JIL_DB.JIL_REPO.IMAGES TO JIL_PUSH_ROLE;

-- JIL CI pushes after every release
$ snow spcs image-registry token --account acme-mco
$ docker tag jil/pre-settlement:v3.4.1 \
    acme-mco.registry.snowflakecomputing.com/jil_db/jil_repo/images/pre-settlement:v3.4.1
$ docker push acme-mco.registry.snowflakecomputing.com/jil_db/jil_repo/images/pre-settlement:v3.4.1

4.3 · Deploy (Service Creation)

The customer (or JIL on the customer's behalf) creates a SERVICE that pins the image digest, the compute pool, the network rule, and the secret used to authenticate to the Authority Server. The YAML spec is visible to ACCOUNTADMIN; nothing in it is sensitive.

CREATE SERVICE JIL_DB.JIL_SVC.PRE_SETTLEMENT_SVC
  IN COMPUTE POOL JIL_POOL
  FROM SPECIFICATION $$
spec:
  containers:
    - name: pre-settlement
      image: /jil_db/jil_repo/images/pre-settlement:v3.4.1
      env:
        AUTHORITY_URL: https://authority.jilsovereign.com
        ACCOUNT_ID: acme-mco
      secrets:
        - snowflakeSecret: JIL_DB.JIL_AUTH.AUTHORITY_TOKEN
          envVarName: AUTHORITY_TOKEN
  endpoints:
    - name: verdict
      port: 8443
      protocol: HTTPS
  networkPolicyConfig:
    allowInternetEgress: false
$$
  EXTERNAL_ACCESS_INTEGRATIONS = (JIL_NETWORK_RULE);

Section 05Multi-Tenancy Model

JIL operates as a single-tenant deployment per customer Snowflake account. Snowflake itself is multi-tenant; JIL is not. There is no JIL "control plane" inside Snowflake that aggregates state across customers. Cross-customer aggregation happens outside Snowflake, in the JIL Sovereign Network.

This split is a deliberate architectural choice. It gives the customer an audit story they can defend ("JIL inherits our governance, runs in our account, never moves our data"), and it gives JIL a network-effect story it can defend ("the registry gets stronger every time a new customer activates, because every flagged entity goes into a shared graph"). Both stories are true at once.

Section 06Attestation & Key Management Flow

The Authority Server is the single point of control that determines whether an image, once deployed, can actually decrypt and execute its rule packs. Without an active attestation, a JIL container is an inert binary with encrypted blobs it cannot read.

6.1 · Container Startup Sequence

1. Pod scheduled. Snowflake schedules the pod onto a compute pool node, pulls the image (signature verified at pull time), and starts the container.
2. Light Client wakes. The first executable in the container is the Light Client, not the engine. The engine cannot run yet because its rule packs are still encrypted.
3. Attestation request. Light Client opens an mTLS connection to authority.jilsovereign.com, presenting the Snowflake account ID, the image digest, the pod identity, and a fresh nonce signed with the OAuth token from JIL_DB.JIL_AUTH.
4. Authority validation. The Authority Server confirms (a) the image digest is on the JIL approved release list, (b) the customer account has an active JIL contract, (c) the OAuth token is valid, (d) the customer has not been revoked.
5. Key issuance. If all four checks pass, Authority returns a 5-minute time-limited rule-pack decryption key, sealed to the requesting pod's identity.
6. Decrypt in memory. Light Client decrypts the rule packs into memory only. Plaintext rule packs never touch disk.
7. Engine activation. The Verdict Engine binary is now functional. It signals readiness back to Snowflake. The service starts accepting traffic.
8. Rolling re-attestation. Every 4 minutes, the Light Client refreshes the key. If the refresh fails (network down, contract suspended, revocation), the engine zeroes its in-memory keys and refuses further verdicts within the same TTL.

6.2 · Revocation Posture

If a customer relationship ends, JIL revokes the OAuth token in the Authority Server. Within 5 minutes, every running JIL container in that customer's account loses its decryption keys. The containers continue running, but they cannot serve verdicts because the rule packs are no longer accessible. The customer is not damaged: their data is intact, their Snowflake account is intact. But the JIL engine has effectively self-disabled.

This is the same posture as a SaaS vendor terminating an account, except the customer's data and infrastructure remain entirely under their control. JIL has no "kill switch" that touches the customer's Snowflake; it only has a kill switch that touches its own attestation service.

Section 07IP Protection Layers · Defense in Depth

Treat the customer ACCOUNTADMIN as a sophisticated potential adversary. The architecture is designed so that even with full administrative access to the Snowflake account, they cannot extract operational JIL intellectual property.

Layer	What it protects	Mechanism
L1 · Native binary	The 175 verdict checks and engine logic	Rust compiled with LTO and stripped symbols. Reverse engineering requires expert work and recovers no business logic, only machine code.
L2 · Encryption at rest	Rule packs, model weights, threshold tables	AES-256-GCM, keys held only by JIL Authority. Image alone is useless without an active attestation.
L3 · Attestation gate	Runtime activation	5-minute key TTL. Continuous attestation. Revocable instantly.
L4 · In-memory only	Decrypted rule packs at runtime	Plaintext rules exist only in pod memory, never on disk, never in logs, never in env vars. Pod memory is not introspectable from Snowflake's control plane.
L5 · Image signing	Engine integrity	Cosign signature verified at pull and at attestation. Tampered images fail attestation and never receive keys.
L6 · Network isolation	Bad Actor Registry, CourtChain™, all sovereign IP	Egress allow-list permits only four JIL FQDNs. Registry, chain, and Authority are read-only over the wire from customer perspective.
L7 · Sovereign separation	Cross-customer intelligence	The Bad Actor Registry, the network-effect graph, and the verdict catalog evolution all live on JIL infrastructure outside Snowflake entirely.

Section 08Customer Visibility Matrix

What an ACCOUNTADMIN with full access to the customer's Snowflake account can see, partially see, or cannot see at all. This is the substantive answer to "is our IP safe."

Asset	ACCOUNTADMIN access	What they get
Image binary blob	Visible	Encrypted/stripped binary. No usable IP without an active attestation key.
Service spec YAML	Visible	Configuration only. No secrets in YAML. Reveals nothing about engine logic.
Container logs (stdout/stderr)	Visible	Engineering logs only. Engine deliberately does not log rule pack contents, model weights, or Bad Actor Registry data.
Environment variables	Visible	URLs and config flags only. Auth tokens come from Snowflake Secret store, not env vars.
Compute pool usage / billing	Visible	Standard Snowflake observability. Cost and capacity, no engine internals.
Network rule and egress targets	Visible	The four JIL FQDNs are visible. Customer can verify nothing else is being called.
Pod runtime memory	Not accessible	SPCS does not allow attaching debuggers or shells to running pods. Memory is a closed runtime.
Decrypted rule packs at runtime	Not accessible	Plaintext rules exist only in pod memory. Memory is closed. Disk and logs never see them.
JIL Authority Server keys	Not accessible	Keys are issued ephemerally per-pod, sealed to pod identity, expire in 5 minutes. Customer cannot extract from the Authority API.
Bad Actor Registry full graph	Not accessible	Registry is queried live, query-by-query. The full graph never sits in customer cloud. Bulk export is rate-limited and audited.
CourtChain™ full ledger	Not accessible	Customer holds light-client receipts only. Full chain history sits on JIL validators across five vaults.
Cross-customer intelligence	Not accessible	Other customers' verdicts, patterns, and flagged entities never enter this customer's account. They influence registry queries from outside.
Verdict reasoning (per-claim)	Partial	Customer sees the verdict, the CREB™ output, and the high-level reasoning trace. They do not see the underlying rule expressions, threshold values, or model weights that produced the reasoning.

Section 09Deployment Posture · Partially-In Today, All-In Tomorrow

The architecture described above is the target state. Today, JIL runs a hybrid: data and attestation compute are Snowflake-native (Snowpark Container Services); customer-facing UI, authentication, and ancillary services run outside the Snowflake boundary. This section is a candid accounting of which surfaces live where, what compliance certifications each posture inherits, and the migration path to all-in.

Where each layer runs today

Layer	Snowflake-native (SPCS / Snowflake objects)	External (Hetzner / dev box)
Reference data (NPPES, LEIE, PECOS, OFAC, sanctions feeds)	All-in	—
Claims / billing data (Part D, Phys/Supp, DMEPOS, inpatient, outpatient, SNF, HHA, hospice)	All-in (382M+ rows)	—
Tier 1 deterministic attestation engine	All-in (SQL + SPCS jobs)	—
AVA cluster generator	All-in (SQL)	—
Premise classifier (Google Places, USPS validation, Street View)	Partial — results land in Snowflake	Lookup script runs externally
External-data ingest workers (SAM.gov, OFAC CSL, UN, UK HMT, FinCEN)	Partial — output lands in Snowflake	Loader script runs externally
Customer-portal UI (customer.jilsovereign.com)	—	All external (Next.js on Hetzner)
Authentication, session, OAuth, MFA	—	All external (retail-v2-api + postgres)
Engagement records, AVA plan receipts, demo state	—	All external (postgres trust.*)
Secure Document Vault (SDV) artifacts	—	Hetzner Object Storage
175+ supporting microservices (KYC, MPC, bridge, validators, etc.)	—	Docker on Hetzner

Compliance inheritance — what each posture buys you

A Snowpark Container Services workload inherits the compliance perimeter of the Snowflake account it runs in. Anything outside that perimeter inherits whatever the operator (Hetzner, JIL) certifies independently. The table below reads each certification across both surfaces.

Certification	Snowflake-native side	External (Hetzner) side
SOC 2 Type II	Inherited (every Snowflake edition is SOC 2 Type II)	JIL would need our own SOC 2 — in progress (target Q4 2027)
HIPAA (BAA required)	Inherited only on Snowflake Business Critical edition + signed BAA. Standard edition cannot legally process PHI.	JIL would need Hetzner BAA + our own HIPAA controls for any PHI on the external side
HITRUST CSF	Available on Business Critical with HITRUST certification on the account	JIL would need our own HITRUST cert for any external services touching PHI
FedRAMP Moderate / High	Inherited on Snowflake Government region (AWS GovCloud / Azure Government). Not available on commercial regions.	—
PCI DSS	Inherited on Business Critical	—
GDPR (data residency + DSR)	Snowflake account region pin (e.g., AWS eu-central-1) satisfies residency. DSR tooling supported.	Hetzner Frankfurt is EU — helps for the residency dimension
ISO 27001 / 27017 / 27018	Inherited	JIL would need our own

The all-in migration path

Going from partially-in to all-in eliminates the external compliance surface. Two technical decisions, one commercial decision:

Step	Effort	What it removes
1. Snowflake edition upgrade Standard → Business Critical, sign BAA, enable HITRUST controls	Commercial decision · ~1 week	Unlocks legal PHI processing on the Snowflake side. Prerequisite for everything else.
2. Move customer-portal UI into SPCS Containerize the Next.js app, push to Snowflake image repo, expose via SPCS service with public endpoint	~1-2 weeks	Removes Hetzner from the user-facing serving path. UI inherits Snowflake's compliance perimeter.
3. Move auth + engagement state into Snowflake Replace retail-v2-api auth with Snowflake user federation; move trust.engagements / trust.ava_plan_receipts into JIL_DATA tables	~1-2 weeks	Removes Hetzner postgres from the customer-data path. Engagement records inherit Snowflake's compliance perimeter.
4. Move premise enrichment + external feeds into SPCS jobs Containerize the Python scripts; trigger via Snowflake Tasks	~3-5 days	Removes the last external-script surface. Every call to Google Maps Platform / SAM.gov / OFAC originates from inside the Snowflake account.
5. JIL SOC 2 Type II + HITRUST CSF For any IP held outside Snowflake (e.g., engineering build pipeline, source repo)	~3-6 months (auditor-driven)	The last non-Snowflake compliance gap. Not strictly required for all-in deployment, but expected by enterprise buyers.

Steps 1–4 are achievable in ~4-6 weeks total, fully removing the external surface. Step 5 runs in parallel on its own auditor timeline.

Section 10Annual Cost · Today vs All-In

What it actually costs to run this platform — both at today's partially-in posture (sufficient for pre-production demos against public CMS data) and at the all-in production posture (required before processing any payer's real PHI). All numbers are USD list pricing; enterprise contracts typically negotiate 10-25% off Snowflake.

Today — partially-in (demo against public CMS data)

Item	Detail	Annual
Snowflake Standard edition	Currently inside trial credits; baseline ~$2-3K/yr for compute + storage at our usage	~$2-3K
Hetzner Portal CPX62	16 vCPU, 32 GB RAM, 640 GB NVMe — Frankfurt	$520
Hetzner sandbox + auxiliary	Demo + testing environments	~$300
Google Maps Platform	Places + Street View + Address Validation — ~100 calls/day for premise classification	~$200
Cloudflare + domain registration	2 zones (jilsovereign.com + getjil.com) + DNS + tunnel	~$200
Other vendor subscriptions	See /Internal_Subscriptions for the live list (Stripe, Twilio, Sumsub, etc. — billed per-use)	~$300
Subtotal — today's total cost of ownership		~$3.5K / year

All-in — Snowflake production for MCO-scale PHI engagement

The migration described in Section 09 plus the compliance overhead required to process payer claims data.

Item	Detail	Annual
Snowflake Business Critical base commit	Required for HIPAA BAA + HITRUST inheritance. Min annual commit (region + contract dependent)	$50-75K
SPCS — customer-portal UI 24/7	1× CPU_X64_S node, always-on. ~0.16 credits/hr × 8,760 hr × ~$4.40/credit	~$6.2K
T1 v2 daily attestation pass	LARGE warehouse, ~30 min/day. 8 credits/hr × 0.5 hr × 365 × ~$4.40	~$6.4K
AVA cluster generation daily	MEDIUM warehouse, ~10 min/day	~$1.1K
SPCS — premise enrichment + Google APIs	~100 lookups/day Google Places + Street View + USPS validate	~$200
SPCS — external feed ingest jobs	SAM.gov, OFAC CSL, UN, UK HMT, FinCEN, DOJ daily refresh on XSMALL pool	~$300
Snowflake storage	~50 GB compressed (382M+ rows) at $40/TB/month	~$25
Engagement DB query traffic	UI queries, AVA plan reads — XSMALL on demand	~$700
Cloud Services billing overhead	~10% surcharge on compute per Snowflake's billing model	~$1.5K
Subtotal — Snowflake-side		~$66-91K
External compliance — required for production PHI
Snowflake BAA execution	Included in Business Critical contract	$0
HITRUST CSF certification	Initial $40-60K, annual renewal $25K	~$25K
JIL SOC 2 Type II audit	Annual third-party auditor (Schellman, A-LIGN, Prescient, etc.)	~$30-50K
Annual penetration test	External red-team engagement, retest after remediation	~$15-25K
Subtotal — compliance		~$70-100K
Grand total · all-in production cost of ownership		~$140-185K / year

Cost framing — what this buys you

A typical MCO Special Investigations Unit (SIU) operates with an annual budget of $5-20M and recovers $50-200M+ in pre-paid overpayments per year. A single signed MCO-scale contract pays for the all-in posture many times over. The $140-185K all-in cost is a 0.07-1% line item against the recovery yield — not a meaningful cost-justification question for a serious customer.

The cost does bind us to running on Business Critical edition and maintaining external compliance certifications. That's the right trade-off: the customer's actual ask is "prove you can process our PHI without breach risk," and the compliance overhead is the price of being able to answer that question definitively.

Section 11Customer Deployment Checklist

Everything a customer's IT, identity, network, compliance, and procurement teams need to configure on their side before JIL goes live in their environment — SSO + SCIM, network egress whitelisting for AWS Bedrock / SageMaker / Snowflake, Snowflake account setup (BYO or reader), BAA chain, webhook + SIEM integration, optional custom branding, and a realistic go-live timeline.

The deployment requirements are non-trivial: an enterprise customer must move through procurement, InfoSec, identity, network, and data engineering teams in parallel. We've maintained the full itemized list as a separate document so the customer can hand it directly to those teams as a single source of truth.

Section 12Closing · The Architectural Bargain

The customer keeps their data, their compute, their governance, their auditability. JIL keeps its IP, its network effect, its evidence sovereignty. Both can prove what they keep, to their respective regulators and stakeholders.

Every element of this design is in production-grade use somewhere in the enterprise software market today. Snowpark Container Services is generally available. AES-256-GCM with attestation-gated keys is standard for hardware security modules. Cosign image signing is the kubernetes ecosystem default. mTLS plus short-lived tokens is how every modern zero-trust architecture runs. Light clients with merkle proofs are how every modern blockchain consumer interacts with chains they do not host.

What is novel about JIL is the combination: detection logic and proof logic deliberately split across the trust boundary, attestation tying the detection IP to a sovereign authority, and a court-admissible evidence chain that makes the whole arrangement defensible in front of a federal judge. None of the individual pieces are exotic. The composition is the asset.