Output Parity Is Not Input Parity: What Execution Evidence Must Bind

Software verification often begins too late.

Teams compare outputs, run smoke tests, check exit codes, and inspect whether a generated artifact looks plausible. Those checks matter. But they cannot answer a more basic question:

Did every consumer receive the same intended input?

If the answer is unknown, output parity is weak evidence.

Two programs can both complete successfully while solving different problems. One adapter may truncate precision. One wrapper may drop a flag. One generated client may normalize a field differently. One CI lane may render a template with different environment truth.

The outputs may still look reasonable. The commands may still exit zero. The smoke tests may all pass.

The parity inference is still untrustworthy.

Ota's position is direct: acceptance evidence must bind what was declared, what was delivered, where it ran, and what was observed. Output alone is not enough.

A recent Claude Code issue describes a useful failure shape. Two companion tools were generated from one specification and processed a large body of work. Their outputs survived smoke testing and output-side fault checks.

But one input path had reduced numeric precision. The tools were not receiving equivalent inputs, so they were not actually evaluating the same problem.

That is not merely a testing mistake. It is an evidence-design mistake.

The verification system asked:

• did both tools run?
• did both produce output?
• did the output survive selected checks?

It did not establish:

• which canonical input each tool was meant to receive
• which transformation produced each delivered representation
• whether the delivered representations were semantically equivalent
• whether the checks exercised the exact input path later used in real execution

Once that link is missing, output comparison begins after the divergence has already happened.

A digest is useful for byte identity, but incomplete.

A digest can establish the identity of bytes. It does not automatically establish:

• that the bytes came from the canonical declared source
• that the renderer used the intended version and configuration
• that two different representations are semantically equivalent
• that the consumer actually received the recorded representation
• that the proof exercised the same path used by the real task

For example, a JSON fixture and a command-line argument may encode the same logical value in different forms. Their byte digests should differ. The important question is whether each form was derived correctly from the same canonical input and delivered to the intended consumer.

That requires provenance, not just hashing.

A trustworthy execution record needs five distinct bindings.

1. Declared intent

Which contract, task, workflow, and canonical input governed the run?

This prevents a successful command from floating free of the repository truth it was supposed to execute.

2. Delivered input

What exact representation reached each consumer?

This is stronger than recording the source file. A template, wrapper, environment projection, CLI serializer, generated SDK, or protocol adapter may change the value between source and consumer.

3. Transformation provenance

Which producer, renderer, version, configuration, and transformation path created that delivered input?

Without this, two matching outputs may only prove that the same untracked mistake happened twice.

4. Execution boundary

Which source state, worktree, runtime, platform, mode, and isolated boundary executed the consumer?

Evidence from another checkout, container, task closure, or runtime cannot silently stand in for the selected run.

5. Witnessed result

What did the runner actually observe: output identity, side effects, dependency interaction, failure behavior, or an explicitly unproved boundary?

This keeps execution success separate from proof breadth. A zero exit can establish that a command completed. It cannot, by itself, establish that the command received the correct input or produced the intended application behavior.

This is the distinction Ota is designed to make explicit. Task runners and CI scripts can carry these bindings, but they do not establish them by default.

A task runner can launch two commands.

A CI workflow can compare their output files.

A README can say both commands should use the same fixture.

Execution governance asks whether the evidence chain is complete enough to authorize acceptance:

contract intent
  -> canonical input identity
  -> transformation identity
  -> delivered input identity per consumer
  -> selected execution boundary
  -> witnessed result and explicit not-proved boundaries

If any required link is unavailable, the honest verdict is not "close enough."

It is unknown, not_proved, or refusal, depending on the declared policy.

That distinction matters for humans, CI, and AI agents. Agents are especially good at producing plausible implementations quickly. They are not a substitute for runner-authored evidence that the implementation consumed the intended truth.

Ota already provides building blocks for parts of this chain:

• semantic contract identity ties execution back to normalized repository truth
• clean source identity can bind evidence to the exercised repository state
• replay inputs stay separate from witnessed observations
• expected input identities can refuse selected execution when a governed file is missing or has changed
• receipts preserve runner-authored execution evidence
• proof output carries explicit not_proved boundaries instead of turning a narrow green result into a repository-wide claim
• promoted replay baselines remain separate from ordinary observed output

See Replay Inputs and Trusted Baselines, Execution Receipt, and Runtime Proof Evidence.

These separations are deliberate. A previously observed output must not quietly become an input assumption. A file name must not substitute for content identity. A successful task must not become proof of behavior it never observed.

Ota does not yet provide or claim a general, first-class proof that multiple consumers received semantically equivalent delivered inputs through different transformation paths.

That is the useful next refinement exposed by this failure class.

The mature shape is not a maintainer-authored inputs_match: true. It is runner-authored evidence that records:

• the canonical input identity
• each consumer and delivered representation identity
• the transformation or producer identity for each representation
• the equivalence rule that was actually evaluated
• the result and any unresolved semantic boundary

Byte equality can prove exact representations match. Semantic equivalence needs a declared, reviewable comparator appropriate to the input type. If Ota cannot verify the transformation or delivery seam, it must not promote the result beyond the evidence it has.

This should extend Ota's existing replay, artifact-lineage, and proof-evidence model. It should not become a parallel trust system or a vague "generated by AI" label. The risk is not that a tool was AI-generated. The risk is that operational trust was granted without evidence binding its inputs, execution, and effects.

There is also a governance consequence.

If delivered-input equivalence is required for a lane, discovering that the evidence is missing or contradictory must block that lane. A warning that everyone learns to ignore is documentation, not governance.

Any exception should be explicit, scoped, attributable, and preserved as evidence. It should not silently turn an unproved input path into an accepted one.

This is the standard Ota is built around:

Declare the execution truth once. Enforce the selected boundary. Preserve evidence of what actually happened. Refuse to claim what was not proved.

Output parity can be useful evidence.

It is not input parity.

Before trusting the output of generated scripts, adapters, drivers, workflows, or ordinary handwritten tools, teams need to know that each consumer received the intended input through a traceable transformation path.

That is not extra metadata around execution. It is part of the execution contract itself.

Ota's job is to make that chain machine-readable, enforceable, and honest enough that developers, CI systems, and AI agents do not have to infer trust from a green command and a plausible file.