Trust and evidence

autodev treats agent output as a proposal. Acceptance belongs to the host and should be supported by facts another process can inspect.

Four project rules define that boundary. They are governing invariants, not a claim that the current pre-release binary has closed every enforcement gap; see Current limitations.

1. Observe, never trust

Claims are useful inputs, but they are not outcomes.

Claim	Observation autodev keeps
“I committed the change”	Commits read from git before and after the turn
“I only changed these files”	Write set derived from the recorded commits
“The tests pass”	Validation run by the host in verification and candidate trees
“The merge is safe”	Repository gate run on integration and post-merge trees
“The operation changed N items”	Store or filesystem re-read after the mutation
“The turn used these resources”	Host-measured time plus reported usage, kept as separate facts

This is also why story contracts and base refs are pinned at dispatch: a later edit cannot silently rewrite what an in-flight result is being compared against.

2. Every refusal names its reason

Withholding a story, refusing a handoff, excluding a candidate, parking a wave, cancelling a worker, or declining to run an unconfined gate all produce reason-carrying records. Recovery should begin with a fact an operator or retrying worker can act on, not with a missing transition.

Reasons are part of the types wherever possible. They distinguish, for example, a test that passed against the old code, a test that never reached the old code, an environment failure, a cross-wave write-set collision, and a gate that could not run. Those are different failures and require different responses.

3. Ceremony is configurable; proof is not

Workflow definitions control states, edges, and how much process surrounds a story. Human approval is an optional gate, not a prerequisite built into autonomy. The intended delivery trust boundary is mechanical evidence, independent review, and a repository gate on the result that will remain. The fleet pipeline performs those stages. A direct board transition evaluates only the gates on its planning edge and does not manufacture a fleet delivery record.

Skipping a check is represented as a waiver with an actor and reason. It is not represented as a missing record that looks like success.

4. Absence stays absence

Unknown is not zero, and missing is not passed.

• A harness that provides no usage data records usage as unknown and names the harness.
• Metrics keep their denominator, so partial observations do not look complete.
• A criterion with no verification handle is different from one whose verification failed.
• A gate that could not run is refused, not red and not green.
• A truncated transcript records why it was truncated and how much was omitted.

This rule prevents tidy-looking aggregates from erasing the very uncertainty an operator needs to see.

The evidence chain

For a delivered story, the useful question is not simply “did it pass?” It is whether the following target chain can actually be reconstructed:

story contract and pinned base
  -> observed worker commits and transcript
  -> observed write set and failing-first result
  -> independent review verdict
  -> integration gate attempts
  -> post-merge gate attempts
  -> delivery record at a commit and time
  -> observed board transition

The planning files remain human-readable; the runtime store retains the typed operational history. Together they are intended to make a delivery explainable without relying on an agent's summary of its own work. For consequential changes, inspect the candidate diff and the complete chain rather than treating one green label as conclusive.

See the delivery lifecycle for when each artifact is produced and the architecture for where it is owned.