Immutable Bundle Regeneration Lineage with Deterministic Cached Cross-Version Diff

Executive Summary

JIL Sovereign's evidentiary bundle regeneration model never mutates a previously sealed bundle. Any operation that would conventionally be described as "updating" a bundle instead creates a brand-new bundle row, independently sealed - hashed and signed - exactly as an original bundle would be, and records a parent_bundle_id lineage pointer to the prior bundle. There is no update-in-place code path for a sealed bundle's content; every revision is additive, forming a linked chain of immutable versions.

Because both endpoints of any parent/child pair are already cryptographically frozen and will never change again, the diff between them is not a live computation subject to future change - it is a fixed fact. A diff service computes this structural diff once per (parent, child) pair and caches it indefinitely, with correctness guaranteed by the immutability of the inputs rather than by a time-based invalidation policy.

Problem Statement

Systems that regenerate compliance or evidentiary output in place - updating the same bundle record as underlying facts change - destroy the ability to answer what a bundle asserted on the date it was relied upon, a question that matters in litigation, appeals, and regulatory review, where a party may need to show precisely what a prior version stated before it was corrected. Even systems that do version their bundles often compute cross-version diffs on demand from the live records, which is comparatively expensive to run repeatedly and, more importantly, is not guaranteed to be stable: if the diff computation or comparison logic changes over time, a diff run today may not match a diff run months earlier for the same two version identifiers, undermining reliance on it.

Why Conventional Versioning Falls Short

• In-place regeneration: destroys the historical record of what a bundle asserted at a specific point in time.
• Live cross-version diffing: recomputed on demand from current records; not guaranteed stable if comparison logic changes, and expensive to run repeatedly.
• Document "version history" tools: versions are diffable but generally not independently cryptographically sealed at each version.

Technical Architecture

Regeneration Path

Any request that would conventionally be handled as "update this bundle" instead generates a new bundle record, independently hashed and signed exactly as an original bundle is, and sets that new record's parent_bundle_id to the identifier of the bundle it supersedes - forming a linked lineage chain of immutable versions rather than a single mutable record.

Diff Service

Given any two bundle identifiers in a lineage, the diff service computes added, removed, and changed evidentiary items and changed completeness dispositions between the two sealed manifests, and serves that result from cache on subsequent requests for the same pair.

Chain-of-Custody Alignment

The parent_bundle_id lineage pointer functions as a first-class chain-of-custody relationship in its own right, letting a reviewer walk the full version history of a bundle the same way they would walk a custody chain for a physical exhibit - each version independently sealed, each transition explicitly and permanently recorded.

Prior Art Differentiation

Patent Claim