Executive Summary
JIL Sovereign's rule repository represents every edit to a governing rule as a new, immutable, content-hashed rule-version record, rather than an in-place modification of an existing one. Each rule-version record retains a reference to the logical rule it instantiates and an effective date range, but its content - the actual rule text or logic that was applied - is fixed and content-hashed at creation and never subsequently altered.
When a decision is rendered, it is bound not to the logical, mutable rule, but to the specific, immutable rule-version record that governed it, via a composite decision-to-rule-version link keyed by the decision identifier, the rule-version identifier, and a statutory or policy basis category. That composite key allows a single decision to cite multiple distinct rule versions under distinct bases simultaneously - for example, a medical-necessity criterion and an independent timely-filing rule - while ensuring that no subsequent correction to the logical rule can ever retroactively alter what a historical decision is recorded as having relied on.
Problem Statement
In regulated review and appeal systems - utilization review, prior authorization, claims adjudication - the rules governing a decision change over time: reimbursement policy is updated, statutory thresholds are revised, medical-necessity criteria are corrected. When a rule is later corrected, systems that store only a mutable pointer to "the current version of rule R" create a serious evidentiary problem: a historical decision's recorded rationale can silently reflect the rule as it reads today rather than as it read at the moment the decision was actually made.
This is not merely a data-hygiene concern. It is exactly the kind of retroactive-rewrite vulnerability that undermines appeal integrity, invites due-process challenges, and - whether through negligence or intent - can make a past denial or approval look more or less defensible after the fact than it actually was when it was issued. A reviewing body, an appellant, or an auditor examining a historical decision needs confidence that the rule text they are looking at is the rule text that was actually in force and actually applied at decision time, not a version that has since been edited.
Why Conventional Rules Engines Fall Short
- In-place rule editing (typical business-rules-engine configuration tables): a rule row is updated directly; nothing prevents the edit from silently altering what a past decision appears to have relied on.
- Timestamp-column "effective dating" without content hashing: reconstructs "the rule as of date X" via a query against a mutable table, which remains vulnerable to backfilled edits with no tamper-evidence.
- Decision logs that cite a rule by name or ID only: preserve that a rule was applied, but not what that rule's content actually was at the time, and do not support multiple concurrent bases per decision.
Technical Architecture
Rule-Version Record Structure
| Field | Purpose |
|---|---|
rule_id | Logical, mutable identifier for the rule as a concept (e.g. "timely filing requirement") |
version_id | Immutable identifier for this specific content snapshot of the rule |
content_hash | Cryptographic hash over the rule's actual text/logic, making any alteration to a historical version detectable |
effective_from / effective_to | Date range during which this specific version was the governing content for rule_id |
superseded_by | Reference to the rule-version record that replaced this one, when applicable |
Composite Decision-to-Rule-Version Citation
A decision-to-rule-version link is keyed by a composite of the decision identifier, the specific rule-version identifier relied upon, and a statutory or policy basis category. This composite structure is what allows a single decision to be bound to multiple distinct rule versions concurrently - for instance, a clinical medical-necessity criterion under one basis category and a separate procedural timely-filing rule under another - each independently citable and independently reproducible.
Immutability in Practice
An edit to the logical rule never modifies an existing rule-version record. It produces a new rule-version record with its own content hash, its own effective-date range, and a superseded_by reference from the prior version. Every decision-to-rule-version link continues to point at the exact version-record it was originally bound to, which remains byte-identical and independently reproducible - and cryptographically verifiable via its content hash - regardless of how many times the logical rule is subsequently revised.
Composite Citation Model
The basis-category dimension of the composite key exists because real decisions are rarely governed by a single rule in isolation. A denial, for example, might simultaneously rest on a clinical-necessity determination and an independent procedural defect - two different rule versions, two different basis categories, one decision. Modeling this as a composite link rather than a single rule-per-decision citation preserves the decision's actual, multi-basis grounding rather than forcing an artificially simplified single citation that would misrepresent what the decision actually relied on.
Prior Art Differentiation
| Approach | Rule Content Immutable Post-Decision? | Content-Hash Tamper Evidence? | Multi-Basis Concurrent Citation? |
|---|---|---|---|
| In-place rule editing (typical BRE config tables) | No | No | No |
| Timestamp-column effective dating, no content hash | Partially - vulnerable to backfilled edits | No | Not typically supported |
| Decision logs citing rule by name/ID only | N/A - content not versioned | No | No |
| JIL immutable rule-version binding | Yes | Yes | Yes - composite key per basis |