Behavior Validation
Judge what the product does, not how its source appears to do it.
Establish isolation
Write or read the behavior contract before exercising the target. Use
behavior-contract.md. The contract must name
user tasks, expected outcomes, setup, allowed interfaces, negative cases, and
required evidence.
Do not inspect source, diffs, internal tests, Git history, or implementation
notes during validation. Interact only through public browser, CLI, API,
artifact, accessibility, or operator surfaces. If source is required, mark the
clause blocked and hand it to root-cause-debugging.
Exercise the contract
- Run each task through the same entry point a real user or operator uses.
- Vary input and state to detect hard-coded success, stale data, or display-only
behavior.
- Test invalid, empty, interrupted, retry, persistence, and permission paths
where the contract makes them relevant.
- Capture redacted screenshots, terminal excerpts, response summaries, or
artifact facts.
- Mark every clause pass, fail, blocked, or out of scope. Lack of evidence is
not a pass.
When a finding is fixed, rerun the failed clause and nearby regression probes;
do not rerun unrelated expensive scenarios without reason.
Completion condition
Every relevant contract clause has a status and reproducible evidence, anti-fake
probes were attempted, secrets and private data were excluded, and the report
does not infer implementation defects from observable symptoms.
1---2name: behavior-validation3description: Validates a running application, CLI, API, service, or generated artifact as a user or operator against a prewritten observable behavior contract while remaining source-blind. Use for acceptance checks, runtime proof, anti-fake probes, release smoke tests, or an independent companion to code review. Not for source-quality findings, root-cause diagnosis, or visual design judgment outside the contract.4---56# Behavior Validation78Judge what the product does, not how its source appears to do it.910## Establish isolation1112Write or read the behavior contract before exercising the target. Use13[behavior-contract.md](references/behavior-contract.md). The contract must name14user tasks, expected outcomes, setup, allowed interfaces, negative cases, and15required evidence.1617Do not inspect source, diffs, internal tests, Git history, or implementation18notes during validation. Interact only through public browser, CLI, API,19artifact, accessibility, or operator surfaces. If source is required, mark the20clause blocked and hand it to `root-cause-debugging`.2122## Exercise the contract23241. Run each task through the same entry point a real user or operator uses.252. Vary input and state to detect hard-coded success, stale data, or display-only26 behavior.273. Test invalid, empty, interrupted, retry, persistence, and permission paths28 where the contract makes them relevant.294. Capture redacted screenshots, terminal excerpts, response summaries, or30 artifact facts.315. Mark every clause pass, fail, blocked, or out of scope. Lack of evidence is32 not a pass.3334When a finding is fixed, rerun the failed clause and nearby regression probes;35do not rerun unrelated expensive scenarios without reason.3637## Completion condition3839Every relevant contract clause has a status and reproducible evidence, anti-fake40probes were attempted, secrets and private data were excluded, and the report41does not infer implementation defects from observable symptoms.
thiientv