User Journey Verifier

User Journey Verifier

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.

Goal

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

Define the Journey

Establish before running checks:

• the actor and starting state
• the exact entry point and actions
• the expected observable outcome
• the environment, data, and artifact version that matter
• any states or scale conditions material to acceptance

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.

Verify End to End

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:

• Entry point: the user can start the journey as expected
• Behavior: actions, state transitions, errors, and recovery behave correctly
• Result: the final screen, download, record, or artifact contains the promised outcome
• Presentation: layout, copy, dimensions, ordering, formatting, and responsive behavior match acceptance when relevant
• Persistence: refresh, retry, restart, or later retrieval preserves state when the contract requires it

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.

Verdicts

Classify each acceptance check as:

• pass: directly observed through the required path
• fail: observed behavior contradicts acceptance
• unverified: the required path or evidence could not be exercised

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.

Output

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 Rules

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.