Verify the outcome through the same path the user relies on.

Verification does not authorize fixes. Do not edit code, install dependencies, change configuration, deploy, or mutate production or external systems unless the user separately requests that action.

Produce direct evidence that the requested user-visible behavior works from its real entry point to its final state or artifact.

Establish before running checks:

Use the user's stated path when one is provided. A substitute path cannot prove the requested path: directly invoking an export function does not verify a browser download button, and inspecting source data does not verify the generated workbook.

If the authoritative environment, reference artifact, or required access is missing, report the gap rather than silently substituting another source.

When supporting a conformance audit, use its specific acceptance criteria and evidence gaps to scope the journey. Report observations against those requirements without waiting for a conforming verdict; the journey supplies evidence needed to establish it.

Reuse direct journey evidence already obtained within the same implementation task when it covers the same relevant implementation or artifact version, entry point, acceptance criteria, environment, inputs, and conditions. Identify the observations being reused and confirm that no intervening change invalidates them. Another skill invoking this verifier does not by itself require a rerun.

When evidence is missing or invalidated by changes, failures, or new concerns, exercise the narrowest complete journey that resolves the gap. Retain applicable evidence for unaffected acceptance checks. Use available browser, document, PDF, spreadsheet, image, log, or shell capabilities only as needed for the actual outcome.

Check the relevant layers:

Use representative data and scale when the defect or requirement depends on them. Do not claim broad coverage from a happy-path fixture that omits the reported condition.

Local or test verification may perform normal reversible actions required by the journey, such as uploading a fixture or creating disposable test state. Keep artifacts outside the working tree when practical, clean up through the application's normal mechanisms when safe, and do not treat test authority as permission for production or external mutation.

Classify each acceptance check as:

Valid reused observations count as direct evidence. State when a verdict relies on them rather than implying that a new execution occurred.

Automated tests, typechecks, builds, logs, and code inspection can support a verdict, but they cannot replace missing user-visible evidence when the outcome is visual, interactive, or artifact-based.

Lead with the journey-level verdict: pass, fail, or unverified.

Report:

For a failure, include the shortest reliable reproduction and the observed-versus-expected difference. Name a likely implementation area only when evidence supports it; do not turn verification into speculative diagnosis.

For an unverified result, state the exact missing access, environment, data, or tool and the next check that would close the gap.

Stop when every material acceptance check has direct evidence or an explicit verification gap. Never report success solely because a different path, unit test, build, or generated artifact succeeded.