← Back to journal

A Match Inside a Bundle Is Not Ownership of the Bundle

Why containment evidence should not become permission to remove surrounding application code.

Evidence basisKalu, Korpus, and frozen Ushman source/docs snapshot reviewed September 17, 2026; no new runtime qualification performed
DisclosureEngineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.
Published by Kalu KodeRequest a KodeBack assessment →

Scope: Engineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.

A recognizable library fragment can appear inside a much larger bundle. That is useful containment evidence. It is not proof that the surrounding declarations, helpers, and effects belong to the same package.

Recovery gets dangerous when those two statements are treated as equivalent. A recognizer finds a strong anchor, and a later step removes a region wider than the evidence actually justified.

Follow the boundary beyond the match

Imagine a synthetic bundle with a library constructor, a shared helper, and application-specific initialization in one top-level region. The constructor may match an authenticated reference closely. The helper may also serve first-party code. The initialization may be unique to the application.

A safe ownership analysis needs to preserve those distinctions. Finding the constructor does not establish exclusive ownership of the helper, and finding both does not authorize removal of the application’s side effect.

Stronger recognition does not erase closure work

Kalu’s harvest notes explicitly separate minifier-stable anchors from ownership authority. Longer or more distinctive literal evidence can improve a match while still leaving the source boundary unresolved.

The bundle-isolation engine therefore has its own responsibilities: source coordinates, declaration closure, outside references, writes, and evaluation-order obligations. A complete selection is not automatically a package attribution, install pin, certificate, or transaction.

Explain the retained region

When a shared helper blocks a carve, the useful outcome is a bounded explanation of the outside referrers. The engineer can see why the proposed removal would cross first-party or unresolved ownership rather than receiving an unexplained “not supported.”

That refusal may identify a later research opportunity. It should not be weakened simply to make the current externalization demonstration look complete. Retained target implementation also needs to be reported honestly rather than renamed as unrelated residue.

The current source implements bounded recognition and isolation mechanisms; it does not offer an arbitrary bundle demixer. The practical question for an evaluator is not only “did you find the library?” It is “which exact bytes does the evidence let you treat as the library, and what must remain?” That second question is where recognition becomes useful engineering rather than a visual similarity exercise.