← Back to journal

Keep the Archive Separate from the Interpretation

Why collecting repository evidence and explaining repository history are different product milestones.

Evidence basisKodeAtlas website source reviewed September 17, 2026; archive implementation was not supplied
DisclosureArchive capabilities are website-described; semantic context and later roadmap capabilities are in development or planned. No delivery date is promised.
Related to KodeAtlasExplore KodeAtlas →

Scope: Archive capabilities are website-described; semantic context and later roadmap capabilities are in development or planned. No delivery date is promised.

A repository archive and a repository memory system answer different questions. An archive asks whether the relevant material was collected, preserved, and indexed. A memory system asks what that material means for the change an engineer is considering now.

KodeAtlas starts with the former. The current product website describes an implemented archive CLI, while semantic context and lineage remain the next development phase. The archive implementation is not part of the Kalu source snapshot behind this article; its current capability description comes from the KodeAtlas website, not an independent implementation audit.

Preserve both the source and the interpretation

The archive design keeps raw API evidence alongside normalized records and indexes. That separation matters because the interpretation of a discussion can change without the discussion itself changing.

Consider a synthetic pull request that updates an interface, renames a helper, and explains a rejected alternative. A normalized relationship can make the pull request easy to find. The underlying review text is still necessary to distinguish an explicit decision from an inference made later.

If a future analysis improves its relationship model, it should be able to revisit that evidence rather than inheriting the earlier model’s conclusion as a fact.

A complete record is not a complete explanation

The website describes Git history, collaboration records, release material, manifests, and verification as archive concerns. Those are useful foundations. They do not establish that the system can follow a function through an extraction or tell an agent which historical decision still applies.

That next step introduces ambiguity: similar names, split responsibilities, missing discussions, and decisions that were later reversed. Preserving evidence makes those questions answerable in principle. It does not answer them automatically.

Evaluate each layer on its own terms

For an archive, ask which resources were collected, which were partial, and what verification actually checked. For a context system, ask whether its citations support the recommendation and whether it distinguishes an explicit statement from an inferred relationship.

This separation is central to how we describe KodeAtlas. Archive collection is the established website-described foundation. Bounded context and semantic lineage are development work, not capabilities we should imply merely because their raw ingredients are present.

A useful engineering memory should make it easier to revisit the evidence, including when the current interpretation turns out to be wrong.