Bugs and evidence: why plausible is not enough
Evidence is an observable basis for a decision, such as a reviewed diff, a test result or a validation finding. A BUG is behavior that violates an established expectation. An agent's confident explanation is neither proof that the requirement holds nor a substitute for observing the relevant state.
This page explains evidence within IMPLEMENTATION in AI Architect Mastery's AI Driven Development Methodology. Work Types defines how BUG differs from TASK and PROB.
Agent claim is not evidence
A completion statement describes what the agent believes it achieved. Evidence lets the human inspect whether the claim holds. Human Judgment evaluates the relevance and sufficiency of those observations; the agent's confidence cannot substitute for that decision.
Why evidence must be state-aware
A result applies to the version, configuration, inputs and environment that produced it. A passing check before the latest change does not prove the current implementation. An unavailable integration environment remains a limitation, not a passed check.
What useful evidence records
- The requirement or acceptance criterion being checked.
- The relevant implementation state and test conditions.
- The check actually performed and the observed result.
- The difference between expected and actual behavior.
- Unexecuted checks, limitations and remaining risks.
Constructed finding: allowed is not denied
An export succeeds for its owner, but that says nothing about a signed-in non-owner. A separate denied-request check shows whether access is actually blocked and whether record contents leak in the response. Both observations must be tied to the reviewed change.
Interpret the failure before correcting it
If the requirement clearly prohibits the observed behavior, record a BUG and perform a scoped correction. If the expected behavior is undefined, treat the uncertainty as PROB and seek a human return decision. Evidence identifies the gap; it does not invent the missing policy.