# Fix and verify (/docs/guides/fix-and-verify)



Open a confirmed finding and select **Fix and verify**.

<Callout type="warning" title="A code change is not a verified fix">
  Resolve the finding only after a new assessment confirms the expected behavior
  and protected behavior.
</Callout>

## Review the finding first [#review-the-finding-first]

Confirm the expected behavior, observed behavior, customer impact, affected journey, and supporting evidence. If the evidence is incomplete, gather more evidence before proposing a fix.

## Prepare the fix [#prepare-the-fix]

<Steps>
  <Step>
    ### Connect an approved repository [#connect-an-approved-repository]

    Use the workspace's approved GitHub App connection. The repository must be inside the authorized organization and scope.
  </Step>

  <Step>
    ### Review the plan [#review-the-plan]

    The plan should identify the cause, intended code change, affected tests, verification journey, and safe rollback path. Reject unrelated changes.
  </Step>

  <Step>
    ### Approve execution [#approve-execution]

    A permitted user must approve the plan before execution. Approval is bound to the current finding revision and plan. A material finding change makes the old approval stale.
  </Step>

  <Step>
    ### Review the result [#review-the-result]

    Check changed files, test output, limitations, and the exact revision produced by the fix run. A failed or incomplete fix remains open.
  </Step>

  <Step>
    ### Run verification [#run-verification]

    Rerun the affected journey and relevant variations. Invokeable compares the resulting product state with the original expected behavior.
  </Step>
</Steps>

## Verification outcomes [#verification-outcomes]

* Resolve the finding when the expected state and protected behavior pass with sufficient evidence.
* Return the finding to confirmed when the failure remains.
* Move it to needs evidence when the result cannot be observed reliably.
* Reopen a resolved finding if the same problem recurs.

## Manual fixes [#manual-fixes]

You can fix the product outside Invokeable. Keep the finding open until you run the same verification journey. Record enough context for reviewers to understand which product revision was tested.

See [Evidence and findings](/docs/concepts/evidence-and-findings) and [Review results](/docs/guides/review-results).

## Findings after verification [#findings-after-verification]

A newer successful run of the same test can automatically resolve its finding
when the environment, agent, and variation match, the previously failing checks
pass with objective evidence, and cleanup is verified. Resolved findings stop
appearing under **Issues to fix** and stop affecting readiness. Open **Resolved**
to review the original finding and its verification.

If the original test assertion was incorrect, first correct the test and rerun
the affected journey. Open the finding and choose **Resolve with verification**.
Select the successful run and explain what was wrong with the original assertion
and how the corrected test still proves the intended result. Invokeable records
this as **Assessment corrected**, with the original outcome, verification, and
reviewer preserved. Changing a test alone does not resolve a finding.