Read run results

Confirm the target and run

Start with the project, repository, action, completion time, branch, and commit. A report describes the revision it checked, not whatever is currently open on the default branch. When viewing history, confirm that you did not accidentally interpret an older run as the latest result.

For Auto-pentest, also verify the exact linked website. Repository identity and website target are separate parts of that run.

Read the main answer first

The headline and narrative should answer the run’s practical question before presenting detail. For an audit, that means the current health conclusion. For an improvement, it means whether the candidate was fixed, documented, already resolved, blocked, or left for review. For a pentest, it means what was confirmed and what provider action followed.

Do not infer “healthy” from a completed status. Completion means the workflow produced its valid outcome; that outcome can still describe red-zone evidence, failed verification, or no authorized write.

Inspect scores, findings, and evidence

For audits, read the audit-specific criteria and calculation. The shared green/yellow/red zones do not make formulas interchangeable. A cap can keep a result below a threshold even after one local fix. Findings should cite representative current evidence and distinguish confidence, severity or priority, impact, and next action.

Evidence may include source paths, configuration names, command results, scanner facts, or bounded external observations. Sensitive values should be redacted. Open the source only when your provider access permits it.

Read limitations as part of the result

Limitations explain untested surfaces, unavailable tools, provider API gaps, private services, environment failures, shallow history, inaccessible external context, or target restrictions. They are not boilerplate. A limitation can lower confidence, leave a criterion unscored, or constrain the score when a material surface is hidden.

Do not turn “not observed” into “absent.” Decide whether the missing evidence needs a rerun, owner confirmation, a different environment, or specialist review.

Follow provider artifacts carefully

An issue is a durable problem and decision thread. A pull or merge request is a proposed code change. A provider comment can be a review result or an update to existing work. Compare the artifact with the report, inspect the exact diff and checks, and confirm it still targets the current repository state.

Guard does not merge Autofixes. If no review request exists, read the outcome before treating it as an error: issue-only policy, duplicate work, unsafe scope, stale evidence, or failed verification may be the intended result.

Choose the next action

Rerun when the repository or evidence has materially changed. Review and merge only through normal repository controls. Escalate active-testing, legal, production, or high-blast-radius decisions to the responsible owner. After a merge, rerun the affected audit so new evidence—not artifact existence—shows whether health improved.