Is this lineage pointer fully wired into bundle generation today?

The lineage pointer (redaction_of) is populated at redaction time, but automatic resolution and attachment of that lineage during bundle assembly is a documented follow-on integration rather than a currently wired end-to-end capability.

Derived-Artifact Redaction Preserving the Original Hash-Chained Blob

Q: Why is redaction modeled as derivation rather than an in-place edit?

An in-place edit is fundamentally incompatible with a hash-chained WORM evidentiary store, because it either breaks the original object's hash commitment or requires special-casing redaction as an exception to immutability. Modeling redaction as a fork - a new object with a lineage pointer to the untouched original - avoids both problems.

Q: Is the original object still accessible after redaction?

Yes. Both the original and the redacted derivative are independently addressable, independently retrievable, and independently hash-verifiable, so retention and access-control policy can be applied to each separately.

Executive Summary

JIL Sovereign's redaction mechanism never mutates or removes a stored write-once-read-many (WORM) object when redacting a record. Instead, redaction is modeled as a derivation operation: the redacted content - the source bytes with specified fields or spans masked - is written as an entirely new, independently addressable WORM object, tagged with an explicit lineage pointer (redaction_of) back to the untouched original object. Both objects, original and redacted derivative, remain independently retrievable and independently hash-verifiable.

Because the original is never touched, its hash-chain commitment is never broken by a redaction event, and it remains available - subject to appropriate access controls - even after a redacted derivative has been produced and distributed to a third party.

Core Innovation: Modeling redaction as object derivation rather than in-place transformation, so a hash-chained evidentiary original is never touched by a redaction operation and can be shown, on demand, to be the specific source of a given redacted derivative without exposing the original's unredacted content.

Problem Statement

Redaction is conventionally implemented one of two ways. It is either an in-place transformation that overwrites or replaces the original document with a redacted version - fundamentally incompatible with a hash-chained WORM evidentiary system, because it either breaks the chain's hash commitment or requires special-casing redaction as an exception to immutability. Or it is a purely presentation-layer masking applied at render or export time with no persisted redacted artifact - which cannot be handed to a third party, such as opposing counsel or a regulator, as a standalone document with its own independent integrity properties.

Neither approach cleanly answers the question that actually matters in a litigation or compliance setting: can the platform show that a produced, redacted document derives specifically from a given hash-committed original, without exposing that original to the party receiving the redacted version.

Independently addressable objects per redaction: original + derivative

Mutations to the original WORM object during redaction

Lineage pointer per derivative, back to its exact source

Why Conventional Redaction Falls Short

PDF/document redaction tools (Adobe Acrobat, Relativity): typically produce a standalone redacted file with no cryptographic lineage claim back to a hash-committed original.
Presentation-layer masking: masks fields in a UI or API response at render time; no persisted, independently distributable redacted artifact exists at all.
Data loss prevention (DLP) tooling: focused on preventing exfiltration of unredacted content, not on producing a provably-derived redacted artifact for lawful production.

Technical Architecture

Redaction as Fork, Not Edit

Step	Action	Effect on Original
1	Redaction request identifies a source WORM object and the fields/spans to redact	None
2	Redaction service generates redacted content by masking the identified spans within a copy of the source content	None - source untouched
3	Redacted content is written as a new, independently content-addressed WORM object	None
4	New object's metadata records a `redaction_of` lineage reference to the source object's identifier	None

Independent Addressability

Original and derivative are both independently retrievable and independently hash-verifiable. Retention, legal-hold, and access-control policy can be applied to each independently - broader distribution rights on the redacted derivative, restricted access on the original.

Relationship to Chain of Custody

Because both the original and the derivative are independently WORM-sealed and lineage-linked, a chain-of-custody record for the redacted derivative can cite the original's own custody chain without requiring re-verification of the underlying unredacted content by parties who should not see it. The current implementation populates the redaction_of lineage pointer at redaction time; automatic consumption of that pointer during bundle assembly is a documented follow-on integration.

Prior Art Differentiation

Approach	Original Preserved Untouched?	Cryptographic Lineage to Original?
PDF/document redaction tools	Sometimes, as a separate file	No
Presentation-layer field masking	N/A - no persisted derivative	N/A
Data loss prevention (DLP) tooling	N/A - prevention-focused, not derivation-focused	N/A
JIL derived-artifact redaction	Yes - never mutated	Yes - explicit lineage pointer

Patent Claim

Independent Claim 144: A computer-implemented method for redacting a stored evidentiary object comprising: receiving a request identifying a source object stored in a write-once-read-many store and one or more fields or spans within said source object to be redacted; generating redacted content by masking the identified fields or spans within a copy of the source content, without modifying the source object; writing the redacted content as a new, independently content-addressed object in the write-once-read-many store; and recording, in metadata associated with the new object, a lineage reference identifying the source object, such that the source object and the redacted derivative object remain independently retrievable and independently hash-verifiable, and retention or access-control policy may be applied independently to each.