Human Verification
Verification records whether a person checked a reported issue on a specific fixed version. Keep it separate from applying a patch, changing a status, or merging a pull request.
Before you start
A proposed fix on a known build or deployment, plus an eligible verifier.
What you get
A human approval or rejection, recorded against the selected version.
Request and decide verification
INTERACTIVE EXAMPLEAssign a sample fix check against a specific deployment.
Checkout total is incorrect
Staging · checkout-v2 · target commit 7c9e4a1
Request verification
Deploy or build the proposed fix and confirm the intended environment/version.
Open the annotation's verification controls with permission to request verification.
Choose an eligible verifier and the target build or deployment, then submit the request
Verify that the request is pending for the intended person and target.
The verifier can find the request in My Work and open the report's context.
Approve or reject the result
Open the assigned request and check the target build/deployment, expected result, and reproduction steps.
Repeat the steps on that target
Use the recorded evidence and Claron It where useful, but check the behavior itself.
Approve when the intended result passes
If it fails or you cannot verify the right target, reject and enter a concrete reason, including the failing step.
Confirm the recorded decision and version
The assigned verification task clears when its decision is recorded; merely reading the report does not complete it.
If verification cannot proceed
Check that you are the assigned eligible verifier, can access the target version, and have permission for the action. A pending status-approval request and a verification request are different workflows.
For production extension issues, perform a human check on the chosen deployment. Automated retakes/after screenshots/pixel comparisons are not available for live production annotations. A missing capture must not be treated as a passing test.
