Technical assurance, security posture, and operational evidence
JIL publishes architecture documentation, security models, performance benchmarks, operational evidence, and governance boundaries. Every claim is mapped to artifacts. Every gap is disclosed. Select an assurance domain below to verify directly.
Architecture Assurance
Data architecture, trust assumptions, and system boundary documentation
System Trust Assumptions
Every security system makes trust assumptions. JIL documents what the system trusts, what it verifies, what it cannot prevent, and where residual risk exists.
- 5 core trust domains documented
- Cryptographic assumptions and boundaries
- Known limitations transparently disclosed
Trust Boundary Diagram
Visual mapping of trust boundaries across 6 layers - from user-facing applications through the evidence protocol to JIL-operated attestation infrastructure.
- 6 trust boundary layers visualized
- Data flow and authentication boundaries
- External system integration points
Data Architecture
JIL never stores customer data at rest. Customer-owned AWS S3 and Snowflake share, with a JIL-operated signing record and external RFC 3161 timestamps. The customer holds the record. A subpoena for the evidence goes to the customer, who controls disclosure.
- Zero customer data at rest in JIL infrastructure
- Customer-owned AWS S3 with Apache Iceberg
- Built to support FRE 902(13) and 902(14) self-authentication
Security Assurance
Threat models, security invariants, controls, and identity verification
Adversarial Threat Model
Structured threat analysis covering 4 adversary categories, 5 attack surfaces, signing and infrastructure attack scenarios, and residual risk assessment.
- 4 adversary categories with capability analysis
- 5 attack surfaces with mitigations
- Residual risks transparently disclosed
Security Invariants
Properties that must always hold true regardless of system state, with failure detection mechanisms.
- 7 invariant categories defined
- Automated violation detection
- Failure response procedures
Security Controls
Security architecture is published, not hidden. Evaluate the threat model, key management, authorization design, and data boundaries directly.
- Threat model summary
- Key management model
- Authorization lanes and data boundaries
Identity Verification
BID performs exhaustive identity verification. Five check categories, seven vendor integrations, fail-safe architecture.
- Phone, email, address, person, company checks
- 7 vendor integrations
- Fail-safe architecture
Performance Assurance
Test results and institutional-grade evidence packs
Operational Assurance
Resilience, infrastructure, and verification services documentation
Operational Resilience
Resilience philosophy, signing-node fault tolerance, partition handling, infrastructure design, monitoring architecture, and disaster recovery procedures.
- Signing-node failure tolerance model
- Network partition handling
- Incident response and disaster recovery
Platform Infrastructure
Every component documented. 350+ production services, 18 API specifications, 177 patent claims filed, 22 technical specs.
- 18 API specs linked
- 177 patent claims (filed) indexed
Verification Services
12 real-time verification services - OFAC sanctions screening, address validation, email/phone verification, PEP screening, fraud detection, velocity monitoring, and continuous re-screening.
- 12 verification services with live data sources
- OFAC SDN, FATF, OIG LEIE, GLEIF, SEC EDGAR
- 24-hour continuous re-screening cycle
Compliance Certification Report
512M+ certified test cases across 12 frameworks - SOC 2 Trust Service Criteria, NIST CSF 2.0, OWASP API Security, FIPS 140-3, formal verification, sustained-load stress testing, and cross-jurisdiction compliance. 99.70% pass rate.
- SOC 2 control mapping: Security, Availability, Confidentiality
- 512M+ tests, 99.70% pass, 12 frameworks
- 10 policy zones configured in software; all signing nodes JIL-operated
Governance and Claims
Policy evaluation, scope boundaries, and institutional readiness
Policy Evaluation
Policies are versioned, hashed, and enforced in software. Every policy decision is recorded as evidence.
- Policy configuration
- Enforcement evidence mapping
- Policy versioning and hashing
Scope and Boundaries
Clarity about what JIL does and does not do is itself a form of proof. Institutional counterparties deserve precise scope boundaries.
- What JIL does - 4 core capabilities
- What JIL does not do - clear exclusions
- Key handling stated plainly
Institutional Readiness
Everything an institutional counterparty needs to evaluate, integrate, and deploy JIL.
- Integration checklist
- POC plan (2 to 4 weeks)
- Compliance review packet
Where your data actually sits
The question every risk committee asks first. Payload data never leaves your perimeter. Evaluation happens in memory. Only a hash and a pass/fail attestation are ever written to the evidence record - so there is no second copy of your members, claims, or payment files to govern, breach, or subpoena.
Payload data stays here
Claims, member records, payment files and PHI remain inside your own cloud, data centre or Snowflake tenant. The engine deploys to the data through a read-only adapter. Nothing is uploaded to JIL.
- Read-only adapter, no export
- Your keys, your region, your retention
- No BAA dependency for the data plane
332 checks evaluate in RAM
Every rule runs against the record in ephemeral memory. Nothing is written to disk, cached in a sidecar, or retained in an error bucket. When the evaluation ends, the working copy is gone.
- Ephemeral, nothing persisted
- Deterministic rules, reproducible result
- Payload redaction enforced in CI
A SHA-256 hash and a verdict
What gets recorded to CourtChain™ is a cryptographic digest, the pass/fail result, the rule version, and the time. Never the underlying record. The digest proves the record existed and was unaltered; it cannot reconstruct it.
- SHA-256 digest, not content
- Ed25519 + ML-DSA-65 hybrid seal
- RFC 3161 trusted timestamp
Why this matters to a CCO: because JIL holds no customer data at rest, a JIL incident cannot become your breach notification. The scope of what an auditor has to examine at JIL is the verdict record, not your book of business.
Stopping it beats chasing it
Post-payment recovery is the industry default, and it is structurally lossy: by the time an audit lands, the money has been spent, the provider may be gone, and every dollar back costs legal and administrative effort. Pre-payment interdiction avoids the loss instead of financing its recovery.
Pay, then chase
- When you find out
- Months to years after the payment cleared
- What you recover
- A fraction of the identified overpayment
- What it costs
- Audit staff, legal fees, appeals, contingency vendors
- Provider relationship
- Adversarial - clawbacks land after the money is spent
- Evidence
- Reconstructed after the fact from surviving records
Decide before it moves
- When you find out
- Before the payment leaves, inside the authorization window
- What you recover
- Nothing to recover - the improper payment never goes out
- What it costs
- A per-event fee, no contingency share of your own money
- Provider relationship
- A pend or a request for documentation, not a clawback letter
- Evidence
- Contemporaneous and sealed at the moment of decision
Rules that fire before the money moves
Payment-integrity teams do not buy "signal categories" - they buy specific enforcement. These are evaluated pre-settlement, with the reasoning sealed into the record:
Hospice recertification and face-to-face
Verifies the certifying physician encounter exists and is timely relative to the benefit period before the claim is disbursed, rather than discovering the missing attestation during a post-pay review.
Correct-coding edits
Catches unbundled procedure pairs and modifier misuse at authorization time, where the correction is a pend rather than a recoupment.
Unit-count ceilings
Caps implausible unit counts before payment, the single highest-volume category of routine overpayment.
Excluded and deactivated parties
Screens the rendering and billing party against exclusion, debarment and sanctions sources refreshed daily - LEIE, SAM, OFAC and the state lists - with the source version pinned into the evidence.
Rule coverage is configured per programme and per contract. Ask for the check inventory that applies to your lines of business.
What counsel actually receives
Not a report. A sealed Court Ready Evidence Bundle, built for self-authentication under Federal Rule of Evidence 902(14) and independently verifiable by the other side from the bundle itself. 902(14) does require a written certification from a qualified person comparing hash values; the bundle carries that declaration pre-filled with its Merkle root and identifiers, for the designated custodian to execute. What 902(14) removes is live foundation testimony, not the declaration and not JIL's participation.
- Identifiers and retentionReport and attestation IDs, content hash, storage locator, retention period, retrieval index
- Subject of verdictThe party, the instrument, the purpose code, the latency budget
- Test profile appliedNamed profile and version, compliance-officer sign-off, jurisdictions enforced
- Data sources with attestation certificatesEach source, its certificate ID, last refresh and update cadence - pinned, not "as of today"
- Test-by-test result matrixEvery check by ID: method, source, result, and an evidence digest, rolled to a Merkle root
- Final verdictYes, no, or review - with confidence and reason codes
- Cryptographic seal and anchorEd25519 + ML-DSA-65 hybrid signature, multi-party confirmation across named jurisdictions, CourtChain™ reference, RFC 3161 timestamp token, Merkle root, QR verification code
- Chain of custodyMicrosecond-precision event log from request through sealed delivery
- Authorized evidentiary usesThe rules and reporting regimes the bundle is built to support
Why this matters to a relator's counsel
The hard element in a False Claims Act case is rarely the falsity. It is knowledge - showing the defendant knew, or recklessly disregarded, that the claim was false at the moment it was submitted. That is normally reconstructed years later from depositions and document production.
A pre-settlement attestation inverts the problem. When a payer or provider runs a payment through JIL and the engine returns a flag, that flag is recorded contemporaneously - with the rule that fired, the data source and version behind it, and a trusted timestamp - and sealed so it cannot be quietly revised later. Paying anyway creates a contemporaneous record of exactly what was known, at the millisecond it was known.
JIL produces evidence; it does not offer legal advice or opine on any element of a claim. Whether a given record supports scienter under 31 U.S.C. § 3729 is a question for counsel.
Compliance status, stated plainly
Certifications are either held or they are not. Below is where each one actually stands - so your vendor-risk team can rely on it rather than discover otherwise in diligence.
PHI stays in your tenant
The strongest control we have is structural, not contractual: JIL holds no customer data at rest, so the data plane does not depend on any third-party agreement being in place.
SOC 2 Type II
The control mapping is complete for the Security, Availability and Confidentiality Trust Services Criteria. No audit firm is engaged and no observation window has started, so there is no report and no bridge letter. We will name the firm on the day we sign, and publish the report when the auditor issues it, and not before.
HITRUST CSF i1, ISO 27001 / 27017
Scoped and sequenced behind SOC 2, which shares most of the evidence base. No certificate is claimed until an assessor issues one.
Business Associate Agreements
A BAA with the data substrate your deployment runs on is a standard form we complete as part of contracting - not a negotiation and not a gate on your timeline. Because evaluation happens inside your own tenant, your PHI is handled correctly by the architecture regardless.
Who operates the nodes
JIL Sovereign Technologies operates every attestation node - named, and one company operates every node and answers for the result. We do not describe them as independent third-party operators, because they are not.
Diligence pack
Architecture documentation, data-flow and retention mapping, encryption policy, sub-processor list and incident-response summary, provided under NDA for vendor-risk review.
Security Review Roadmap
Production rollout is gated by completion of the independent security audit. Institutional onboarding during pilot phase operates under sandbox conditions.
Start where you sit
Different seats need different first steps. Pick the one that matches your role and we will send the material that answers your questions, not a generic overview.