Declare the change
Define the intended mutation, protected entrypoints and contracts, allowed files, required architecture outcome, project gates, and behavior scenarios.
AI code-change control · Private alpha · JavaScript/TypeScript research focus
AI changes code fast. KodeProof controls what reaches the repository.
KodeProofturns a risky change into an isolated, declared transaction. It gives agents bounded decisions, uses deterministic actuators where coverage exists, checks multiple evidence layers, and transfers only the candidate that satisfies the configured contract.
KodeProofprovides scoped empirical evidence, not formal proof. Project tests and engineering review remain part of the evidence stack.
Declare · isolate · check · transfer
Evidence surface
The transaction leaves a readable record, not only a green check.
This illustrative ledger shows the shape of a declared change: before-state, bounded plan, evidence layers, and a transfer decision that can still refuse to move anything.
transaction.ts
typescript
const before = await captureBeforeState({ scope: "src/**" });
const plan = await preparePlan({ contract, before });
const candidate = await runIsolated(plan);
const evidence = await verify({ candidate, before, contract });
if (!evidence.passes || !before.isUnchanged()) {
return verdict("blocked", evidence);
}
return transfer(candidate, { declaredFiles: plan.files });
The problem
A plausible diff is not a trusted transaction.
Coding agents can decompose a monolith, move packages, consolidate helpers, change boundaries, and complete a hard cut at extraordinary speed.
- edit beyond intended scope;
- preserve a passing build while dropping a public export;
- create a hidden import cycle or change initialization order;
- leave a compatibility façade instead of completing a migration;
- pass visible tests while failing an unobserved behavior;
- claim completion after the workflow stopped or transferred nothing.
The problem is not that agents are useless. The problem is that the agent’s output, explanation, and confidence come from the same source. KodeProof introduces an independent transaction boundary.
Transaction toolchain
Bounded change control sits where source analysis meets an honest project gate.
KodeProof’s research context draws on Kodeguard transaction policy, Ushman evidence workflows, TypeScript, Bun, Babel analysis, and verification packages. The React Bits mark identifies the visual reference for this page, not a runtime dependency.
Transaction model
Seven gates between intent and transfer.
Capture an immutable before-state
Fingerprint the real current repository state—including tracked, modified, staged, and relevant untracked content—without requiring a commit, stash, or reset.
Prepare bounded choices
Use source-backed analysis to identify covered opportunities and reviewed options. The agent supplies semantic judgment where necessary.
Act only in an isolated candidate
Deterministic actuators apply covered transformations through exact preview-bound plans. Manual agent edits stay inside the disposable candidate.
Run proportional evidence
Check structure, imports/exports, module load, effects and order, protected literals, behavior scenarios, affected tests, and full project gates.
Produce a causal verdict
Separate candidate regressions, baseline debt, environment changes, policy violations, unsupported coverage, agent workflow failure, and harness failure.
Transfer—or refuse
Transfer only the declared candidate files when the verdict passes and the original fingerprint is unchanged. Retain blocked candidates for repair.
Why this is more than CI
CI evaluates a repository state. KodeProof evaluates a declared change transaction.
CI can tell you whether commands pass after a change. KodeProof also knows which before-state the transaction began from, what the change was supposed to do, which files and bindings were allowed to move, which contracts were protected, whether topology or order changed, whether the original changed during the session, and whether transfer completed.
Your tests remain important. They are one layer of evidence—not the entire safety model.
Customer-facing capabilities
A transaction system with visible failure modes.
Guarded workspace
Agents experiment against an immutable before-state in an isolated candidate.
Change contract
The transaction declares what may change, what must remain stable, and which project gates matter.
Structural plan
Source-backed plans distinguish apply-ready actions, reviewed choices, advisory opportunities, and unsupported requests.
Evidence stack
Structure, boundary, behavior, project, and environment evidence remain separately visible.
Trust verdict
A verdict explains why a candidate passed, blocked, stopped, or remained unsupported.
Controlled transfer
Only the declared, passing transaction reaches the original workspace.
Workflow preview
Start with refactors whose failure is expensive and whose contract can be declared.
Decompose a monolith
Protect public entrypoints, preserve initialization-sensitive ownership, move coherent regions through reviewed plans, require direct consumer imports, and refuse compatibility sludge.
Move a module or package boundary
Bind exact source and destination ownership, rewrite consumers directly, preserve exports and effects, and reject stale plans.
Consolidate helpers
Prove similar helpers are actually equivalent for the declared use before replacing them with one owner.
Complete a hard cut
Coordinate file, export, import, dependency, schema, or multi-repository transitions without indefinite compatibility bridges.
Protect a public contract
Declare CLI commands, package exports, artifact shapes, opaque files, literals, or behavior scenarios that must survive the refactor.
Example verdict
A useful result is a causal explanation and an executable next action.
Blocked
Candidate: Behavior checks passed; declared architecture incomplete
Primary cause:One consumer still imports through the former owner, leaving a two-hop compatibility path
Original workspace: Unchanged
Project gates: Passed
Coverage gap: One dynamic-import path was not exercised
Next action:Rewrite the remaining consumer directly, rerun affected evidence, then finish.
Evidence Lab
A verification product should publish its own uncomfortable results.
KodeProofis evaluated in a separate longitudinal framework that preserves exact model, harness, reasoning, prompt, treatment, repository, environment, budget, raw events, native artifacts, and independent grader outcomes.
- original-worktree corruption;
- transfer-policy violations;
- independent task regressions;
- false confidence;
- catches, false blocks, workflow, and harness failures;
- time, tokens, and cost.
KodeProof Journal
Refactor evidence that does not stop at a green build.
Read about transaction boundaries, structural proof, runtime characterization, tiered equivalence, and performance parity.
Runtime Evidence
Async Side Effects Need Provenance
An effect observed after an await should be attributed only when the harness owns the continuation. Otherwise the honest result is no claim.
Equivalence
Equivalence Is Tiered, Not Binary
Static structure, module loading, runtime traces, visual states, and end-to-end flows cover different failure classes. One green tier cannot stand in for the others.
Structural Verification
Initialization Order Is Behavior
Moving code can preserve every exported value and still change effects, cycles, registries, scheduling, or top-level-await order.
The Kalu Kode product family
Preserve. Recover. Remember. Control.
Four distinct products share one evidence-first philosophy and remain independently useful.
PreserveControl
KodeCapture
Preserves the observable truth of deployed software as replayable evidence.
Early accessRecoverKodeBack
Recovers maintainable source from software that still runs.
Selected assessmentsRememberKodeAtlas
Preserves why the code became what it is and delivers that context where change begins.
Archive foundation · context in developmentKodeProof
Controls what AI-authored changes reach the repository.
You are hereTake the next step
Bring one risky refactor and one engineer who owns the outcome.
We are looking for a small number of JavaScript/TypeScript-family repositories where the change is meaningful, the project gates are known, and the team is willing to evaluate the entire transaction rather than celebrate a selective demo.