JIL on Databricks. Six product lines. One governed runtime.

01 The whole system runs inside the customer's Databricks workspace.

Every box rendered inside the framed platform region is a workload that executes inside the customer's own Databricks workspace, on the classic compute plane that lives in the customer's cloud account. Not a SaaS endpoint they pipe data to. Not a copy that lives in JIL infrastructure. The customer's claims, prior auth requests, eligibility files, wallets, and counterparty data never move. JIL's services are deployed to the data, the data is not deployed to JIL.

That single architectural decision is what unlocks payer, federal, and sovereign procurement. No data exfiltration risk. No third-party vendor data residency review. No new HIPAA pathway. The customer's existing Unity Catalog governance posture covers JIL by definition, because JIL is running under it.

02 Databricks Apps and Workflows are the runtime.

The orchestration layer at the top of the platform is Databricks Workflows scheduling JIL's services, with Databricks Apps hosting the in-workspace interfaces. JIL ships its 300 services as Apps, jobs, and Mosaic AI serving endpoints. Databricks allocates compute through Photon and serverless clusters, and exposes results through SQL-callable Unity Catalog functions and Databricks Apps that customer analysts and counsel use without leaving the workspace. RBAC, lineage, masking, and credential management are all native to Unity Catalog. JIL inherits them.

03 The detection ML and the agentic layer live next to the data.

This is where the Databricks runtime earns its keep. AVA™, JIL's agentic AI layer, and the machine learning models behind the Verdict Engine run on Mosaic AI inside the same governed account as the claims and counterparty data. There is no feature pipeline shuttling sensitive data to an external model host and no separate ML governance surface to certify. The models are trained, served, and audited under the same Unity Catalog lineage that covers everything else. On a lakehouse built for AI, the proof layer and the intelligence layer are the same deployment.

04 Six product lines. One verdict spine.

The six product cards in the middle are not separate platforms. They are differentiated entry points that all converge on the same shared engines below them: the Verdict Engine running 234 checks across 15+ categories, the Bad Actor Registry as the cross-product knowledge graph, the CREB™ generator producing FRE 902(14) court ready evidence packages, and the Sealed Escrow PoCS layer. A claim seen by Pre-Settlement and a wallet seen by Wallet Intel hit the same registry. A grantee cleared by Attestyx and a provider scrutinized by Utilization Management share the same evidence schema.

05 Utilization Management is the new sixth surface.

Utilization Management is highlighted in gold because it is the newest addition and because it carries the most carefully scoped legal posture. It is a proof layer beneath the plan's medical team, never above it. It does not approve or deny care. It validates that the medical necessity evidence on file is internally consistent, that the documentation pattern matches peer norms, and that any flagged outliers are surfaced for the human reviewer with a sealed audit trail. That deliberate scoping is what avoids the NaviHealth pattern of litigation. The plan's clinicians make the call. JIL proves what the plan's clinicians had in front of them when they made it.

06 The anchor layer is the only thing outside Databricks.

CourtChain™ and the five jurisdictional vaults sit beneath the platform because they have to live somewhere with sovereign neutrality. Hashes leave Databricks. Data does not. Every verdict, every CREB™, every PoCS receipt is hashed inside the customer's account, written to CourtChain™, and replicated across the US, Switzerland, UAE, Singapore, and Brazil vaults. The customer can prove a verdict was rendered at a specific time on specific evidence without ever exposing the evidence itself. That is the FRE 902(14) admissibility bridge, and it is the reason an MCO general counsel, a state Medicaid director, and a federal IG can all use the same artifact.

07 Why Databricks instead of building it ourselves.

Three reasons, in order of weight to the buyer. First, a large and growing share of payers, banks, and federal civilian agencies have standardized on Databricks, frequently on the Azure Databricks footprint that carries the regulated and FedRAMP posture those buyers require. Meeting them inside their existing data plane removes the longest line item in any procurement cycle. Second, the lakehouse gives JIL a managed compute substrate with native governance through Unity Catalog, native zero-copy sharing through Delta Sharing, native elasticity through Photon and serverless, and a first-class ML and agentic surface in Mosaic AI that would take a multi-year platform investment to replicate. Third, the commercial story to investors is cleaner. JIL is a detection and proof IP company riding on top of the most defensible data infrastructure layer in the enterprise. JIL does not have to be an infrastructure company to win an infrastructure-grade procurement.

08 What the customer turns on, in plain language.

An MCO could activate Pre-Settlement and Utilization Management on day one and add Retroactive in quarter two. A foundation activates Pre-Clearance only. A federal program office activates Pre-Settlement and Asset Intel together. Each of those decisions is a SKU. None of them require a separate stack, a separate integration, or a separate audit. They are all the same engine, lit up against different pieces of the customer's existing Databricks workspace. And because the verdict spine is runtime-portable, a customer who later migrates between Databricks and Snowflake keeps the same SKUs, the same evidence schema, and the same CourtChain™ anchor.