Re-checking Failed Files

What is "re-check"?

After a QA run finishes, you typically:

1. Read the results.
2. Fix the failed / warning files (rename them, fix metadata, regenerate the PDF, etc.).
3. Want to confirm the fixes landed.

The naive way is to run the entire QA check again. That's wasteful — re-scanning thousands of already-passed files takes time and burns through OCR / API budget for files that don't need re-evaluation.

Re-check runs the same rule set against only the files that didn't pass last time. It produces a fresh check run, scoped to the failed and warning files from the parent run.

Where the button lives

On the run-detail page, the table toolbar has a small icon-only button near the top-right (alongside Sync, Columns, Charts, Delete). The icon is a shield with a tick — distinct from the circular-arrow Sync icon next to it: the shape signals "validate again", not "fetch latest data".

The button is only visible when:

• The run is not a pure local-upload run (re-check needs to re-fetch bytes from a cloud).
• The run has at least one failed or warning file (otherwise there's nothing to re-check).

Hover the button for the tooltip — it adapts to whether the run is mixed or cloud-only.

What happens when you click it

1. Foreman creates a new check run that mirrors the parent's configuration: same rule sets, same per-folder mappings, same zone templates, same target folders.
2. The file scope is restricted to the specific files that finished the parent run with status Failed or Warning. Passed and skipped files are excluded.
3. The new run executes in the background — same five-phase pipeline as a normal run.
4. A snackbar confirms Re-check started. Navigate to Check History (or refresh the current tab if you're already there) to find the new run and watch its progress.

The original run is not modified. The two runs sit side-by-side in history — the parent gives you the "before" picture, the re-check gives you the "after".

Mixed runs (cloud + local files)

A mixed run is one that combined cloud-resident files with locally uploaded PDFs in a single check (e.g. you ran QA across a Forma folder and uploaded a few extra PDFs your client emailed in).

Re-check works on mixed runs but local uploads are silently excluded. The reason: local upload bytes are kept under tenant-level retention and may have been cleaned up by the time you re-check. Re-fetching bytes is only reliable for cloud-resident files.

The button's tooltip explicitly calls this out: Re-check failed/warning Forma files only (local files excluded).

If you need to re-validate a local file, re-upload it through Run Check → Local upload as a fresh check.

What you'll see in the new run

The re-check is otherwise identical to a normal run:

• Same rule sets, same templates → same kind of violations get flagged.
• Files that you fixed cleanly should land in the new run as Passed.
• Files where the fix didn't land (or introduced a new violation) reappear as Failed / Warning with up-to-date evidence.
• Pass rate on the dashboard updates: the re-check counts as its own run and contributes to the trend line.

Tip — pair re-check with bulk Resolve All on the parent run after the re-check confirms passes. The parent run's violations are technically still "Open" until you mark them; Resolved records that you saw the fix land.

When not to use re-check

• You changed the rules, not the files. Re-check uses the parent's rule configuration; if you tweaked a rule between runs, re-check applies the new rules but only to the failed subset. Better to start a new full run so the dashboard reflects the new rules across all files.
• You added new files to the folder. Those files weren't in the parent run, so re-check won't touch them. Run a fresh full check instead.
• The parent was a pure local-upload run. The bytes aren't refetchable; re-upload via Run Check.

Permissions

Same as starting any QA check — any user with edit access to QA can trigger a re-check.

Audit trail

Re-check writes a single audit event qa.run.rechecked recording the parent run id, the new run id, and the count of files included.

Next steps

• Managing Violations — close out violations after the re-check
• Running QA Checks — full-folder runs vs targeted re-checks
• Check History — find your re-check in the history list