Honest Uncertainty Is a Product Feature

Software tools are rewarded for producing simple answers.

Passed.

Failed.

Recovered.

Verified.

Done.

Those labels are convenient. They can also hide the information a buyer or engineer needs most.

A deployed application may be recovered for three user journeys while authentication refresh remains unobserved. A refactor may pass every configured check while one dynamic-import path has no evidence. A dependency may be strongly attributed to a package family but not to an exact public version. A candidate may be valid while a guard blocks it for the wrong reason.

The trustworthy output is not always green or red.

Sometimes it is:

This part is established. This part is inferred. This part remains unknown.

Confidence is not evidence

AI agents often communicate confidence fluently.

A detailed explanation can feel like proof because it describes a coherent theory of the code.

But confidence can come from several different sources:

• direct observation;
• source analysis;
• pattern recognition;
• remembered conventions;
• plausible completion;
• assumption.

Those sources are not equivalent.

An evidence system should preserve where a conclusion came from rather than flattening every result into a polished narrative.

Four kinds of statements

A useful public and technical report can separate at least four statement types.

Measured

The system directly observed the fact under a defined condition.

Example:

The candidate completed the declared checkout flow in the frozen browser scenario, with no unexpected console errors.

Derived

The result follows mechanically from measured inputs and a declared rule.

Example:

The source hash changed after the evidence was recorded, so the previous verdict is stale.

Inferred

The evidence supports a likely interpretation, but alternatives remain.

Example:

This bundled region is probably a modified copy of package X, based on source and runtime fingerprints.

Unresolved

The system does not have enough evidence to make the claim.

Example:

The service-worker update path was not exercised and remains unverified.

These labels make the report more useful, not less decisive.

Unknown is not a warning color

One of the most damaging design choices is treating missing evidence as a quiet green.

If a browser scenario never reached the requested state, the tool should not report that state as passing.

If an equivalence provider did not run, the overall result should not silently inherit the results of the layers that did.

If a donor service is unavailable, the system should distinguish donor failure from candidate regression.

If a source-map path is stale, it should not be promoted as recovered authored truth.

Unknown has its own meaning.

It is not necessarily a product defect. It is a boundary on the claim.

Recovery needs residuals

A source-recovery report should not end with a single percentage.

It should make the remaining debt explicit:

• unresolved modules;
• captured vendor regions;
• live service dependencies;
• unsupported worker or native surfaces;
• untested application states;
• inferred semantic names;
• protected surfaces;
• source that remains generated or opaque;
• build assumptions;
• product-scope decisions.

A buyer may still choose to proceed.

The important thing is that the decision is informed.

A partial recovery with honest residuals can be much more valuable than a clean-looking workspace with hidden dependence on the original deployment.

Verification needs coverage

KodeProof’s long-term trust verdict should say more than whether the candidate was blocked.

It should reveal:

• which contract was evaluated;
• which evidence provider ran;
• which provider failed;
• which checks were unavailable;
• whether the original changed;
• whether the candidate transferred;
• whether the independent task grader passed;
• whether the blocker was later adjudicated as valid;
• what the workflow cost;
• whether the evidence was current.

This allows catches and false blocks to coexist in the same product report.

A tool that publishes only catches has not established precision.

False refusal matters too

Safety products naturally focus on escaped failures.

A second failure mode is blocking valid work.

A recovery candidate may satisfy every declared requirement while the pipeline refuses promotion because of an overbroad gate. A refactor may be behaviorally and architecturally correct while an environment defect appears as a source failure.

False refusal has real cost:

• engineering time;
• loss of trust;
• pressure to disable checks;
• compatibility workarounds;
• slower adoption;
• distorted benchmark results.

KodeProof therefore needs to treat false blocks as first-class product failures, not embarrassing footnotes.

The goal is not maximum blocking.

It is calibrated blocking.

Honest incompleteness should receive credit

Suppose two systems attempt the same recovery.

System A reports success, but the hidden grader later finds that one route and a persistence behavior are broken.

System B reports that those two surfaces are unresolved and refuses to call the project complete.

System B produced the more trustworthy result, even if its headline completion rate is lower.

Evaluation should reward:

• correct refusal;
• calibrated confidence;
• accurate residual reporting;
• explicit unsupported boundaries;
• no false transfer;
• preservation of the original.

This is especially important when comparing models. A model that refuses a poorly supported rename can be more useful than a model that produces a fluent answer for every packet.

Product copy should preserve the same discipline

Marketing language often destroys the nuance the product worked to create.

Technical report:

No unexpected differences were observed in four captured states. The WebSocket reconnect path was not exercised.

Homepage translation:

Perfect parity.

That translation is not acceptable.

The public claim should remain scoped:

Compared against four declared states, with the reconnect path listed as unresolved.

The wording may be less dramatic.

It is also defensible.

A practical evidence card

Every public demonstration should include a compact card:

Evidence basis: Owned application, synthetic fixture, internal dogfood, or customer-authorized case.

Scope: Exact flows, files, or transaction.

Measured: What ran and passed.

Inferred: What was classified but not proven.

Unresolved: What remains outside coverage.

Product status: Research, private alpha, pilot, or generally available.

Reproduction: Versioned artifacts or methodology where publishable.

That one card can prevent a large amount of accidental hype.

Trust compounds

Honest uncertainty does more than reduce legal or reputational risk.

It improves the product.

When a gap is explicit, it can be:

• turned into a fixture;
• added to the next capture;
• assigned to a new evidence provider;
• tested with a known-bad mutation;
• compared across models;
• promoted into a deterministic rule;
• tracked until resolved.

Hidden uncertainty cannot be improved because it is disguised as success.

The Kalu Kode position

KodeBack should tell buyers exactly what was recovered, reconstructed, inferred, retained, or left unresolved.

KodeProof should tell engineers exactly what it checked, why it blocked or transferred, and how much evidence supports the result.

Neither product should promise formal certainty where the system performs empirical observation.

The commercial thesis is not that uncertainty disappears.

It is that uncertainty becomes visible, bounded, and actionable.

In software recovery and AI change control, that is a product feature.