This document specifies how JIL's six product lines deploy and execute inside a customer's Databricks workspace using Databricks Apps, Workflows, and Mosaic AI Model Serving on the customer's own compute plane. It identifies the precise Databricks objects that hold JIL's images, services, models, and operational state. It defines the trust boundary between the customer's Databricks account and JIL's sovereign network. It enumerates the IP-protection layers that prevent even a sophisticated customer account or workspace administrator from extracting JIL's verdict logic, rule packs, model weights, or cross-customer intelligence.
It is intended as the architectural reference that engineering, security, and legal counsel can all work from, and as the Databricks-native counterpart to the Snowflake design document (JIL-TDD-SF-001). The verdict spine is identical across both. Only the substrate primitives differ.
Executive Summary
JIL deploys to Databricks as a set of signed, encrypted, attestation-gated workloads that execute inside the customer's own Databricks workspace, 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 Databricks account. JIL's services run on the classic compute plane in the customer's own cloud VPC, or on serverless compute within the customer's account boundary. Verdicts are computed in place against Delta tables the customer already owns. JIL operates no ingestion pipeline and stands up no external endpoint that customer data is piped to.
Second, JIL's intellectual property is protected by defense in depth even though the engine runs on infrastructure the customer controls. The 234 verdict checks, the rule packs, the model weights, and the Bad Actor Registry are shielded by compiled and encrypted artifacts, runtime-only key release gated by remote attestation, and remote execution of the highest-value logic on JIL's sovereign network.
Third, the cross-customer evidence and intelligence layers live in JIL's sovereign network, outside the reach of any single customer. CourtChain™, the Bad Actor Registry, and the Authority Server are never deployed into a customer account. Customers query them through privacy-preserving interfaces that return verdicts and hashed selectors, never raw cross-customer records.
The customer can prove, to their general counsel, their CISO, their auditor, and their regulator, that JIL never sees their data. JIL can prove, to its own investors and 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.
Reference Architecture
The figure below shows every object that lives in the customer's Databricks account, every object that lives in JIL's sovereign network, and every flow that crosses the trust boundary between them. Data resides on the customer side. Only hashes, attestations, and privacy-preserving selectors cross the boundary.
Everything inside the left zone runs under the customer's existing Unity Catalog governance posture. Nothing in the right zone is ever provisioned into the customer account. The dashed seam is the only network path, and it carries no raw customer data.
Artifact & Image Residency
JIL ships three classes of artifact. Each has a defined residency, a defined protection posture, and a defined Databricks object that holds it.
| Artifact | Databricks Object | At-Rest State | Readable By Customer Admin? |
|---|---|---|---|
| Service containers (Apps, custom-image clusters) | Databricks Container Services image pulled from JIL registry; deployed via Databricks Apps | Signed image digest, layers encrypted | No. Pull is attestation-gated; layers decrypt only in the attested runtime. |
| Rule packs & verdict logic (234 checks) | Compiled native libraries in a Unity Catalog Volume, JIL-owned catalog | Compiled + AES-256 encrypted | No. Compiled, not source; keys never persisted to the workspace. |
| Model weights (Verdict Engine, AVA™) | Unity Catalog Model Registry, served by Mosaic AI | Encrypted weights, sealed serving env | No. Weights decrypt in-memory in the serving process only. |
| Bad Actor Registry & cross-customer graph | Not resident. Lives in JIL sovereign network | N/A in customer account | No. Never deployed to the account at all. |
| Verdict and CREB™ output | Customer Delta tables and Volumes | Plaintext, customer-owned | Yes. This is the customer's own output, by design. |
JIL's executable IP is present in the account only in compiled, encrypted, or remote form. The customer's data and the customer's verdict output are present in plaintext, because both belong to the customer. The asymmetry is deliberate and is enforced at the platform layer, not by policy alone.
Runtime Topology
On Snowflake the runtime is Snowpark Container Services. On Databricks the equivalent responsibilities are distributed across three managed surfaces, all native to the platform and all governed by Unity Catalog.
| Responsibility | Snowflake (SF-001) | Databricks (this doc) |
|---|---|---|
| Container orchestration | Snowpark Container Services | → Databricks Apps + Databricks Container Services on Workflows |
| Batch & scheduled execution | SPCS jobs / tasks | → Databricks Workflows (Jobs) |
| Model inference | Service Functions over container | → Mosaic AI Model Serving endpoints |
| SQL-callable verdicts | Service Functions | → Unity Catalog SQL / Python UDFs |
| In-account UI | Streamlit in Snowflake | → Databricks Apps |
| Compute allocation | Warehouses | → Photon clusters + Serverless |
| Governance & RBAC | Native account RBAC + Horizon | → Unity Catalog |
| Zero-copy feeds | Native Data Sharing | → Delta Sharing |
Execution path of a single verdict
- An inbound claim lands in a customer Delta table, or a Workflow sweeps a settled-claims partition.
- A JIL Databricks App or Job picks up the record under a JIL service principal scoped by Unity Catalog.
- Non-sensitive checks run locally in the attested container. The Mosaic AI endpoint scores model-driven checks in-account.
- For crown-jewel checks and registry lookups, the service sends hashed, tokenized features over mTLS to JIL's sovereign network and receives a verdict fragment back. No raw record crosses.
- The merged verdict, and any CREB™, is written back to a customer Delta table. Its hash is anchored to CourtChain™.
Multi-Tenancy & Isolation
There is no shared JIL compute tenant. Each customer runs its own deployment in its own Databricks account. JIL operates no multi-tenant data plane that commingles customer records, which removes an entire class of procurement and residency objection before it is raised.
- Per-customer deployment. Each customer receives its own JIL catalog, its own service principals, and its own Asset Bundle deployment. Isolation is the platform's account boundary, not a row filter.
- Per-customer keys. Artifact decryption keys are derived per deployment and bound to that deployment's attestation. A key released to Customer A's runtime is useless in any other environment.
- Cross-customer intelligence stays central. The Bad Actor Registry is the only shared asset, and it is never copied into an account. Customer A's query against it cannot enumerate Customer B's contributions; it returns only match or no-match against hashed selectors.
- Serverless boundary. Where serverless compute is used, it remains inside the customer's account governance and Unity Catalog audit scope. The classic compute plane option keeps execution physically in the customer VPC for buyers who require it.
The Trust Boundary
The boundary is the customer's Databricks account perimeter. The table below is the authoritative statement of what sits on each side and what is permitted to cross.
| Inside the customer account | Crosses the boundary | JIL sovereign network |
|---|---|---|
| Source Delta tables; JIL service containers; Mosaic AI endpoints; verdict and CREB™ output; Unity Catalog and audit logs. | Attestation requests; runtime key-release requests; hashed registry selectors; verdict and CREB™ hashes for anchoring. All over mTLS. No raw data. | Authority Server; Bad Actor Registry; critical-path scoring; CourtChain™ L1; five jurisdictional vaults. |
No raw customer record, no PII, and no PHI crosses the boundary under any code path. The egress allow-list on JIL's services permits exactly one destination, the Authority Server, over mutually authenticated TLS. Everything else is denied by the network connectivity configuration.
IP Protection · Defense in Depth
The hard problem is protecting JIL's IP when the engine runs on infrastructure the customer fully controls, including a customer account administrator with the highest privilege in the workspace. No single control is sufficient. Seven layers compound.
- Compiled, not source. Rule packs and the verdict logic ship as compiled native libraries. There is no readable source for the 234 checks in the account.
- Encrypted at rest. Compiled artifacts and model weights are AES-256 encrypted in their Unity Catalog Volume and Model Registry entries. Copying the bytes yields ciphertext.
- Runtime-only key release. Decryption keys are never stored in the workspace, in a secret scope, or on disk. They are fetched from the Authority Server at process start and held in memory for the life of the serving process only.
- Attestation gating. The Authority Server releases keys only after verifying the workload's attestation, including image digest and runtime environment. A copied image run outside the attested envelope receives no keys and cannot execute.
- Remote critical-path execution. The highest-value logic, including cross-customer registry scoring, never ships to the account. It runs on JIL's sovereign network and returns only verdict fragments.
- Privacy-preserving registry access. The Bad Actor Registry is reachable only through hashed-selector lookups. A customer cannot dump it, enumerate it, or reconstruct another customer's contributions.
- Tamper-evident audit and kill-switch. Every artifact pull, key release, and verdict is logged and anchored to CourtChain™, so extraction attempts are detectable. The Authority Server can revoke attestation or withhold keys, disabling the engine remotely.
| Threat | Primary Control |
|---|---|
| Account admin copies JIL container image | Layers encrypted; attestation gating denies keys outside the envelope |
| Admin exports the rule-pack Volume | Compiled + encrypted; no runtime keys present at rest |
| Admin dumps served model weights | Weights decrypt in-memory only; sealed serving environment |
| Admin probes the Bad Actor Registry | Registry is remote; hashed-selector access only, rate-limited |
| Admin reroutes egress to a customer endpoint | Single mTLS allow-list destination; NCC denies all other egress |
Identity, Access & Governance
JIL inherits the customer's Unity Catalog governance rather than introducing its own. This is the control that lets a customer's existing audit posture cover JIL by definition.
- Service principals. JIL services run under dedicated Unity Catalog service principals with least-privilege grants scoped to the specific catalogs and schemas the engaged products require.
- Lineage and audit. Every read, write, and function call is captured in Unity Catalog lineage and the customer's audit log delivery. The customer sees exactly what JIL touched.
- Masking and row-level security. Where a product does not require a column, the customer can mask it. JIL operates on the governed view, not the raw column, with no loss of verdict fidelity for tokenized fields.
- The admin threat is explicit. The Databricks account admin and metastore admin are treated as in-scope adversaries for IP extraction, which is why Section 07 does not rely on access control alone. Governance protects the customer's data from JIL. Cryptography and remote execution protect JIL's IP from the customer.
Data Flows Across the Boundary
Four flows cross the seam. Each is enumerated with its direction, payload, and protection.
| Flow | Direction | Payload | Protection |
|---|---|---|---|
| Attestation | Account → JIL | Image digest, environment claims | mTLS, signed, replay-protected |
| Key release | JIL → Account | Per-deployment decryption keys | mTLS, attestation-bound, in-memory only |
| Registry lookup | Account ⇄ JIL | Hashed selectors, verdict fragments | mTLS, hashed, rate-limited, no raw PII |
| Evidence anchor | Account → JIL | Verdict / CREB™ / PoCS hashes | mTLS, hash only, written to CourtChain™ |
Evidence Anchoring
The anchor layer is the only part of the system that is intentionally outside Databricks, because it has to live somewhere with sovereign neutrality. Hashes leave the lakehouse. Data does not.
Every verdict, every CREB™, and every Proof of Compliant Settlement receipt is hashed inside the customer's account and written to CourtChain™, JIL's purpose-built Layer 1 secured by a 14-of-20 BFT validator quorum. Signatures are Ed25519 plus Dilithium-III hybrid, with ML-DSA-65 and a Kyber KEM for the post-quantum envelope. Each record is replicated across the five jurisdictional vaults in the United States, Switzerland, the UAE, Singapore, and Brazil.
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(13) and FRE 902(14) admissibility bridge, and it is the reason an MCO general counsel, a state Medicaid director, and a federal inspector general can all rely on the same artifact.
Deployment & Lifecycle
- Deployment. JIL ships a Databricks Asset Bundle that provisions the JIL catalog, service principals, Apps, Workflows, and serving endpoints into the customer workspace. A clean deployment is a single bundle apply.
- Activation by SKU. Each of the six product lines is a switch. An MCO can activate Pre-Settlement and Utilization Management on day one and add Retroactive in quarter two with no new stack, integration, or audit.
- Updates. New rule packs and model versions are delivered as encrypted artifacts and a registry pointer change. The Authority Server gates the new version behind a fresh attestation.
- Revocation. At end of contract, JIL withholds keys and revokes attestation. The encrypted artifacts become inert ciphertext and the customer's own data and prior output remain entirely theirs.
Security & Compliance Posture
- Encryption. AES-256 at rest for all JIL artifacts; mTLS in transit for every boundary flow; post-quantum hybrid signatures on every anchored record.
- Network. Classic compute plane in the customer VPC option; PrivateLink and IP access lists supported; single-destination egress allow-list enforced by network connectivity configuration.
- Federal and regulated. Deployable on the Azure Databricks footprint that carries the regulated and FedRAMP posture federal and healthcare buyers require, inside the customer's existing authorization boundary.
- Auditability. Unity Catalog lineage and audit-log delivery give the customer a complete record of JIL activity. CourtChain™ anchoring gives an independent, tamper-evident record of every verdict.
- Runtime portability. The verdict spine, the evidence schema, and the CourtChain™ anchor are identical on Databricks and Snowflake. A customer that migrates between the two keeps the same SKUs and the same admissibility posture.