← Back to journal

A Proposed Parity Plan Is Not a Passing Result

Why KodeBack refuses to turn an automatically proposed comparison into qualification.

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 tool can help an engineer describe a comparison without having authority to approve that comparison. The distinction is easy to lose when plan generation and execution appear in one command-line workflow.

KodeBack’s planless cassette-parity behavior makes the boundary explicit. Without an accepted plan, the current source can observe a boot state and write a proposed plan. It returns an unsupported, proposal-only result rather than claiming parity passed.

Observation does not choose the acceptance standard

Suppose a synthetic page displays a heading and sends a request. Observing those events can help describe possible assertions. It does not establish that those are the only behaviors the maintainer cares about, or that the tool selected a sufficient acceptance standard.

An automatically proposed plan is therefore diagnostic material. It can reduce the effort of authoring a comparison, but it should not quietly decide what counts as success and then congratulate itself for meeting that decision.

Keep the authority separate from convenience

The current command names this condition PARITY_PLAN_PROPOSAL_ONLY. That is a useful example of product output carrying the same boundary as the architecture. A human or an automation layer can distinguish “there is a proposal to review” from “the candidate satisfied an accepted contract.”

This matters even when the generated file looks complete. A well-formed JSON document can still have the wrong authority. Presence, schema validity, and useful content are not substitutes for the acceptance decision the workflow requires.

Review the intended behavior before promotion

A reviewer should ask whether the proposed states cover the maintenance objective, whether the required resources are represented, and whether the observation can distinguish the relevant failure. Missing interaction or visual coverage should remain visible rather than be assumed from a successful boot.

This article describes the September source behavior, not a guarantee that any arbitrary application can be qualified through the planless path. The current refusal is intentional: a proposal is not enough.

The broader lesson is valuable beyond recovery. Automation can be excellent at preparing a decision while remaining the wrong owner of the decision itself. KodeBack should make the next engineering step easier without pretending that the step has already been approved.