What is the allegiance firewall in JIL's evidence-bundle architecture?

It is a data-access-layer control that binds an immutable 'allegiance' tag (provider or payer) to every engagement at creation. Any request against the payer-facing (PIEB) code path is evaluated against that tag and denied by default unless the tag matches - so a provider-side engagement's data is structurally unreachable through the payer-facing path regardless of application logic, operator action, or credential compromise.

What are AREB and PIEB?

AREB (Audit-Ready Evidence Bundle) is the provider-facing product: it helps a provider substantiate and defend claims under audit. PIEB (Payment Integrity Evidence Bundle) is the payer-facing product: it helps a payer identify and build a recovery case against improperly paid claims. Both run against the same underlying check canon and verdict engine.

How is this different from an organizational information wall?

A traditional information wall is a policy or contractual control - staff are instructed not to cross it, but nothing in the software itself prevents a mistake or a compromised credential from doing so. JIL's allegiance firewall is enforced in code, upstream of business logic, at the point where a query resolves data: a mismatched allegiance tag returns zero rows regardless of what the calling application intended.

Does this claim make clinical determinations about patients?

No. The claim describes a software data-access and evidence-generation architecture only - which checks ran, which party may read which output, and how that access is enforced. It makes no clinical or diagnostic determination.

Bi-Directional Neutral-Evidence Network with Architectural Allegiance Firewall

Executive Summary

JIL Sovereign's attestation engine evaluates a single canonical set of compliance checks - a shared 332-check canon - against a common body of claims data. That one engine feeds two separately branded, adversarial evidence products: the Audit-Ready Evidence Bundle (AREB), used by a provider to substantiate and defend its own billing under audit, and the Payment Integrity Evidence Bundle (PIEB), used by a payer to build a recovery case against improperly paid claims from that same provider.

Running one canon in both directions removes the interpretive disputes that arise when a provider's compliance vendor and a payer's recovery contractor apply different rule logic to the same regulation. But it also creates an obvious conflict-of-interest exposure: a single engine serving both sides could, through misconfiguration, a bad query, or a compromised credential, leak one client's audit-defense data into another client's recovery case. JIL's answer is architectural rather than procedural - an immutable "allegiance" tag on every engagement, enforced at the data-access layer itself, so that a mismatched read is denied by construction before any application-layer logic ever runs.

Core Innovation: A single verdict engine and check canon serves two adversarial evidence products over the same claims data, with the provider/payer separation enforced by a fail-closed, deny-by-default check in the data-access layer - not by policy, contract, or organizational trust.

Problem Statement

In healthcare payment integrity, the parties auditing a provider (payers, recovery-audit contractors, special investigations units) and the parties defending that same provider (compliance vendors, revenue-cycle teams) traditionally run separate rule engines, built by different vendors, applying different interpretations of the same regulations and payer policies to the same claims. The result is not just duplicated engineering effort - it is a structural source of disputes that are really about whose interpretation of a rule is correct, not about the underlying facts of a claim.

Consolidating both sides onto one canon removes that disagreement, but a single vendor serving both provider and payer clients on shared infrastructure introduces an obvious risk: what stops that vendor's payer-facing product from reading a provider client's audit-defense data, intentionally or by accident? The conventional answer - information walls, non-disclosure agreements, separate legal entities, staff training - is a trust-based control. It relies on every engineer, every query, and every operator getting it right, every time, forever, and it fails silently when they don't.

332

Checks in the shared compliance canon

Adversarial product lines served by one engine

Cross-allegiance reads possible by construction

Why Existing Approaches Are Insufficient

Single-directional claims-editing engines: Payer-side claims-editing and SIU platforms are built exclusively for the payer's recovery use case; they have no provider-facing defense mode and no shared canon to keep interpretations aligned.
Single-directional compliance vendors: Provider-facing compliance and revenue-cycle vendors are built exclusively for audit defense; they have no payer-facing recovery mode.
Organizational information walls: Policy-based separation (staff training, contractual NDAs, "Chinese wall" attestations) constrains people, not code - a misconfigured query or a compromised account can still cross it.
Separate legal entities running duplicate engines: Eliminates the conflict but reintroduces the original problem: two independently maintained rule sets that can silently drift apart in their interpretation of the same regulation.

Technical Architecture

Shared Canon, Divergent Output Roles

A single verdict engine evaluates the 332-check canon against ingested claims data and produces a neutral set of check results. Two independent bundle generators consume that same result set and package it for opposite purposes.

Module	Role	Consumer	Output
`areb-modules.ts`	Provider-facing substantiation	Provider / provider's counsel	Audit-Ready Evidence Bundle (AREB)
`pieb-modules.ts`	Payer-facing recovery	Payer / recovery contractor	Payment Integrity Evidence Bundle (PIEB)

Allegiance Tag Binding

Every engagement record is assigned an allegiance value - provider or payer - at creation time. The tag is immutable for the life of the engagement: no subsequent operation, including administrative override, can change which side an engagement was created to serve.

Fail-Closed Enforcement Point

Every PIEB endpoint checks the requesting engagement's allegiance tag before returning any data. If the tag does not match the payer-facing role the endpoint expects, the request is denied by default - the enforcement is a precondition of the query resolving at all, not a downstream filter applied to results that have already been assembled.

Architectural Enforcement of the Allegiance Firewall

The distinguishing design choice is where the check happens. A policy-based wall lives in a handbook or a contract; an application-logic wall lives in business code that a bug or a rushed change can bypass. JIL's allegiance check lives in the data-access layer itself - structurally upstream of both.

Layer	What It Controls	Bypassable By
Organizational policy	Staff behavior and training	Human error, malice, ignorance of policy
Application business logic	What a given feature does with data it has already fetched	Bugs, missed code paths, new features that forget the check
Data-access layer (JIL)	Whether a query can resolve any rows at all for a mismatched allegiance	Nothing above it - denial happens before data leaves storage

Because the check sits below the application layer, even a compromised credential, a manual operator override, or a defect in a new payer-facing feature cannot surface a provider-side engagement's data through the PIEB path - there is no code path through which the mismatched read can succeed.

Prior Art Differentiation

Approach	Serves Both Sides?	Shared Rule Canon?	Separation Enforced By
Payer-side claims-editing / SIU platforms	No (payer only)	No	N/A
Provider-side compliance / revenue-cycle vendors	No (provider only)	No	N/A
Traditional dual-mandate consultancy ("Chinese wall")	Yes, via separate teams	No - independently maintained	Policy / contract
JIL Sovereign Allegiance Firewall	Yes, one engine	Yes, one 332-check canon	Data-access-layer, fail-closed

Patent Claim

Independent Claim 36: A computer-implemented compliance-attestation system comprising: a verdict engine that evaluates a single canonical set of compliance checks against a common body of claims data; a first evidence-bundle generator that packages check results into a provider-facing audit-ready evidence bundle for use in defending a provider under audit; a second evidence-bundle generator that packages the same check canon's results into a payer-facing payment-integrity evidence bundle for use in building a recovery case against that same provider; an allegiance tag bound to each engagement record at creation and immutable thereafter; and a data-access-layer enforcement module that, for every read or write request against a payer-facing endpoint, evaluates the requesting engagement's allegiance tag and denies the request by default unless the tag matches the payer-facing role, such that a provider-side engagement's underlying data is structurally unreachable through the payer-facing code path regardless of application-layer logic or operator error.