Software Evidence Has a Supply Chain

Software facts move through transformations.

A browser response becomes a captured artifact. Captured artifacts become dependency and behavior evidence. That evidence guides a recovered source candidate. Repository history and decisions explain why the candidate became what it is. A future refactor produces new evidence about what changed and whether the change should transfer.

Treating all of that as one product would hide important ownership boundaries.

KodeCapture preserves observation

KodeCapture begins with deployed software and a declared session. It records bytes, routes, requests, interactions, runtime signals, environment policy, coverage, and residual gaps.

Its authority is observational. It can say what the capture saw and how those artifacts were obtained. It should not decide what a minified binding means or claim that an unvisited route was covered.

That boundary matters because downstream tools need stable input. Capture should preserve evidence before interpretation begins.

KodeBack transforms evidence into maintainable source

KodeBack consumes a donor and derived evidence to produce an editable candidate.

It identifies source maps and vendor regions, protects external contracts, recovers semantic names and structure where supported, and checks the candidate against measured donor behavior.

Its authority is recovery. It can make a source tree more useful while retaining provenance and uncertainty. It should not promote the candidate into a new oracle merely because the code looks clean.

KodeAtlas preserves development memory

Software continues changing after recovery or ordinary development. Commits, pull requests, issues, reviews, releases, and repository state provide historical evidence about those changes.

KodeAtlas currently provides a verifiable Git and GitHub archive foundation. The broader context platform—symbol lineage, context packets, backlog and regression memory, and agent coordination—remains in development or planned according to the status shown on the KodeAtlas site.

Its role in the supply chain is memory: retaining why a change happened and which evidence supported it.

KodeProof controls the next mutation

KodeProof begins with a real repository state and a declared change.

It isolates candidate work, protects scope and contracts, runs structural and behavioral evidence, explains the verdict, and transfers only the authorized passing postimage.

Its authority is transactional. It should not use the agent’s confidence as its proof or confuse a green candidate with a completed transfer.

Receipts connect the boundaries

Each product can produce a receipt for the next one:

• capture root and coverage report;
• recovery provenance and handoff state;
• archive and historical context;
• change contract, evidence, verdict, and transfer record.

The receipt names exact inputs and limitations. That prevents a later stage from borrowing confidence from a vague upstream statement.

Why one universal confidence score would fail

The evidence surfaces measure different things. A complete capture does not prove semantic recovery. A successful build does not prove behavioral parity. A preserved Git archive does not prove a planned capability is implemented. A green refactor transaction does not prove every possible user journey.

Collapsing these into one score would make the system simpler to market and harder to trust.

The product-family thesis

Kalu Kode is building a chain in which each transformation retains its source authority:

1. preserve what shipped;
2. recover what can be maintained;
3. remember why it became that way;
4. control what changes next.

The chain can be used in parts. A team may need capture without recovery, recovery without ongoing agent change control, or KodeProof for an ordinary repository that was never recovered.

What connects the products is not a forced workflow. It is a shared rule: every important software claim should point back to the evidence that gives it authority.