Continuous RADV readiness, before the sample letter.
Before the letter, AVA scores documentation support and shows the exposure. When the sample arrives, the work is matching enrollees to records already sealed. After the review, confirmed findings calibrate the next pass. Model versions, MEAT, and extrapolation caveats are in the regulatory detail below. AVA is the workbench. It is not a fifth evidence product.
Before AVA™: 18 months. $5M in fees. One case.
A typical FCA case against a large vendor takes 18+ months and $3-7M in counsel + expert + investigator fees before a single complaint is filed. AVA™ produces the same court-portable evidence bundle in under 5 minutes for a fraction of a percent of that cost. Then you decide whether to file.
The traditional path
- 6-9 months to investigate, sweep claim history, and identify pattern signatures by hand
- 3-6 months to map findings to controlling statutes + element-by-element with outside counsel
- 2-4 months on damages methodology with a forensic-accounting expert
- 2-3 months drafting the memo + assembling the evidence bundle
- $3-7M in fees before the complaint is filed
- No replay capability - reasoning lives in counsel's head + emails, not in a verifiable chain
The agentic path
- 52s Investigator builds the pattern-signature catalog
- 65s Theorist maps to statutes element-by-element
- 80s Adversary names every defense + counter-evidence required
- 73s Damages Quantifier emits 4 methodologies with 95% CIs
- 50s Drafter + Auditor seal the CREB™ bundle
- 2yr bit-identical replay from the pinned prompt and model record
Six specialists. One court-ready chain.
Each agent has one job. Each output is the next agent's input. Each reasoning chain is hashed before the next agent starts. The result: a CREB™ (Court Ready Evidence Bundle) that a defense expert can replay bit-identically two years from now.
Investigator
Job: Sweep the vendor's historical claim record. Build the evidentiary base layer.
Reads tokenized flagged claims + JIL Tier-1 signal codes (upcoding suspect, frequency anomaly, premise mismatch, etc.). Cross-references against the vendor's full claim history to compute base rates. Produces a structured set of pattern signatures with confidence per signature + the supporting evidence references.
Output contract: pattern_signatures[] + flagged_cohort_summary + chain_of_custody_evidence_refs[]. JSON schema enforced; if the model deviates, the orchestrator retries once then surfaces the failure to the Auditor.
Theorist
Job: Map the Investigator's pattern signatures to statutory elements. Propose viable legal theories.
Walks the federal False Claims Act (31 USC §3729), Anti-Kickback Statute (42 USC §1320a-7b), Stark Law (42 USC §1395nn), state Medicaid fraud statutes, ERISA fiduciary breach, civil RICO. For each candidate theory: cite the controlling statute element-by-element, identify the supporting pattern signatures, score the strength of the link, list the evidentiary gaps.
Output contract: proposed_theories[] with statute citations + element mapping + strength score + open evidentiary gaps. Theory selection is the Theorist's call; downstream agents inherit and stress-test.
Adversary
Job: Red-team the case. Anticipate every defense the vendor's counsel will raise.
For each Theorist-proposed theory: name the most plausible defense ("good-faith reliance on coding software", "absence of materiality post-Escobar", "intervening cause", "statute of limitations defense"). Rate the rebuttal strength honestly. List the specific counter-evidence required to defeat it (not "more documentation" - "Q3 2024 internal coding audit memos"). Identify the weakest link the case overall.
Output contract: defense_scenarios[] with rebuttal_strength: strong|moderate|weak + counter_evidence_required[] + weakest_link_analysis. The Adversary is paid to be honest about weak rebuttals; the Drafter decides what to drop.
Damages Quantifier
Job: Produce damages under multiple methodologies with statistical confidence intervals.
Four methodologies: extrapolation (flagged-cohort rate applied to full claim universe), unit-of-overpayment (sum the flagged set only - most conservative), benefit-of-bargain (paid minus what would have been paid for the actual service rendered), disgorgement (all vendor profit derived from the misconduct - broadest). Every methodology carries a 95% confidence interval and the explicit assumptions. Treble damages flag set only if a Theorist-cited statute allows it.
Output contract: calculations[] with amount_usd_cents + confidence_interval_95 + assumptions[] + treble_damages_eligible + recommended_methodology. Integer cents; no float drift in the audit chain.
Drafter
Job: Compose the investigative memo + the CREB™ bundle structure.
Reads the prior four agents' outputs as structured JSON. Composes the case theory summary, key evidence references, defenses anticipated, damages methodology, recommended action. Estimates the page count and exhibit count of the resulting CREB™ bundle. Generates structured bundle exhibits for the orchestrator to sign and persist - actual long-form rendering happens in the CREB renderer at filing time.
Output contract: investigative_memo_artifact_id + creb_bundle_artifact_id + honest page_count and exhibit_count estimates. Haiku because long-form generation at this stage is heavy-output / moderate-reasoning - ~3x cheaper per unit of output than Sonnet, sufficient quality.
Auditor
Job: Walk the entire chain. Verify integrity. Hold the seal until the chain passes.
Validates every prior agent's output schema. Verifies the SHA-256 hash chain (each agent's result_hash_sha256 referenced by the next). Identifies evidentiary gaps that downstream counsel will need to close. Scores chain integrity: clean (seal), minor-gap (seal with marker), major-gap (hold for human review). The Auditor's go-no-go gates the CREB™ seal - no auditor approval, no court-portable bundle.
Output contract: chain_integrity_findings[] + evidentiary_gaps[] + overall_severity: clean|minor|major + seal_decision: yes|hold. The seal decision is the last action before CourtChain™ anchoring.
Every agent run is bit-identically replayable.
Temperature 0. SHA-256-pinned system prompt. Cross-region inference profile for Bedrock capacity resilience. The ModelCard inside each AgentResult records the exact model id, the prompt hash, the AWS region, the input/output token counts. Two years from now, with the same model id available on Bedrock, the same prompt hash, and the same tokenized input, the call replays bit-identically. That replay capability is what makes the FRE 902(14) self-authentication claim hold up against a defense expert.
End-to-end orchestrator test on a demonstration case. The case passed through all six agent roles in canonical order in 295 seconds, and the CREB™ was sealed and anchored on CourtChain™.
One conductor. Many sections.
Detection is not one engine. It is anomaly scoring, pattern matching, entity resolution, sanctions and exclusion screening, and a set of vertical rule engines, each good at one thing and none of them able to decide what matters. AVA™ is the layer that reads across all of it and decides: what becomes a case, which specialists run, in what order, against which model, in which region, under which agreement. Below is what it conducts today, and what it is being built to conduct.
Conducted today
Shipping, and traceable end to end in the platform source.
- The coordination engine itself. Every agent implements one contract, whatever model or hardware is behind it. A registry binds each role to an implementation at run time from the customer's profile, and the orchestrator never knows which backend is live; changing backends is a configuration change, not a rewrite. This is the part of AVA™ that is genuinely hard, and it is built.
- The six-agent case pipeline. Investigator, Theorist, Adversary, Damages Quantifier, Drafter, with the Auditor as a hard gate. Sequenced by AVA™, not by a human picking tools, and each agent is handed what the agents before it concluded.
- Per-case model and region selection. One profile resolved once per case drives model, region, cost ceiling and the BAA gate for every downstream agent invocation.
- The fail-closed gate. If a case needs a cloud invocation and the Business Associate Addendum is not executed, AVA™ refuses to proceed rather than degrading quietly.
- Clustering detection findings into cases. Tier 1 findings arrive as thousands of separate signals; AVA™ groups them into the small number of things worth a human hour.
- Continuous RADV and shadow intelligence. Claims and clinical documents scored continuously against risk-adjustment exposure, in shadow by default so nothing touches payment. Internally this runs as its own service; to a customer it is AVA™, because it is.
- Replayable reasoning. Every agent run is hashed and bit-identically replayable, which is what makes the output evidence rather than output.
On the roadmap, not yet built
The target control plane. Stated as a direction, because none of it runs today and a page that blurs the two is worth less than one that says so.
- A public API to read from the products, never to drive them. Pull findings, cases, bundles and their verification state; integrate them into a customer's own systems. It will not accept a request to run an agent, start a case, or select a model. Reading what AVA™ produced and making AVA™ act are different powers, and only the first one is ever leaving the boundary.
- A single control plane over every detection engine. The vertical integrity engines run as independent services today and are reached directly. The intent is for AVA™ to front all of them.
On the open protocol question
JIL does not run a Model Context Protocol server, and that is a design decision rather than a gap. A tool-protocol server exists in order to be reached from outside: it is an ingress, and an ingress into the system that holds Protected Health Information is a thing to be justified, not assumed. AVA™'s coordination engine has no outside. No hostname routes to it, every route including reads is refused without an internal credential, and it is reachable only across the private service mesh. There is no external surface to authenticate, rate-limit, or defend, because there is no external surface.
What it does internally is the harder problem a tool protocol does not address: six specialist agents reaching many models, in an order that has to be reproducible, while a regulator's constraints hold at every hop. Those constraints travel with each invocation - a region the work is pinned to, an agreement that must be executed before the call is permitted at all, a cost ceiling, and a hash of the result chained to the hash before it. Strip them out and you have a way to call a tool. Keep them and you have an evidentiary record. The comparison people reach for is the wrong axis: the question is not which protocol coordinates agents, it is whether the coordinator is exposed at all.
Why the split is on the page at all. Everything on the left is in the platform source and can be traced by anyone who is given the repository. Everything on the right is a direction. Buyers in this market are sold roadmaps described as products constantly, and the fastest way to be believed about the first column is to be honest about the second.
What AVA™ does for you.
AVA™ is the AI layer that turns thousands of suspicious data points into a story a human can read, then (one tier up) into a court-ready evidence bundle a lawyer can file. The page below has the technical detail. This section is the short answer for non-technical readers.
If you're a fraud investigator
You give AVA™ a name, a network, or a payment stream. It reads the JIL detection findings and writes you a one-page memo that says 'here's what's happening, here's the evidence chain, here's where the holes are.' You can keep using the cheap stage to triage cases and only escalate the ones that look real to the next stage.
If you're general counsel or outside counsel
AVA™ runs five specialist AI agents in sequence (Investigator > Theorist > Adversary > Damages > Drafter) and stops at an Auditor agent that flags any gaps. You get a litigation-ready package: legal theory, controlling authority, anticipated defenses, damages methodology, draft memo. You review and sign; AVA™ does not file anything for you.
If you're an MCO SIU lead
Use AVA™ to convert your existing claim-flag pipeline into customer-readable case files. On the cases you decide to refer to the state Medicaid Fraud Control Unit (MFCU) or to outside counsel, AVA™ builds the CREB™ bundle to the FRE 902(14) authentication standard. We make no claim about what any state MFCU requires in a referral packet: ask yours.
If you're a CISO / compliance officer
All inference runs on Amazon Bedrock + SageMaker inside your AWS Business Associate Addendum coverage. PHI is tokenized via AWS KMS / CloudHSM before reaching any model. Every model call is logged to CloudTrail + anchored to JIL's CourtChain™ audit ledger. The pipeline is bit-identically replayable two years later for an OCR audit.
If you're a CFO
AVA™ is included with the engagement. Billed events are the tiers: Tier 1 (flat-fee scan), Tier 2 (paid substantiation), Tier 3 (CREB™ production). You decide per case which billed tier to authorize. There is no separate AVA™ Pro line item.
If you're a state MFCU or referring agency
The CREB™ bundle AVA™ produces is designed to satisfy FRE 902(14) for self-authenticating electronic records. A court-appointed expert can verify the chain of custody and the cryptographic signatures from the bundle itself, and 902(14) lets authenticity be established by a written certification from a qualified person rather than live JIL testimony at trial. We have no data on state MFCU intake practice and make no claim about it: tell us what your unit requires and we will show you where the bundle meets it. Sample bundle at /samples/verdict-record.
What we mean by Agentic AI.
"Agentic AI" is one of the most overloaded terms in 2026. Vendors use it for everything from chatbots to autoscaling scripts. Here is what it means inside JIL Sovereign, precisely.
Agents are role-specialized AI workers that act in sequence over a goal, each producing a structured artifact the next consumes, with every step auditable.
Three properties, all required:
- Role-specialized. Not one mega-prompt. Each agent has a single narrow job (find evidence; map it to a statute; red-team the case; quantify damages; draft the memo; audit the chain). The prompt is locked + hashed; the output schema is rigid.
- Sequential, coordinated. Agents run in a fixed canonical order. Each agent's output becomes the next agent's input. The orchestrator is plain code, not another LLM - no LLM-coordinating-LLMs hand-waving. Failure or low confidence on any agent halts the pipeline.
- Auditable. Every agent invocation produces a SHA-256-hashed reasoning chain, anchored to JIL's CourtChain™ audit ledger before the next agent starts. The whole pipeline is bit-identically replayable two years later.
If a system is missing any of these three, it's not what JIL means by Agentic AI - it's an LLM with a label.
Agentic AI is not a chatbot, not RAG, not "AI tools".
To draw the line cleanly:
- Not a chatbot. No human in the loop sending free-form messages mid-pipeline. Each agent runs once per case, takes a structured input, returns a structured output, and exits.
- Not just RAG. Retrieval-augmented generation is one technique an agent uses (the Theorist retrieves controlling case law from the legal corpus). But "RAG" alone - one LLM + one vector store - is not agentic. Agentic adds role specialization + cross-checking + audit anchoring on top.
- Not "AI tools" or "AI features". Agentic means the AI drives the workflow - it decides which legal theories to propose, which defenses to anticipate, which damages methodology to recommend. A human counsel reviews; the AI doesn't wait for instructions at each step.
- Not autonomous. The Auditor agent is a hard gate. If it flags a "blocker" gap, the bundle does not seal. A human reviewer must clear the gap before AVA™ produces the filing-ready CREB™.
Models JIL uses today (Phase 2, live)
| Agent role | Model | Provider / hosting | Why this model | Stage status |
|---|---|---|---|---|
| Investigator | Anthropic Claude Sonnet 4.6 | Amazon Bedrock us.anthropic.claude-sonnet-4-6 |
Heavyweight reasoning over claim sweep + pattern recognition; strong at structured extraction across long inputs | LIVE on Bedrock |
| Theorist | Anthropic Claude Sonnet 4.6 | Amazon Bedrock us.anthropic.claude-sonnet-4-6 |
Statutory-element decomposition, controlling-authority citation, no-hallucination reasoning | LIVE on Bedrock |
| Adversary | Llama 4 / DeepSeek R1 class with LoRA | Amazon SageMaker (G6 / P5 / P4 GPU) + LoRA adapter per case theory (FCA, AKS / Stark, ERISA, RICO, MFCU) | Red-team / defense anticipation needs adapter-driven specialization beyond what general-purpose models can offer | Phase 3 (stub today) |
| Damages Quantifier | Llama 4 / DeepSeek R1 class with LoRA + SageMaker XGBoost | Amazon SageMaker GPU + SageMaker built-in XGBoost | Multi-methodology damages calculations need both reasoning (LLM) and quantitative anomaly detection (XGBoost) | Phase 3 (stub today) |
| Drafter | Anthropic Claude Haiku 4.5 | Amazon Bedrock us.anthropic.claude-haiku-4-5-20251001-v1:0 |
Long-form generation (memo + CREB™ structure); roughly 3x cheaper per unit of output than Sonnet | LIVE on Bedrock |
| Auditor | Anthropic Claude Haiku 4.5 | Amazon Bedrock us.anthropic.claude-haiku-4-5-20251001-v1:0 |
Structured gap-finding + chain-integrity walk; cost-efficient for the audit pass | LIVE on Bedrock |
Supporting AWS services (Phase 2/3)
Cross-region inference profiles
Bedrock invocations route through the us.* cross-region inference profile, distributing capacity across us-east-1, us-east-2, and us-west-2. If one region throttles, the next call lands elsewhere without code change. PHI residency stays US-only by published region scope + IAM Service Control Policy.
Bedrock Knowledge Bases + OpenSearch Serverless
Theorist and Auditor agents pull controlling case law from a managed RAG store backed by Amazon Bedrock Knowledge Bases over Amazon OpenSearch Serverless, with embeddings from Amazon Titan Text Embeddings v2. Corpus: Harvard CAP, CourtListener federal opinions, PACER bulk filings, CMS regulations, HHS OIG advisory opinions, DOJ FCA settlement library, state MFCU precedent.
Step Functions, EventBridge, SQS, CloudTrail, KMS
AWS Step Functions orchestrates the six-agent state machine. EventBridge fans agent-completed events to downstream consumers (CourtChain™ anchor, billing, customer notifications). SQS queues batch case intake. CloudTrail logs every Bedrock invocation (input + output hashes only, never content) to S3 with Object Lock immutability. AWS KMS / CloudHSM hold the per-tenant PHI tokenization vault keys.
One pipeline. Three lock-in points. One audit chain.
Each stage carries a distinct analytical scope, AWS compute target, and PHI handling regime. The customer chooses where to stop.
AVA™ · on Amazon Bedrock
148 deterministic rule checks across 16 categories. AVA™ consumes Tier 1 flagged claims from the JIL evidence record, groups related flags into coherent finding clusters, and produces customer-readable summaries. Inference runs on Amazon Bedrock managed APIs - no GPU provisioning, per-unit pricing aligned to query volume. JIL retains the right to swap or add Bedrock-hosted models without architectural change; the system prompt + JSON-output contract is portable across Anthropic Claude families. Bedrock contractually does not retain customer prompts or use them for model improvement.
AVA™ · Six specialized agents on Bedrock
Six specialized agent roles, each with a distinct prompt + JSON output contract. Today four are wired to Amazon Bedrock via cross-region inference profiles for capacity-based resilience: Investigator + Theorist on Anthropic Claude Sonnet 4.6 (heavyweight reasoning, legal-element decomposition, statutory mapping); Drafter + Auditor on Anthropic Claude Haiku 4.5 (long-form generation, evidentiary-gap structured analysis, ~3x cheaper per output token). The remaining two roles - Adversary (red-team / defense anticipation) and Damages Quantifier (multi-methodology damages with statistical confidence intervals) - run on Amazon SageMaker self-hosted inference with LoRA adapters per case theory (FCA, Anti-Kickback / Stark, ERISA, civil RICO, state insurance fraud, MFCU referral); Phase 3.
AVA™ · Filing-ready CREB™
Final lock-down. Filing-ready bundles for counsel. AVA™ produces filing-ready CREB™ packages for customer counsel or referral agencies. Every agent reasoning chain is hashed and anchored to CourtChain™ via AWS CloudTrail + CloudWatch event hooks; the resulting evidence bundle is FRE 902(14) self-authenticating. Damages calculations carry methodology variance + 95% confidence intervals (SageMaker XGBoost for time-series anomaly base rates). The Auditor agent walks the prior five agents' chain integrity before the bundle is sealed; if any gap rises above "minor" severity, the bundle is held for human review.
Six agents, one chain, every reasoning step hashed.
Most "AI in healthcare" today means a single LLM behind a chat box. AVA™ is the opposite. Each role is a separately-prompted agent with its own output contract, its own model assignment, its own evidence trail. The orchestrator runs them in canonical order, anchors each result to CourtChain™ before the next agent starts, and stops at the Auditor's go/no-go.
Specialization beats prompt-stuffing
One mega-prompt asking a single LLM to "find fraud, propose theories, anticipate defenses, calculate damages, draft the memo, audit the chain" produces hand-wavy aggregates. Six narrow prompts, each constrained to a single output schema, produce auditable structured artifacts that downstream tooling can verify. Each agent's output is the next agent's input - no agent sees the customer's raw claim universe, only the prior agent's structured findings + the legal corpus.
Temperature 0, fixed prompts, replayable
Every agent invocation runs at temperature: 0 with a SHA-256-pinned system prompt. The ModelCard inside each AgentResult records the exact model id, the prompt hash, the AWS region, the input/output token counts. Two years from now, with the same model id available on Bedrock, the same prompt hash, and the same tokenized input, the call replays bit-identically. That replay capability is what makes the FRE 902(14) self-authentication claim hold up against a defense expert.
Right tool, right cost, per agent
The Investigator and Theorist do most of the legal-reasoning work. They get the heavier reasoning model. The Drafter and Auditor do generation and structured-gap analysis, and get a smaller model sized to that task. We can swap a single role to a different model without touching the rest of the pipeline.
Each customer carries its own posture
Inference mode, AWS region, model overrides, KMS key, BAA timestamp, and cost cap are all per-tenant - not process-global. In production, AVA™ runs inside the customer's own Snowflake account (Native App or Snowpark Container Services), so the customer's chosen region governs where data rests. A JIL-hosted deployment on JIL Cloud (AWS EKS) is a reference architecture that is not yet provisioned; it targets AWS us-east-1 when built. AWS GovCloud (US-West) for federal customers is on the roadmap and is not available today. AI analysis runs only after a BAA is executed; until a signed BAA is in place, the orchestrator gates Bedrock invocation to protect customer data boundaries. Each case has a hard cost ceiling beyond which the orchestrator aborts and surfaces a partial CREB™ with the cost-cap marker.
Bedrock routes across us-east-1 + us-east-2 + us-west-2
JIL invokes Bedrock through the us.* cross-region inference profile - a managed router that distributes capacity across three US regions. If one region throttles, the next call lands somewhere else without code change. The IAM policy authorizes invocation in each of the three regions plus the inference profile itself. PHI residency stays US-only by Service Control Policy + the inference profile's published region scope.
One anchor, two regulatory regimes
Each agent run's output hash is anchored to JIL's CourtChain™ (the tamper-evident audit ledger). The same anchor satisfies HIPAA Security Rule audit-log integrity (45 CFR §164.312(b)) and FRE 902(14) self-authentication for evidentiary admissibility. CloudTrail logs land in S3 with Object Lock so they're immutable before the chain hash is computed. One mechanism, two compliance frameworks - no parallel audit infrastructure to maintain.
PHI is on a tightly bounded path. Everything else flows.
JIL's runtime touches three classes of data - PHI (HIPAA Safe Harbor identifiers), PII (employee credentials, contact records), and non-PHI operational data (pattern signatures, model weights, legal corpus, CourtChain™ anchors). The architectural goal is to keep PHI on a tightly bounded path inside the JIL AWS tenant and let everything else flow freely through the analytical layer.
Minimum necessary, tokenized at boundary
AVA™ processes only the PHI required for the analytical task. PHI identifiers are replaced with format-preserving tokens (FF3-1 / FPE-AES per identifier class) at the JIL ingest boundary. Tokenization runs in AWS Lambda or ECS within the customer-tenant VPC. The crosswalk lives in AWS KMS with customer master keys (CMK), with AWS CloudHSM (FIPS 140-2 Level 3 validated) for the highest-sensitivity workloads. Re-identification happens only at the customer-facing CREB™ output boundary.
No PHI in model training
Foundation models are inference-only on customer data. No customer PHI is used for fine-tuning, weight updates, RLHF, or any training process. AWS Bedrock contractually does not retain or use customer prompts for model improvement. Continued pre-training and supervised fine-tuning happen on the (PHI-free) legal corpus only, on SageMaker training jobs.
Ephemeral inference
Bedrock invocations are stateless by contract. SageMaker KV caches are cleared between sessions. No persistent storage of customer prompts in inference infrastructure. Logs capture input and output hashes only via CloudTrail + CloudWatch - never content. Every PHI access is logged and anchored to CourtChain™.
No external API egress beyond AWS
All inference happens within JIL's AWS account boundary, under the AWS Business Associate Addendum. No data flows to OpenAI, Google, or any non-AWS LLM service. Bedrock keeps customer data within the JIL AWS tenant and does not share with third-party model providers. VPC endpoints + VPC-only routing for Bedrock and SageMaker invocations.
PHI residency
Production PHI belongs in a BAA-covered environment the customer controls: their own Snowflake account, or AWS commercial regions (us-east-1, us-east-2, us-west-2) under an executed BAA. JIL's demonstration and evidence-sealing hosts are in the EU and are not under a BAA, so they do not accept customer PHI. AWS GovCloud (US-West) for federal and CMS workloads is a roadmap item, not a current deployment.
Immutable audit, dual-purpose anchoring
Every PHI access is logged via AWS CloudTrail and CloudWatch Logs, then anchored to CourtChain™. The same anchor that supports FRE 902(14) admissibility also satisfies HIPAA Security Rule audit log integrity (45 CFR 164.312(b)). One mechanism, two regulatory regimes. CloudTrail logs are themselves immutable (S3 Object Lock + bucket policies that deny delete) before the CourtChain™ hash is computed.
Three deployment paths. Customer chooses where the PHI sits.
Same Verdict Engine. Same FRE 902(14) admissibility. Same CourtChain™ seal. The substrate is the lever: Snowflake or Databricks for the fastest path to production (inherit their compliance posture), JIL Cloud for federal / sovereign workloads requiring maximum operational control. Customer data never leaves the customer perimeter in any of the three paths; AVA™ runs inside the chosen substrate.
AVA™ on Snowpark Container Services
AVA™ deploys as a Snowflake Native App inside the customer's Snowflake account. PHI never leaves the customer's Snowflake perimeter. Inherits Snowflake's certified compliance posture: HITRUST CSF, SOC 2 Type II, ISO 27001, HIPAA, FedRAMP MOD, PCI DSS. Fastest path to production for customers already standardized on Snowflake Financial Services Data Cloud. See Snowflake reference architecture + TDD.
AVA™ on Databricks Apps
AVA™ deploys as a Databricks App inside the customer's Databricks workspace. Delta Lake substrate, Unity Catalog governance, Photon query engine. Best fit for lakehouse-native, ML-heavy customers running Unity Catalog. Same HITRUST + SOC 2 + ISO 27001 + HIPAA inheritance as the Snowflake path. PHI stays inside the customer's Databricks environment.
AVA™ on JIL Cloud (AWS EKS, not yet provisioned)
A designed option, not available today: direct AVA™ deployment on JIL Cloud (Amazon EKS + KMS + IAM + GuardDuty) in AWS commercial regions, customer VPC or peered. The EKS environment is not yet provisioned, so this option cannot be contracted until it is built. A GovCloud (US-West) variant for federal / CMS workloads is on the roadmap; no GovCloud account is in service today, so no FedRAMP High inheritance is claimed. When built, it is aimed at heterogeneous estates and institutions requiring maximum operational control. See JIL Cloud reference architecture.
Pre-built responses for every common questionnaire.
Customer security review teams typically resolve in 4 to 8 weeks once a questionnaire is submitted. The shift to AWS Bedrock + SageMaker materially shortens the review window because most infrastructure-layer controls are inheritable from AWS's existing certifications.
Pre-built response library
- Whistic
- OneTrust Vendorpedia
- ProcessUnity
- KY3P (Hitachi)
- SIG Lite and SIG Core
- HITRUST MyCSF
Response library updated quarterly. Customer-specific overlays handled at intake.
What you get on day one of review
- SOC 2 control mapping for Security, Availability and Confidentiality. No audit firm is engaged, so no report exists
- HITRUST CSF i1 control mapping, self-assessed. No authorized external assessor is engaged, so no certification exists
- HIPAA Security Rule attestation
- AWS Business Associate Addendum evidence
- FedRAMP inheritance documentation for the AWS commercial services used (Bedrock, SageMaker). No GovCloud account is in service, so no FedRAMP High inheritance is claimed
- Self-conducted vulnerability assessment, refreshed quarterly. No third-party penetration test has been performed, so there is no report
- Architecture review materials, data flow diagrams
- BAA template and signature workflow
Begin a security review.
Customer security teams open conversations with JIL by requesting a briefing. We will share the full reference architecture under NDA and walk the BAA structure, deployment-mode trade-offs, AWS service inventory, and PHI handling principles in depth.