Review an AI report

Prerequisites

You need:

• A run with an AI report. Start from the run you created in Import your first report. Uploading a report normally starts its AI analysis. If the run has no report yet, open the run and choose Trigger pipeline, which needs the QA engineer role or higher. The report appears on the run’s Evidence tab, as the runs guide on GitHub describes.
• A QA lead or administrator account, signed in. API keys can’t record a decision, and that includes CI keys. Neither can the automatic QA-lead account that TestLookup creates for each project, which nobody signs in as. Some runs propose actions for an agent, an automated helper, to take. For those runs, the person who asked for the run can’t review its report.

You don’t need an AI model. When no model is available, TestLookup builds the report without one, and the report still goes through review. Don’t expect evidence from a model that didn’t run.

As you go, write down:

• the report version;
• whether it came from a model or from rules;
• the project’s review setting;
• who reviewed it;
• the TestLookup version.

Open the report

Open Inbox › Approvals, select your project, and set the source filter to AI reports. Every report that the AI analysis produces arrives here as Awaiting review.

The state filter shows Pending by default. The old reviews page now sends you here.

Choose Open report to read the report and its evidence on the run page. Before you review, check that the project, run, version and creation time are the ones you expect. Also check that the report isn’t marked as superseded, which means a newer report replaced it.

The inbox guide on GitHub describes the queue. The reporting guide on GitHub explains how reports, reviews, release decisions and exports fit together.

Check where it came from

Check what the report is based on:

• the evidence it cites;
• the run it analyzed;
• the steps that ran;
• the model and the prompt or settings, where shown;
• its confidence;
• any steps that were skipped, or that finished with parts skipped;
• any missing evidence.

Compare its claims with the test output. Note where the report draws a conclusion rather than showing it directly.

A well-formed report isn’t always a correct one. The format check looks at the shape, not the facts. A confidence value is only a real probability if someone has measured it for that exact path.

Accept or reject

Accept the report only when it describes its evidence accurately and suits the people who will read it. Reject it when it’s wrong, unsafe or unsupported, or when it’s about the wrong run or test.

1. In the queue, choose Accept or Reject.
2. For a rejection, choose the Reason: Wrong category, Unsupported claim, Missing evidence, Contradiction, Stale data or Other. Notes are optional. Don’t put secrets or personal data in them. TestLookup removes sensitive details from notes before it saves them, and it never exports notes.
3. Choose Confirm accept or Confirm reject.

There are only these two decisions. There’s no “request revision”.

To get a corrected report, reject it and run the analysis again. The new report gets its own review request.

Accepting marks the report’s AI analysis run as passed, and rejecting marks it as failed. The test run’s own status doesn’t change.

A run’s code change may have a TestLookup comment on it, on a GitHub pull request or a GitLab merge request. When you accept, TestLookup edits that comment to add “Reviewed by a person” and the time. It doesn’t name the reviewer, and it doesn’t post a new comment.

The project’s activity feed shows the outcome once. The feed also says when TestLookup skipped the comment because there’s no integration, no pull request, a newer run, or offline mode.

While review is enforced, someone who opens a share link to a pending report sees a “Report awaiting review” page.

The user workflow guide on GitHub keeps four outcomes separate: a person’s correction, feedback, creating an issue in another tool and training a model.

Check the review gate

A review screen doesn’t by itself stop unreviewed reports from leaving TestLookup. Check the review gate too. An administrator can open Settings › AI › Review gate, which reads Audit only or Enforced and says why:

• Enforced when the server’s enforcement setting is on, or when the enforcement date an administrator saved has passed.
• Audit only when the saved date is still in the future, or when there’s no date. Nothing is held back, and TestLookup only records what it would have refused.

Details: the server setting is REVIEW_GATE_ENFORCED=true.

The page also counts the exports and shares that the gate would have held back in the last 30 days.

While the gate is enforced, accepted reports and reports not written by AI can be exported and shared. A pending report can leave TestLookup only as a draft with a watermark, and TestLookup records it in the audit log.

The next section shows how. Rejected or superseded reports can’t take that draft route.

Download result

Check the report’s review state before you export it. With the gate enforced, TestLookup refuses to export a pending report (HTTP 409). Accept the report first, rather than working around the control.

To download the run’s PDF report, use the values you set in the first tutorial:

curl --fail-with-body -o run-report.pdf \
  "$TL_URL/api/v1/reports/runs/$TL_RUN_ID/pdf" \
  -H "X-API-Key: $TL_API_KEY"

For a pending report, a QA lead or administrator can add an option to that address. At this version, that’s the only way to export a pending report.

You can’t set the project-level draft permission through the API or the web app. The PDF then shows a draft watermark, and TestLookup records the export in the audit log.

Details: add ?include_unreviewed=true to the address. The watermark reads DRAFT - AI-generated, not human-reviewed.

Open the file and check the report version, any watermark or draft label, and the evidence it refers to. A successful download doesn’t mean that a notification or share link was delivered.

Audit

Check the project’s activity feed. It records each accept and reject decision with the reviewer and the time.

Also check any refused export, the export itself, and any release decision that used the report. A newer report or a recalculation must keep the earlier review history.

What a recorded run showed

This run was recorded on September 21, 2026, with an earlier development version of TestLookup. That version came before the administrator’s enforcement date and the pull request comment update existed, so details may differ on later versions.

A throwaway analysis run completed 12 steps, skipped 8 and failed none. The local model wasn’t available, so TestLookup built the report, version 1, without an AI language model.

It made no tool calls and used one evidence item. The report needed a person’s review, and it showed an AI-draft notice.

Review enforcement was then switched on in that throwaway installation. TestLookup refused a PDF request for the pending report.

After a person accepted the report, the next PDF request succeeded and returned a PDF file of 3,990 bytes. The audit view showed the refused export, the accepted review and the PDF export.

Details: the refusal was HTTP 409 with the code report_pending_review. The success was HTTP 200 with the type application/pdf.

Read the complete review policy.