---
title: "Keep acceptance criteria independent of generated fixes"
description: "Design test ownership and review rules so a coding agent cannot silently weaken the expected behavior while repairing the implementation it generated."
canonical_url: "https://vostride.com/agent-library/software-factory/independent-acceptance-criteria.md"
md_url: "https://vostride.com/agent-library/software-factory/independent-acceptance-criteria.md"
content_kind: "guide"
topic: "software-factory"
---

# Keep acceptance criteria independent of generated fixes

Using a separate QA runtime changes where a test executes. It does not, by itself, prevent the coding agent from editing the expected result. Independence comes from the way a team specifies, reviews and protects acceptance criteria.

## Write a contract before a repair

State the initial actor, resource, action and observable outcome. For an access-control repair, identify the role that must be allowed and the role that must be denied. Preserve an independent fixture manifest with the expected owner and organization. This makes it harder for an incorrect result to look valid merely because it is internally consistent.

Choose one negative control that would expose the original defect. If both allowed and denied actors can complete the operation, a happy-path screenshot is not adequate verification. The [authorization recipes](/agent-library/authorization.md) describe paired cases to adapt.

## Review changes to intent

Treat edits to expected outcomes as changes to the contract. A label update can be routine when the underlying behavior is unchanged, but removing a persistence assertion or substituting a different actor needs explicit reasoning. Review test and implementation diffs together, with special attention to skipped steps and broadened success conditions.

Restrict test-mutation access where the team's release process requires it. The website's [coding-agent workflow](/docs/agent-qa/guides/coding-agent-workflow.md) explains that local tool permissions and ownership decisions are separate from runtime execution.

## Measure the quality of the oracle

Run the same test against a known failing fixture or deliberately incorrect application behavior in a disposable environment. Confirm the assertion rejects the defect for the expected reason. A negative control that fails only because login was unavailable does not establish defect detection.

Record the accepted requirement, the negative-control result and the candidate result. This is especially useful when natural-language execution, cache reuse or self-healing changes the route through the interface. The route can change while the outcome remains fixed.

[Evaluation guide](/docs/agent-qa/guides/evaluating-agent-qa.md) · [Release evidence](/agent-library/software-factory/release-evidence-contract.md)