Kalu Kode Journal
Evidence before announcements.
The Journal documents the reasoning, experiments, failures, and measurable boundaries behind KodeCapture,KodeBack, KodeAtlas, KodeProof, and the shared research platform.
A Roadmap Article Should Explain the Test Before the Feature
How we discuss future harvest work without disguising plans as shipped capability.
What We Are Looking for in Our First Design Partners
Kalu Kode is pre-revenue and has not validated market fit. We are looking for organizations with real, authorized capture, recovery, or AI-refactor problems.
Do Not Measure Recovery by Lines Rewritten
A proposed scorecard centered on maintainability, preserved behavior, and unresolved risk.
Judge a Context Packet by the Plan It Changes
A proposed evaluation for bounded, cited repository context.
A Useful Demo Includes the Case That Breaks It
How to present bounded engineering progress without turning a demonstration into a universal claim.
How We Evaluate a Product That Is Supposed to Verify AI
KodeProof cannot use its own verdict as the sole proof that it works. We need frozen campaigns, independent graders, calibrated mutations, and reports that include false blocks.
Holdouts Should Stay Out of the Workshop
A research lesson about keeping evaluation examples independent from the system being tuned.
Six Generations of a Source-Recovery Architecture
Our recovery system evolved by removing one false assumption at a time: permanent opacity, reconstruction from description, recovery-shaped workspaces, and broad agent handoff.
The Product Promise Should Fit in a Status Report
Why complete, partial, blocked, and unsupported deserve plain-language explanations.
Historical Ledgers Are Maps, Not Live Roadmaps
How we use the Ushman harvest record without turning old plans into new promises.
An Index Is Not Yet Engineering Memory
The difference between finding a repository record and knowing whether it still matters.
A Prerelease Tag Cannot Qualify a Product
What a source snapshot proves, what an installed journey proves, and why we keep the labels separate.
What a Source Recovery Assessment Should Tell You
Before committing to a recovery, an organization should know what evidence exists, which route applies, what can be made independent, and what remains risky.
Why We Built a Corpus That Knows Its Own Answers
How source-owned fixtures help separate recovery evidence from a tool grading its own output.
Honest Uncertainty Is a Product Feature
A recovery or verification system earns trust by separating what it proved, what it inferred, what it could not observe, and what it refused to change.
The Most Valuable Code We Harvest May Be a Refusal
Why negative examples deserve a first-class place in a research-to-product migration.
Our First Growth Metric Is a Better Engineering Question
A founder-led approach to measuring early interest without mistaking impressions for product validation.
Keep the Archive Separate from the Interpretation
Why collecting repository evidence and explaining repository history are different product milestones.
The Model Should Decide. The System Should Edit.
AI is valuable for semantic judgment. Mutation authority should remain with source-aware, preview-bound, rollback-capable tools.
Four Products, Four Different First Questions
How to route an engineering problem without pretending every Kalu Kode product is interchangeable.
A Research Engine Is Not a Product Release
Why Kalu Kode is harvesting a frozen research system into narrower, independently accountable products.
Build Green Is Not Behavior Green
Compilation is necessary, but it cannot tell you whether a refactor changed initialization order, runtime state, layout, message contracts, or a user journey.
Why AI Agents Rename the Wrong Things
Semantic cleanup is not a global search-and-replace problem. The difficult part is distinguishing local meaning from public contracts, serialized keys, asset identities, and other protected surfaces.
What a Bundler Hides: App Code, Dependencies, and Glue
A production bundle is not one author’s code. Reliable recovery must separate first-party logic, third-party packages, modified vendor code, and bundler runtime before cleanup begins.
Recovery Starts With Capture, Not Code Generation
A raw agent cannot recover behavior it never observed. Reliable source recovery begins by preserving the deployed application as a donor and replayable evidence surface.
Shipped Software Is Not Source Code
A working application can survive while its maintainable source disappears. Understanding the difference is the first step in software ownership recovery.
Abstention Is an Engineering Output
When evidence is contradictory, stale, unsupported, or too weak for the requested risk, refusing to mutate is a useful and actionable result.
A Chat Transcript Is Not a Software System of Record
Agent conversations are useful for reasoning, but durable software work needs source-bound plans, receipts, validator results, and explicit state transitions.
Software Evidence Has a Supply Chain
Capture, recovery, software memory, and change control are different products because each owns a different transformation of evidence.
Freshness Is Part of a Software Fact
A report can be correct for the state that produced it and unsafe for the state in front of you. Evidence needs identity, dependencies, and expiry conditions.
Source Recovery and AI Refactoring Share the Same Trust Problem
One reconstructs maintainable source from shipped artifacts; the other transforms known source. Both can produce plausible code that lacks evidence of behavioral control.
Why Kalu Kode Exists
Deployed truth can disappear, source ownership can be lost, and AI can change code faster than teams can safely trust it. Kalu Kode is building the evidence layer across that lifecycle.