How is this different from a general in-tenant compliance deployment?

This claim is scoped specifically to provider-record audit workflows: a lightweight connector that reads a provider's own records incrementally, rather than the broader class of settlement pre-clearance or general tenant-isolation deployments covered elsewhere in the portfolio.

What does 'incremental by watermark and column projection' mean?

The connector tracks a persisted watermark (a bookmark of the last record processed) so each run reads only new or changed records, and restricts the columns it retrieves to those a given check actually needs - rather than pulling a full-table extract of the provider's records.

What leaves the provider's network boundary?

Only sealed, de-identified and tokenized evaluation results, transmitted outbound-only. The connector's egress channel has no corresponding inbound data path for cleartext records, and the control plane receiving those results has no PHI ever come to rest inside it.

How does a third party verify an audit result?

By checking the cryptographic seal together with the provider's own retained record - nothing at the control plane's infrastructure is required for verification, since the control plane never held the underlying record in the first place.

Proof-Without-Custody Client-Resident Audit Edge

Executive Summary

Provider-side compliance and documentation-integrity audits conventionally require the provider to export a large slice of their patient record system to a vendor's cloud for analysis. JIL Sovereign's client-resident audit edge instead deploys a lightweight connector inside the provider's own network boundary that reads records incrementally - tracking a persisted watermark and projecting only the columns a given check requires - evaluates the compliance-check catalog locally, and de-identifies, tokenizes, and cryptographically seals the results before anything leaves the provider's environment. The transmission channel out of the provider's boundary is outbound-only: sealed, de-identified results go out; nothing resembling a bulk record extract ever does.

This is a distinct embodiment, scoped specifically to provider-record audit workflows, from JIL Sovereign's broader client-perimeter edge/cloud-split architecture used for settlement pre-clearance: the defining property here is the minimal-footprint incremental read pattern (watermark plus column projection) applied to an audit connector, not the general non-exportable tokenization-key architecture used elsewhere in the portfolio.

Core Innovation: A client-resident connector performing minimal-footprint incremental reads (watermark plus column projection) of provider records, evaluating checks and sealing de-identified results locally, and emitting only outbound-only sealed output - so the control plane is structurally incapable of holding PHI at rest.

Problem Statement

Traditional compliance-audit SaaS products ask a healthcare provider to export patient records - often full-table extracts - to the vendor's cloud for processing, which drives long data-use-agreement negotiations, large PHI transfer footprints, and a persistent question of what the vendor retains and for how long. Even vendors who advertise an "in-tenant" or "on-prem" deployment model frequently still pull broad, non-incremental extracts rather than reading only the specific records and fields a given audit check actually needs.

Egress direction enforced by the connector - outbound only

PHI bytes retained at the control plane

Inputs needed to verify any output: the seal and the provider's own record

Why Full-Extract Audit Models Fall Short

SaaS compliance vendor with full-extract export: the provider's records leave the provider's network entirely, creating the largest possible PHI transfer surface.
On-prem vendor appliance: data may stay local, but the appliance's internal behavior and update cadence are vendor-controlled and not independently verifiable by the provider.
Customer-hosted vendor Docker image without incremental reads: data stays local, but a full-table pull on every run is unnecessarily broad and slower to reconcile against a watermark-based audit trail.
Batch nightly ETL to a vendor warehouse: reintroduces an at-rest PHI copy outside the provider's own systems, even if encrypted.

Technical Architecture

Edge Connector Pipeline

Stage	What Happens
1. Incremental read	Connector reads only records newer than its persisted watermark, using a column-projection filter limited to fields the active check catalog requires
2. Local evaluation	The compliance-check catalog is applied to the retrieved records entirely inside the provider's network boundary
3. De-identify / tokenize	Any identifying content in the evaluation results is removed or tokenized before leaving local memory
4. Seal	The de-identified results are cryptographically sealed, binding the output to a verifiable receipt
5. Outbound-only emit	Only the sealed, de-identified results are transmitted to the remote control plane; the channel has no corresponding path for inbound bulk-record retrieval

Watermark-and-Projection Read Pattern

Rather than treating "in-tenant" as sufficient on its own, the connector's read pattern is itself minimized: a persisted watermark bounds each run to newly-arrived or newly-changed records, and column projection further bounds each read to only the fields a specific check actually consumes. Together these mean the connector's footprint inside the provider's own systems scales with audit activity, not with the size of the underlying patient population.

Structural Zero-Retention at the Control Plane

Because the outbound channel carries only sealed, de-identified results, the remote control plane has no code path capable of receiving or storing cleartext PHI - the guarantee is architectural, not a retention policy the vendor commits to and could later violate.

Independent Verification

A party wishing to verify an emitted audit result - for example, an auditor reviewing a documentation-integrity finding - needs only the seal and access to the provider's own retained record; the control plane's infrastructure is not part of the verification path at all, since it never held the underlying record.

Prior Art Differentiation

Approach	Data Leaving the Provider	Read Pattern	Control-Plane PHI Exposure
SaaS vendor, full-extract export	Full patient record extracts	Bulk, non-incremental	Full copy resident at vendor
On-prem vendor appliance	None (data stays local)	Vendor-controlled, not independently verifiable	Unknown/unverifiable
Customer-hosted Docker image, full-table pulls	None	Bulk, non-incremental	None, but inefficient
JIL Sovereign client-resident audit edge	Sealed, de-identified results only	Incremental: watermark + column projection	Structurally zero - no code path receives PHI

Patent Claim

Independent Claim 48: A computer-implemented system for auditing provider records without centralized custody of protected health information, comprising: a client-resident connector deployed inside a healthcare provider's own network boundary, configured to read provider records incrementally using a persisted watermark and a column-projection filter limiting retrieved fields to those required for compliance evaluation; a local evaluation module that applies a compliance-check catalog to the incrementally-retrieved records entirely within the provider's network boundary; a de-identification and tokenization module that removes or tokenizes protected health information from evaluation results before any data leaves the provider's network boundary; a sealing module that cryptographically seals the de-identified evaluation results; and an outbound-only transmission channel that emits only the sealed, de-identified results to a remote control plane, the control plane being structurally incapable of receiving or storing cleartext protected health information; wherein a party verifying any emitted result requires only the seal and access to the provider's own retained record, without requiring access to the control plane's infrastructure.